Stuck in the messy middle of a product transformation

The hardest place to be in a product transformation is halfway.

A feature factory is at least coherent. Requirements arrive, the team builds them, velocity is the score, and everybody understands the rules even if the rules are wrong. It is miserable in a legible way.

The messy middle is different. The language has changed and the incentives have not, so you get to be wrong in two vocabularies at once. Teresa Torres named this as one of three organisational states that stop continuous discovery from taking hold, and it is by far the most common one I walk into.

How you know you are in it

Four tells. Most teams in this state have all four.

You have just learned OKRs, and the first set reads like a feature list with numbers stapled to it. "Ship the new dashboard by Q3" is written in the objective column and nobody quite wants to say why that is not an outcome.

You are moving towards trios, but the old assumptions came along for the ride. The product manager is still the one who decides. The designer is treated as the voice of the customer, which quietly excuses everyone else from talking to them. The engineers are assumed to deliver value at the moment they ship code.

Leadership genuinely cares about outcomes, and still asks for specific features by name and by date. Both things are true at once, which is what makes it so disorienting.

You can talk to customers. It just takes three emails, a legal check, a calendar negotiation and two weeks, so in practice you do it before a big decision and then not again for a quarter.

Three moves that make it worse

Asking everyone to change at once. Organisational change does not have a launch date. A reorg announcement plus a new set of rituals gets you compliance in the first month and a quiet return to the old behaviour by the third, because nothing in the incentives moved.

Fighting turf wars. You can win the argument about who owns discovery and lose the person who was going to help you do it. In a half-transformed org the boundaries are genuinely unclear, which means the fight is not resolvable by being right.

Battling opinions with opinions. Two people with no evidence will still have no evidence an hour later, and now one of them is annoyed. The only thing that ends these is a fact neither person owns.

Make one trio the bright spot

Pick one team. Preferably the one with a real bet in front of it, something the company cares about and nobody is confident about.

Put a product manager, a designer and an engineer on the discovery decisions together, not in sequence. Not a pilot programme with a steering committee and a readout. One team, one bet, working in the open. If the mechanics of forming it are the unclear part, the trio setup is worth reading properly, including the false assumptions listed above and why each one breaks the model.

The reason to start with one is not caution. It is that an argument about whether this works is unwinnable, and a team that visibly made a better decision is not an argument at all.

Make talking to customers cheap

Weekly interviews almost never die because interviewing is hard. They die because recruiting is hard, and after three weeks of chasing people the slot quietly disappears from the calendar.

So fix the recruiting, not the resolve:

• Recruit inside the product, at the moment of use. A small prompt at the point where someone just did the thing you want to understand beats a mailing list every time.
• Recruit through the people already in front of customers. Support, sales and customer success talk to your users every day. Make "would you be open to a 20-minute conversation" part of what they already do.
• Keep a standing slot. The interview fills the slot. The slot does not get created per interview, because that negotiation is where the practice dies.

Five to eight conversations gets you most of the pattern, and the mechanics of running them well are covered in talk to five customers this week. The short version: ask about the last time they hit the problem, not what they would like next.

Interview as a trio, not as a representative

All three people in the room, or at least on the call. This is the part that gets cut first and it is the part that does the work.

The designer notices the hesitation. The engineer notices the workaround that reveals what the system is actually doing. The product manager notices that this person's problem is not the one on the roadmap. None of them would have reported the other two, which is exactly why sending one person to "gather requirements" produces so little.

Then debrief together, immediately, while the disagreement about what you just heard is still live.

How it spreads

Not by announcement. You do not send a deck saying the trio worked.

You show the work: the assumptions you had, the ones that survived contact with customers, the thing you did not build as a result. Making that visible is what converts a leader who is asking for features by name, and it deserves more thought than most teams give it, which is why showing your discovery work is a discipline of its own.

The tell that it is taking hold is small and specific. Another team asks how you decided something. Not what you decided. How.

Getting an organisation from the messy middle to a working operating model is slow, political, and mostly not a process problem, which is what Product Model Transformation exists to work through with the people who actually hold the incentives.