Bo Frese
There's a lot of talk about agile these days. Does it work? 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 many years I've worked inside organisations that struggle to make both work together. I've also seen it done well, almost always by a small, focused team with real ownership of the outcome, whether it was a standalone company or a product unit inside a larger one.
The difference isn't the methodology. It's ownership.
What ownership feels like
In the dot-com era I was technical lead and partner in the startup Bass Consulting. There were five to ten of us, depending on where we were in the project, and we were accountable for everything: the users we built for, the architecture, the code and the commercial outcome. When something was wrong, there was nobody to pass it to. The gap between what we had shipped and what users needed landed directly on us.
What I noticed was how differently we made decisions. We didn't wait for the next planning meeting to fix something confusing in the interface, and 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 both for whether users value the product and for how well it's built, you can't sacrifice one to optimise the other. Both are yours, and that changes how every decision gets made.
What fragmentation does
In large organisations, ownership gets divided. That isn't a mistake, it's how you manage complexity at scale. Product management owns what to build, engineering owns how to build it, and architecture owns the big technical decisions. Each function has clear accountability for its own area.
What disappears is accountability for the outcome. The product manager is accountable for the backlog, the engineer for the ticket and the architect for the diagram. Nobody is accountable for whether the product is good: whether it solves the user's problem, works reliably and can be improved without the team spending six weeks untangling what built up while everyone was hitting their individual targets.
I've been in that room. A team shipping every sprint, velocity looking healthy and the product owner proud of the roadmap progress, while the product quietly drifted away from what users needed and technical debt piled up just below the waterline. Everyone was doing their job, and nobody was looking at the whole.
The people in these functions care a lot about their work. It's the system that measures the wrong thing:
You get evaluated on your contribution to the process, not on whether what you built mattered to anyone.
Coordination is not ownership
Every framework, whether it's agile, SAFe, OKRs or PI planning, is an attempt to coordinate the fragments, to create enough alignment between functions that the product outcome doesn't fall through the gaps.
That's a completely rational response. If ownership is fragmented, you coordinate the fragments. It just doesn't solve the problem.
You can have daily standups and still have nobody accountable for whether the product works. You can run PI planning every quarter and still have the business and engineering living in separate worlds. You can have OKRs that everyone signs off on, and still manage them as numbers to hit instead of outcomes to pursue.
This is why so many transformations end where they started. The organisation puts the coordination in place, with ceremonies, cadences and frameworks, and two years later finds that nothing fundamental has changed. The business is still on one side and engineering on the other, and 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 a large organisation, the answer is usually some version of "we all do". The whole team, the whole product group, collectively.
In practice, collective ownership tends to become diffuse accountability. That's not because people don't care, but because the system doesn't connect the consequences of a failure to any specific decision or person:
- When a feature misses the mark, whose problem is it?
- When the codebase has built up so much 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.
Nobody designed it this way. Diffuse accountability grows because it's comfortable for everyone involved, while concentrated accountability is uncomfortable. The problem is that you can't build great products without it.
The question I ask instead
Instead of asking whether you're doing agile correctly, ask this:
Who in your organisation wakes up at 3am because the product is failing its users?
It's a useful question because you can't fake the answer. Responsibility can be spread across a committee. The 3am feeling can't.
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 an ownership problem, and no framework is going to solve it.
The organisations I've seen consistently build great products have someone, or a very small group, with real authority over the product outcome and real accountability for it. That means authority over whether the product works, not just over the roadmap, and accountability to the result, not to the process.
That person has to be close enough to the technical reality to know when quality is being traded for speed in ways that will cost more later, and close enough to the users to know when the product is drifting from what they 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 slowly erode the quality. Someone who owns how it's built but not whether it's right will build the wrong thing very well.
What I care about
You might call the answer agile, or 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 closeness to users and code, and the accountability to make the decisions that matter. Not to coordinate the people who make them, but to make them, feel the consequences when they're wrong, and adjust without waiting for the next planning cycle.
That's rare in large organisations, and it's the most important thing. Everything else is coordination. It's useful and often necessary, but it isn't ownership.