Problem Driven Development

Problem Driven Development is presented as a simple way to decide what to do in senior engineering roles. Instead of asking for ideas or prioritizing solutions, the post says teams should identify the biggest problems they actually have, revisit that list over time, and build the roadmap from there.

The post points to auditable problem sources such as pages, SLO violations, wasted time, alerts, cost, and change failures. It also argues that tech debt should be justified with small amounts of data about wasted time, change frequency, and fail rates rather than treated as a vague complaint.

Reading notes

#

• Senior engineers and engineering managers often struggle to define technical roadmaps.
• Good technical vision is described as a simple review of small amounts of data.
• Problem Driven Development means building the roadmap around fixing things that are going wrong.
• Asking people what the team should do tends to produce solutions instead of problems.
• When teams prioritize solutions, they can spend years executing without fixing the underlying problems.
• When teams prioritize problems, they stay focused on the issues they actually have.
• The post names pages, SLO violations, wasted time, alerts, cost, and change failures as places where team problems live.
• These sources are described as auditable and usable for building a prioritized problem list.
• Tech debt should be framed in terms of the problems it causes, such as coding difficulty, wasted time, change frequency, and fail rate.
• Regular-sized tech debt can be handled as people work in that part of the codebase.
• If a team is asked to scope and prioritize tech debt, the claim should be backed by at least a little data.
• The post says this approach helps teams say no to solutions that do not solve a real problem.
• Next steps include finding the biggest problems, exposing teams to the problems they face, and grounding the team in the why of the work.
• The appendix says this approach is basically ersatz product management, with a caution that customer-problem research can be costly and unnecessary when competitors already have an obviously valuable feature.