You can't hold a team accountable for outcomes while withholding the strategy, the information, and the trust that make them possible.
Home • About • Projects • Blog • Resources • Contact
When I've built or inherited a product function, one of the first things I've looked at is the gap between what the business asks product for and what it actually gives product to work with; in my experience, that gap explains far more about a team's impact than its talent does.
The pattern I, and many others, have observed is this: a company hires senior product people, tells them it wants outcomes rather than a features factory, then hands them a roadmap that's already been decided somewhere upstream, restricts access to the P&L, treats the operating model as optional the moment a stakeholder gets nervous, and sees customer research as a phase rather than a habit. More often than not, the teams end up shipping things instead of solving problems, because nobody gave product what ownership requires, yet it was held accountable as if they had.
At one company I worked with, a platform rebuild had been running for months with no product involvement at all. Nobody had asked what problem it was solving, what would count as success, or what it would break on the way. The technical case sounded reasonable on its own terms; it usually does, in isolation. When I finally got visibility and proposed a pause and an independent audit, we found spend had spiralled and was on course to end up around four times the original budget, with no discovery, no meaningful success criteria, and a required safety sign-off nobody had sought. The programme had a senior sponsor who believed in it completely. Nobody involved was lying about any of it; they just weren't being asked the questions product exists to ask, because product hadn't been let anywhere near it. We recommended stopping it, and did; but I only got pulled in once the spend was already three-quarters of the way to the original budget, not when the programme was approved, which meant the audit cost far more, in money and in trust, than it should have. That's on the system that kept product out of the room in the first place, but it's also a reminder that asking for visibility earlier, before there's a reason to, is a habit worth building deliberately rather than waiting to be invited in once something's already gone wrong.
That's the expensive version of what happens without access. The cheaper, more common version is just drift: a team optimising honestly against whatever they've been told matters this quarter, while the thing that actually matters shifts underneath them every time a new stakeholder gets a hearing.
I think real autonomy runs on four things, and a team is missing at least one of them far more often than leadership realises.
A strategy that actually resolves conflicts. Not a slide with four priorities on it, but a working answer to which one wins when two of them can't both happen this quarter; furthermore, a product strategy can only do that if there's a business strategy above it to resolve conflicts against. When I wrote the first product strategy for one business, I built it around Richard Rumelt's kernel of a diagnosis, a guiding policy and coherent actions.¹ It explained what we were trying to achieve and why it mattered, ranked the priorities rather than simply listing them, and framed each one as a hypothesis with the signals that would tell us whether we were right. I think the most important section, though, was the one setting out what we would not do, each item with its reason, from deepening investment in a platform we hadn't yet decided to keep, to using AI where a simpler, safer or cheaper alternative existed. We wrote it knowing those choices would be tested by every incoming request and would need actively defending, because a strategy that never says no isn't making any choices at all. Without that, prioritisation stops being a product decision and becomes whichever voice was loudest.
Real access to the numbers. P&L, cost data, the financial reality the business is actually optimising for, not a summary of it filtered through someone else's interpretation. In one role, I was handed a specific margin-improvement brief from above. Rather than take it at face value, I asked for direct P&L access, found the proposed fix would achieve very little, and pointed at a bigger lever sitting right there in the same numbers. The best example I've seen, however, was at another business where access was offered. The CFO stopped me in the office and asked whether I had ten minutes to help him understand a billing problem caused by a change in how commissioners set their fees. Ten minutes turned into a cross-departmental analysis with Finance and Delivery, and a short- and longer-term plan that recovered a significant sum that would otherwise have been lost. What made that possible was a CFO who saw product as a function able to understand a messy system end to end, and who opened up the numbers to us rather than handing over a ticket. In both cases, the result was simply what happens when you let someone see the thing they're meant to be improving.
A product operating model the business actually honours, not just approves in a slide deck. I've built teams out of a pure feature-factory model into something outcome-led: problem, outcome, discovery, hypothesis, experiment, evidence, then scale, iterate, or stop. I've implemented evidence cards, outcome reviews, product and design crits, and a decision log nobody has to reconstruct from memory. None of that is exotic; Marty Cagan has been describing the difference between feature teams and empowered teams for years.² What undermines outcome-led working usually isn't the model itself; it's leadership treating the model as the default right up until a senior stakeholder wants something built their way, at which point it quietly stops applying for exactly as long as that person is unhappy.
Direct, regular contact with the people who actually use the product. Not a research phase that happened eighteen months ago and got turned into a persona nobody revisits. Weekly, structured user research that is close enough to the work that it changes decisions rather than decorating them.³ This is also, not incidentally, where product earns the right to sit in the room in the first place: it's usually the only function that has both the business's stated priorities and an honest, current picture of what's actually happening on the frontline, and the gap between those two things is frequently where the real opportunity sits.
Take any one of those four away and what's left isn't autonomy, it's exposure. A team can be told they own an outcome and still be set up to fail at it, quietly, in a way that reads as their fault twelve months later.
The worst version of this is the business with no real strategy at all, although it rarely thinks of itself that way. What it usually has instead is a shared understanding of whatever it's currently focused on, often the founders' latest thinking, which feels like strategy from the inside because everyone can describe it, yet has none of the diagnosis, guiding policy or coherent action Rumelt describes. Without that, the business becomes reactive by default, and every external shock (a competitor's launch, a regulatory change, a difficult quarter, a loud customer) arrives as the new top priority.
Product teams absorb the cost of each of those pivots, and I think it's one of the most consistently underestimated costs in product organisations. Every time a roadmap is torn up, the team loses the lead time it had built for discovery, ideation and design, yet it's still expected to deliver the new priority at speed. The only way to do that is to skip the work that makes delivery worthwhile, which means shipping unvalidated solutions to problems nobody has properly understood; furthermore, when those solutions underperform, it tends to read as a product failure rather than a strategic one. The loop then reinforces itself: weak results erode leadership's trust in product, lower trust brings less autonomy and more top-down direction, and more top-down direction means the next pivot lands even harder. The human cost compounds alongside it, because there are few things more demoralising for a team than repeatedly abandoning good work half-finished, for reasons that change faster than the work can.
Melissa Perri has a name for a shallower version of this failure, the build trap, where a business measures itself on output because it's never worked out what outcome it's trying to buy.⁴ The reactive version is worse, because at least a build-trap company is consistent about what it's getting wrong. A business that keeps changing its mind isn't giving product a hard target to hit; it's giving them no target at all, and the customer, who was the actual point of any of this, waits.
What I'm asking for is narrower and much harder than it sounds: give any function the same information you'd expect it to have before holding it accountable for what it does with that information. If you wouldn't judge your finance team's forecasting without giving them the actuals, or your engineering team's architecture without telling them the real scale you're building for, I'm not sure why product is any different.
Giving product autonomy doesn't mean leaving teams to do whatever they want. It means giving them a clear strategy to work within and access to the information they need, then trusting their domain expertise and their proximity to customer problems enough to let them propose a roadmap they believe meets both customer and business needs; in return, leadership gives those proposals due consideration rather than treating them as a formality. Not every proposal I've made has landed, nor do I think it always should. In the past, I've made the case for developing a product into a SaaS offering, but was told no by a board that had good reasons for saying so; the case was sound, the board's call was still defensible, and the two things can both be true at once. Wanting more autonomy for product doesn't mean product is always right; it means product should be trusted to make its case with the same information everyone else in the room has, and to accept the answer when it loses the argument on the merits.
If you lead a business and you're frustrated that product isn't delivering the impact you know it's capable of, the more useful question probably isn't about the team. It's whether you've actually given them the strategy, the numbers, the model, and the access that impact requires, or whether you've just given them the backlog and the blame; and if you haven't yet, that's good news, because it's a far easier problem to fix than a talent gap.
¹ Richard Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters (Crown Business, 2011)
² Marty Cagan, EMPOWERED: Ordinary People, Extraordinary Products (Wiley, 2020)
³ Teresa Torres, Continuous Discovery Habits (Product Talk LLC, 2021)
⁴ Melissa Perri, Escaping the Build Trap (O'Reilly, 2018)