Product management

Product management is a sequence of decisions. The artifacts came later.

Why we bothered writing this

We build software for product teams, so we have an obvious interest in you thinking product management matters. Read the rest with that in mind.

We wrote this page because the standard version of it is everywhere and it never helped anyone. You know the shape — a definition, a list of responsibilities, product manager versus product owner, eleven frameworks in a grid, a career ladder, and a tool recommendation at the bottom that happens to be the tool the page is selling.

That page describes the furniture of the job. Someone who reads it can name every artifact a product team produces and still have no idea how a product goes wrong.

The version below is the one we wanted when we started. It took about twenty-six years and a lot of expensive mistakes to arrive at, most of them ours.

The thing that took the longest to see

Here is a pattern that should be impossible.

A company hires strong people. The engineering is genuinely good — tested, instrumented, shipped on a predictable cadence. The process is mature. Discovery interviews happen. There's a roadmap, reviewed quarterly, tied to OKRs. Every ceremony runs. Every artifact exists and every artifact is well made.

And the product fails anyway. Not dramatically. It just never becomes something anyone would miss.

Spend long enough around this and the reason stops being mysterious. The artifacts were produced correctly and they were answering nothing. The roadmap was a list of agreed work rather than a set of bets. The interviews were conducted, transcribed, and never contradicted anyone. The OKRs were set at the start of the quarter and interpreted generously at the end of it. Everything looked like product management and none of it changed what got built.

That's the failure worth studying, because it survives every improvement you make to execution. Faster delivery of the wrong thing arrives at the wrong destination sooner.

We spent a long time on the execution side of this — predictability, quality, throughput. Those things are worth having. They pay off only after the question of what to build has been answered honestly, and they are perfectly capable of hiding the fact that it hasn't been.

What the job actually is

Underneath the ceremonies, a product organisation is a machine for making a small number of decisions repeatedly, under uncertainty, with incomplete information, in public, with money attached.

Six of them. Every product team makes all six, continuously, whether or not anyone writes them down. Teams that don't name them still make them — by default, by seniority, by whoever spoke last in the meeting.

Naming them is most of the discipline. Once you can see which decision is on the table, you can ask what would actually settle it, and that question is the one that separates product work from product theatre.

The six decisions

  1. Which problem

    Out of everything that could be worked on, which problem gets the team.

    What would answer itEvidence that this problem is more expensive, more frequent, or more strategically load-bearing than the others you could have picked. That means knowing what the others were. A decision made without a visible alternative isn't a decision.

    How it gets fakedThe problem arrives already chosen. It came from a customer with leverage, an executive with conviction, or a competitor's release notes. The team's energy goes into solving it well, which feels like doing the job.

    What being wrong costsThe entire quarter, plus the compounding cost of everything that quarter displaced. This is the most expensive of the six and it gets the least scrutiny, because by the time work starts, the choosing is already over.

  2. Whose problem

    Which specific people have it, and how you'd recognise one.

    What would answer itA description precise enough to be wrong. "Product leaders at growing SaaS companies" excludes almost nobody. "The person who has to defend the roadmap to a board that has started asking harder questions" excludes almost everybody, which is what makes it useful.

    How it gets fakedPersonas built from internal assumption and stock photography, agreed in a workshop, filed, never consulted again. The tell is that the persona has never once been used to reject an idea.

    What being wrong costsYou build something that's mildly appealing to a wide group and essential to nobody. Nobody churns and nobody advocates. The product survives without ever getting traction, which is a slower death than failing outright.

  3. Whether it's worth solving

    Whether solving this problem is worth what solving it costs.

    What would answer itA number on both sides. What the problem costs the people who have it, in money or time or risk. What building the solution costs you, including the opportunity cost. And the size of the bet relative to how long you can survive being wrong about it.

    How it gets fakedA prioritisation score. Effort and impact, each estimated by the people who want the outcome, multiplied together, sorted descending. The arithmetic gives an opinion the appearance of a measurement.

    What being wrong costsProportional to your runway. A large company absorbs a wrong bet as a bad quarter. A company with eighteen months of cash absorbs it as a third of the company's remaining life. Most teams size bets without ever converting them into that unit.

  4. Which solution

    Of the several things that would address the problem, which one you build.

    What would answer itNaming what has to be true for the solution to work, then testing the assumption that would hurt most if it were false. Every solution rests on a stack of these. Most teams can list them if asked. Very few write them down, and almost none go and check the riskiest one before committing.

    How it gets fakedA single solution appears alongside the problem, usually in the same sentence, and the team's work becomes specifying it. The PRD documents the decision after it was made and mistakes documentation for reasoning.

    What being wrong costsYou solve a real problem for real people in a way they won't adopt. This is the failure that generates the most confusion afterwards, because the research was right and the thing still didn't work.

  5. Whether to continue

    At each point where new information arrives, whether this remains worth doing.

    What would answer itConditions written down in advance, before anyone is invested — what would have to be observed for you to stop. Written after the fact, "we've learned a lot" is always available and always true.

    How it gets fakedBy never asking. Work that has started has momentum, a team attached, and a slide in the board deck. Stopping requires someone to volunteer that something was wrong, and nothing in a normal quarterly cycle rewards that.

    What being wrong costsThe difference between a small wrong bet and a large one. This decision is the only mechanism that converts one into the other, which makes it the highest-leverage of the six and the most routinely skipped.

  6. Whether it worked

    After shipping, whether the thing you built produced the outcome you built it for.

    What would answer itThe outcome named before the work started, measured after, compared honestly. Adoption answers a narrower question — whether people found the feature. Whether it changed anything is a separate measurement, and it's the one that was supposed to justify the work.

    How it gets faked"Done" means shipped. The release goes out, the ticket closes, the team moves on. Nobody returns, so nothing is ever confirmed or disproved, so the next bet is made on exactly the same quality of information as the last one.

    What being wrong costsThe learning. A team that never checks accumulates experience without accumulating judgement. Ten years of this produces confident people whose confidence rests on nothing that was ever tested.

