Structure, not process
Your org chart is deciding your roadmap.
Around half of the fifty-two named product failure modes describe an organisation rather than a document. Six structural arrangements produce most of them, and process improvement doesn't touch any of the six.
We sell software to product teams, so we have an interest in you believing product decisions can be improved. Worth knowing before you read on. We'll also be explicit later about where software is irrelevant to the problem described here, because a fair amount of it is.
This exists because the failure ontology kept pointing at something it couldn't explain. The catalogue names fifty-two ways product decisions go wrong and detects each by the trace it leaves in a document. A document is an output. Something produced it, and that something is usually not the person who typed it.
The expensive failure is the one that doesn't look like failure.
Companies that fail outright are rare, well documented, and not very interesting. Somebody ran out of money, or built for a market that wasn't there, and the post-mortem writes itself.
The common case has no name. A product organisation of forty people, competently run, shipping continuously, hitting most of its dates, staffed with people who would be hired anywhere. It has a strategy deck, quarterly OKRs, a discovery practice, a design system, a research function. And it produces roughly half of what it could, for years, without anyone being able to say precisely what's wrong.
Nobody gets fired for this. It shows up as a competitor with fewer engineers moving faster, as a roadmap that looks reasonable and never compounds, as a slow accumulation of features nobody asked for twice.
Put the same forty people into a different structure and they produce different decisions. Leave the structure alone and replace all forty, and within two quarters the output looks the same as before. That's testable against your own history: if you've replaced a product leader in the last three years and the pattern of decisions reverted within six months, you've already run the experiment.
Six things about your structure, and what each one produces.
Each carries the failure modes it reliably produces, a diagnostic you can run this week, and the only intervention that actually moves it.
THE ARRANGEMENT
Whether the product function reports to a customer-facing revenue leader, to engineering, or to the chief executive. And separately, whether individual PMs report into a product organisation or into the business unit they serve.
What it produces
Problem selection stops being a product decision. Requests arrive already chosen, carrying the authority of whoever made them, and the PM's work becomes solving them well. The tell is subtle — nobody in this arrangement believes they're overriding evidence. They believe they're being commercially responsive, and much of the time they are.
Problem selection stops being a product decision. Requests arrive already chosen, carrying the authority of whoever made them, and the PM's work becomes solving them well. The tell is subtle — nobody in this arrangement believes they're overriding evidence. They believe they're being commercially responsive, and much of the time they are.
- 01Stakeholder Laundering
- 02HiPPO-ism
- 03The One Shouting Loudest Wins
- 04My-Budget-My-Features
- 27Selling Vaporware Features
Take the last ten roadmap items. For how many can you name the person who wanted it faster than you can name the evidence for it?
Moving the reporting line, which is a board-level conversation. Short of that: making the origin of every roadmap item a recorded field. It doesn't fix the capture, and it makes the capture visible, which is a precondition for anyone doing anything about it.
The practice was fine. It was applied to a symptom.
Process improvements are applied at the level of practice. These causes sit at the level of structure. A practice change lands on top of a structure that produced the original behaviour, and the structure wins, because the structure determines who gets promoted and who gets overruled.
Run a continuous discovery programme in an organisation where product reports to revenue and you don't get continuous discovery. You get better-documented stakeholder capture — research properly conducted, properly synthesised, and unable to change a roadmap that was never being set by evidence.
This is why "we tried that and it didn't stick" is the most common sentence in product transformation.
It also explains a pattern you'll recognise. A new product leader arrives, changes the practices, sees improvement for two quarters, and watches it decay. Nothing decayed. The practice was held in place by that person's individual effort against a structure pulling the other way, and personal effort has a shelf life.
Including ours.
We'd be doing the thing we're describing if we finished with a product pitch, so here's the honest division.
Arrangements 1 · 2 · 3 · 6
Software does nothing here.
Reporting lines, compensation, PM ratios and whether refusal is survivable are decided by people with organisational authority. Any vendor claiming otherwise is selling you a way to feel active about a problem you haven't addressed.
Arrangements 4 · 5
Software helps here.
Reasoning dropped at a handoff, and customer signal never reaching a decision, are both information-routing failures. That's a tractable thing to build for.
All six · one way
Making the pattern visible.
Nobody's dashboard shows "forty percent of roadmap items originate from one executive." A system checking decisions against a failure taxonomy surfaces the evidence you need to have the structural conversation. It doesn't have the conversation for you.
We think that's worth building. We also think you'd get most of the diagnostic value from the six questions below and an afternoon.
Answer them here. Nothing leaves your browser.
They take about an hour to answer properly and need nobody's permission. Answer them here for a quick read on which arrangements are live.
- 01
Of the last ten roadmap items, for how many can you name the requester faster than the evidence?
- 02
Why was the last person promoted in your product organisation?
- 03
How many open questions in current planning documents are addressed to a PM?
- 04
At your last discovery study: was an engineer present when hypotheses were formed, and did the roadmap change afterwards?
- 05
Do the three problems generating the most support contacts appear anywhere on your roadmap?
- 06
Is there a written record of a PM declining a senior request, with reasoning, in the last quarter?
Make the pattern visible.
Shorter Loop records where every roadmap item came from and what evidence backs it — so the structural conversation has something on the table other than opinion.