"That looks good in theory, but won't work in practice"

"That looks good in theory, but won't work in practice."

I have heard that sentence in enough rooms to know what it usually means. It is rarely a critique of the theory. It is a way of ending the conversation before anyone has to change anything.

Here is the version of it that made me write this down.

The scale-up that had outgrown its founder

I spoke with a scale-up struggling with the usual pitfalls of building both a scalable product and a scalable product organisation. Three things stood out, and in my experience they always travel together:

• Product development was CEO-driven. The founder decided what got built.
• The PMs were junior, and their attention went entirely to delivery and output.
• The product teams avoided talking to customers. When they proposed anything themselves, it was a tech stack improvement.

None of this was a problem for the first few years. The founder's intuition was good, the market was one they knew personally, and moving fast on a strong hunch beat any process you could have installed instead.

Then two things happened at the same time. The company got big enough that one person's intuition could no longer cover every decision. And it expanded into new geographies, where that intuition simply did not apply. The product was not adapted to those markets, and nobody in the building could explain why, because nobody was talking to the people in them.

What I actually proposed

They asked what I would change. Three things, in this order.

A product strategy tied to the business vision. Not a roadmap. A short list of bets the company is making, and everything it has therefore decided not to do this year. Without that, every team optimises locally and the portfolio drifts. I have written about why a strategy is mostly a list of noes, and it matters more, not less, once you are operating in several markets.

Teams empowered to drive product outcomes, in a trio setup. A product manager, a designer, and an engineer, jointly accountable for an outcome rather than a feature list. That is the whole point of the trio, and it is also the fastest way to find out whether you have a product team at all or just a delivery team with product job titles.

Dual-track, so discovery runs alongside delivery. Not a discovery phase that blocks the roadmap. Continuous work on what to build next, happening in parallel with building the thing you already decided on. The split between the two shifts with risk, not with the calendar.

That is a real change to how a company works. It is not a workshop.

"That is more of a theoretical approach"

That was the feedback I got.

And I understand it. Everything I described asks somebody to give something up. The founder gives up being the last word on every decision. The PMs have to start doing a job they have never done, in front of an audience that has never seen them do it. The engineers have to sit in customer conversations they have been protected from. The payoff shows up a quarter or three later.

Compare that with the cost of the objection. "I cannot change it." "My CEO would never go for it." "It is just theory, no company actually works like that." Those are free, they are instant, and they sound like realism. That is the trade a lot of companies are quietly making.

I think this is why so many organisations stay stuck. Not because they cannot see what is broken. They can describe it in detail. They are just more afraid of the change than of the status quo, so they need a reason the change is impossible, and "theory" is the cheapest one available.

Do not take my word for it

I have watched this transition happen more than once, and I am obviously not a neutral party. So if my word is not enough, use somebody else's.

Marty Cagan's TRANSFORMED is built around case studies of companies that moved to the product operating model, specifically because the usual objection is that only Silicon Valley product companies can work this way. Teresa Torres's Product Talk has been documenting how real teams run continuous discovery for years, including the parts that go badly.

Read them and disagree with the specifics if you want. What is hard to maintain after that is the claim that nobody works like this.

Where it actually starts

Here is the part that gets lost when this turns into a debate about models. Nobody has to reorganise the company on a Monday.

Pick one team. Give it one outcome that matters to the business, phrased as a number that should move rather than a feature that should ship. Give it access to customers and to product data. Then leave it alone for a quarter and look at what happened.

One team, one outcome, one quarter is a small enough bet that the CEO can say yes to it without believing any of the theory. It is also big enough that the result is hard to argue with, in either direction. If it works, you have evidence that beats every framework slide you could have presented. If it does not, you have learned something specific about your organisation rather than something general about product management.

That first team is usually where a product model transformation actually begins. Not with a new operating model document. With one team that gets to prove the thing is possible here.

So when the objection comes back as "that is just theory", the useful reply is not another argument. It is a question: which part of it do you think would fail here, and what would we have to see to know?