Product Management Is Broken (And How to Fix It)

Product management has an identity crisis. In the span of about a decade, it went from a relatively clear discipline (understand the user, define the problem, ship a solution) to a bloated ecosystem of frameworks, certifications, and rituals that often produce impressive-looking artefacts and unimpressive products. We've worked with enough product teams across government, enterprise, and startups to see the patterns. This is what's broken, and what works.

The Framework Industrial Complex

Walk into most product teams and you'll find an impressive collection of frameworks. OKRs cascading down from company objectives. A RICE-scored backlog. Opportunity solution trees. Jobs-to-be-done canvases. North Star metrics with input metrics. Story maps. User journey maps. Impact maps. Value proposition canvases.

None of these are bad tools. Some are useful. The problem is when the frameworks become the work instead of informing the work. We've seen product managers spend weeks perfecting their OKR hierarchy while the engineering team sits idle waiting for direction. We've seen beautifully maintained story maps that nobody references during sprint planning. We've seen opportunity solution trees that haven't been updated since the off-site where they were created.

The most effective product managers we work with use maybe two frameworks consistently. They pick the ones that help them think clearly about their specific context, and they use them as thinking tools, not presentation tools. If a framework doesn't change a decision you make, it's overhead.

The Feature Factory Problem

John Cutler coined the term "feature factory" years ago and it's only gotten worse. In a feature factory, the product team's job is to define features, the engineering team's job is to build them, and nobody's job is to verify that the features achieved anything. Success is measured by output (features shipped) not outcome (problems solved).

The symptoms are obvious once you know what to look for. The backlog has 200+ items and grows faster than the team can deliver. Every stakeholder meeting adds features, none removes them. Nobody can articulate which of last quarter's features moved a business metric. The team talks about velocity in terms of story points delivered, not customer outcomes achieved.

The root cause is usually organisational. Product managers are incentivised to ship features because that's visible and measurable. Saying "we investigated three approaches, ran experiments on two, and decided not to build anything because the problem isn't worth solving" takes courage and organisational support that most PMs don't have.

The Discovery Gap

Product discovery, the process of figuring out what to build before you build it, is where most product teams fall down. It's either skipped entirely ("the CEO said we need this feature, just build it") or performed as a one-off ("we did user research last year") rather than a continuous practice.

Continuous discovery means talking to users every week. Not quarterly research sprints. Weekly conversations. Teresa Torres's approach of weekly customer interviews is one of the few product frameworks we advocate for, because it forces ongoing contact with reality. Product decisions grounded in last week's user conversations are better than decisions grounded in last quarter's research report.

The other discovery gap is technical discovery. Before committing to a solution, the engineering team should have spiked on the hardest parts. Not estimated them. Explored them. A one-week technical spike that reveals a proposed approach won't work saves three months of building the wrong thing. We build technical discovery into every project plan, and it's the single most effective practice for reducing delivery risk.

The Effective Model

Outcomes Over Outputs

Good product teams start with a measurable outcome: reduce customer support tickets about billing by 40%. Increase self-service completion rate from 60% to 85%. Decrease time-to-first-value for new users from 3 days to 3 hours. The team is empowered to find the best way to achieve the outcome, which might be a feature, a process change, a documentation update, or removing existing functionality that's causing confusion.

Small Bets, Fast Feedback

Instead of spending three months building a feature and hoping it works, good teams break work into experiments. A Figma prototype tested with five users costs a day and tells you if the concept works. A behind-a-feature-flag MVP released to 5% of users tells you if the implementation works. A full rollout with instrumented analytics tells you if it achieves the outcome. Each stage is a checkpoint where you can pivot or stop.

Empowered Teams, Not Feature Teams

The distinction matters. A feature team receives a roadmap of features to build and executes. An empowered team receives a problem to solve and figures out the solution. The empowered model requires more trust from leadership but produces far better outcomes, because the people closest to the problem are making the decisions.

Fixing It in Practice

If you recognise your team in the problems above, start with this. First, audit your backlog. If it has more than 30 items, most of them are noise. Archive anything that hasn't been touched in 90 days. If it's important, it'll come back. Second, pick one outcome metric for the quarter and make it the team's north star. Every piece of work should have a hypothesis about how it moves that metric. Third, institute weekly user conversations, not delegated to a UX researcher, but attended by the PM and at least one engineer. Fourth, kill the features that aren't working. Shipping is not success. Usage is not success. Achieving the outcome is success.

The incentive structures, organisational models, and accumulated process cruft make it extraordinarily hard to do the job well. Fixing it requires changing the system, not the people in it. The teams that get it right, outcome-driven, continuously learning, and ruthlessly prioritised, build products that are an order of magnitude better. It's worth the fight.