There's a lot of talk about agile these days. Does it work? Does it not? Should we try something else?
I don't care what you call it.
Product development comes down to two things: building the right product, and building it well. For the past fifteen years I've worked inside organisations that struggle to make both work together consistently. I've also seen it done well — almost always by a small, focused team with genuine ownership of the outcome, whether they were a standalone company or a product-focused unit inside a larger one.
What makes the difference isn't a methodology. It's ownership.
What ownership actually feels like
In the mid-nineties I was CTO and co-founder of Bass Consulting. Five to ten of us, depending on where we were in the project. Complete accountability for everything — the users we were building for, the architecture, the code, the commercial outcome. When something was wrong, there was nowhere to pass it. The gap between what we'd shipped and what users needed landed on us directly.
What I noticed was how differently we made decisions. Not better in theory — differently in practice. We didn't wait for the next sprint planning to fix something confusing in the interface. We didn't create a ticket for a performance problem and schedule it for next quarter. The person who felt the gap was the same person who could close it.
When you're accountable for whether users value the product AND for how well it's built, you can't sub-optimise one at the expense of the other. Both are yours. That changes how every decision gets made.
What fragmentation does
In large organisations, ownership gets divided. This isn't a mistake — it's how you manage complexity at scale. Product management owns "what to build." Engineering owns "how to build it." Architecture owns "the big technical decisions." Each function has clear accountability for its domain.
What disappears is accountability for the outcome.
Not as a policy — as a structural reality. The product manager is accountable for the backlog. The engineer is accountable for the ticket. The architect is accountable for the diagram. Nobody is accountable for whether the product is actually good — whether it solves the user's problem, works reliably, and can be improved without the team spending six weeks untangling what accumulated while everyone was hitting their individual targets.
I've been in that room. A team shipping every sprint, velocity metrics looking healthy, the product owner proud of the roadmap progress — and the product quietly drifting from what users need, with technical debt accumulating just below the waterline. Everyone doing their job. Nobody looking at the whole.
This isn't about intentions. The people in these functions care deeply.
But you get evaluated on your contribution to the process. Not on whether what you built mattered to anyone.
Coordination is not ownership
Every framework — agile, SAFe, OKRs, PI planning, whatever comes next — is an attempt to coordinate the fragments. To create enough alignment between functions that the product outcome doesn't fall through the gaps between them.
You can have daily standups and still have nobody accountable for whether the product is working. You can run PI planning every quarter and still have the business and engineering operating in separate worlds. You can have OKRs that everyone signs off on and still have those OKRs managed as metrics to hit rather than outcomes to pursue.
Coordination is not ownership.
This is why so many transformations end where they started. The organisation implements the coordination — the ceremonies, the cadences, the frameworks — and finds, two years later, that the fundamental dynamic hasn't changed. The business is still on one side. Engineering is still on the other. The product still misses the mark in ways that feel preventable.
The methodology wasn't the problem. The missing ownership was.
"We all own it"
When I ask who owns the product outcome in large organisations, the answer is usually some version of: we all do. The whole team. The whole product group. Collectively.
Collective ownership is diffuse accountability. Not because people don't care — because the system doesn't route the consequences of failure to any specific decision or any specific person.
- When a feature misses the mark, whose problem is it?
- When the codebase has accumulated enough debt that the team's velocity has halved, who carries that?
- When engineering and product have been misaligned for three quarters in a row, who is responsible for fixing it?
Everyone, which means no one.
Diffuse accountability isn't an accident. It's structurally convenient — for individuals, for functions, for the managers who sit above them. Concentrated accountability is uncomfortable. The problem is that you can't build great products without it.
The question worth asking
Not: Are we doing agile correctly?
Who in your organisation wakes up at 3am because the product is failing users?
If the answer is a committee, a steering group, a shared accountability model, or "the team collectively" — you don't have an owner. You have a coordination problem that no framework is going to solve.
Organisations that consistently build great products tend to have someone — or a very small group — with genuine authority over the product outcome and genuine accountability for it. Not authority over the roadmap. Authority over whether the product works. Not accountability to the process. Accountability to the result.
That person has to be close enough to the technical reality to know when quality is being traded for speed in ways that will compound. And close enough to users to know when the product is drifting from what they actually need. You can't split those two responsibilities and call it ownership. Someone who owns "what to build" but not "how well it's built" will consistently erode the second. Someone who owns "how it's built" but not "whether it's right" will consistently build the wrong thing very well.
What I actually care about
You might call the answer agile. You might call it something else.
I don't care.
What I care about is whether the person — or the small group — who owns your product outcome has the authority, the proximity, and the accountability to make the decisions that matter. Not to coordinate the people making those decisions. To make them. To feel the consequences when they're wrong. To adjust without waiting for the next planning cycle.
That's the rarest thing in large organisations. It's also the most important.
Everything else is coordination. Useful, often necessary.
But coordination is not ownership.