Where the artifacts come from

Every artifact in product management exists to serve one of those six decisions. Each becomes ceremonial at the moment it detaches from the decision underneath it.

  • The roadmap serves which problem, and turns into a list of agreed work when it stops carrying the reason each item is there.
  • The persona serves whose problem, and turns into decoration once it has never been used to say no.
  • The prioritisation model serves whether it's worth solving, and turns into arithmetic theatre when its inputs are estimates supplied by the people who want the answer.
  • The PRD serves which solution, and turns into a specification when it records a decision instead of the reasoning that produced it.
  • The experiment serves whether to continue, and turns into a formality when it's run after the commitment rather than before.
  • The retrospective and the analytics dashboard serve whether it worked, and turn into reporting when nobody is willing to conclude that something didn't.

This is why arguments about frameworks go nowhere. Two frameworks that seem to contradict each other are usually optimising different decisions, and the argument resolves the moment someone asks which decision is actually on the table.

It's also why adopting a framework rarely changes outcomes. The artifact was never the thing doing the work.

The part that breaks even when every stage is run well

You can run all six decisions competently and still end up with a product nobody can explain.

The damage happens between them. Research completes and the roadmap doesn't move. A solution ships and nobody checks it against the problem it was chosen for. An outcome gets measured and never reaches the strategy that produced it. Each stage was fine. The chain connecting them wasn't there.

This is the failure that tooling made worse rather than better. Strategy lives in one place, discovery in another, the roadmap in a third, delivery in a fourth, feedback in a fifth. Each tool is competent at its stage and none of them can see a handoff. The seams are exactly where the reasoning gets dropped, and they're the one part of the system that no assembly of separate tools can report on.

We named the condition where the chain holds [product integrity](/product-integrity), and it's the thing we've spent the company trying to make measurable.

What to ask your own team this week

Four questions. They take about an hour and they're uncomfortable in a useful way.

  1. Pick an item on your roadmap and ask why it's there. A good answer names a problem, who has it, and what suggested it was worth the slot. A revealing answer names a person.
  2. Find the last piece of research your team completed and ask what changed because of it. If the answer is a document, the research served a decision that had already been made.
  3. Ask what your team is currently building and what would have to be true for it to work. Then ask which of those assumptions has been checked. The gap between the length of the two lists is the real risk on that project.
  4. Take the last three things you shipped and ask whether they did what they were meant to do. If nobody can say, you're not accumulating judgement, and no amount of further shipping will start.

None of this needs a tool. It needs someone willing to ask in a room where the honest answer is embarrassing.

Going further

  • Product integrityThe condition where the chain of reasoning behind a product holds together, defined properly, including the five stages and the seams between them.
  • The product failure ontologyThe catalogue underneath this page. Every way these six decisions go wrong, named, with the mechanism that produces each one.
  • How Shorter Loop worksWhat we built, and which of the six decisions each part of it serves.
  • Choosing a product toolAn honest account of where we fit, including where we're the wrong choice.