“The product manager got this all wrong!”

That’s not an epigraph. That’s a real line from a real refinement, minute forty. The last slide with the new feature’s designs is still up on the screen — the product manager did try, mind you, mapped out a dozen interconnections with the rest of the system. Silence hangs for a couple of seconds. And then our lead developer, who knew from the doorway that “they’ve brought nonsense again,” snaps. From there it goes down the usual track: uncomfortable questions about how this will get along with the system around it, the classic “we’d have to redo half the system for this” — and the product manager is sent on a long journey. Not in those exact words, of course. But everyone understood everything.

And I’m sitting in that meeting thinking: do our product managers and developers get along, tolerate each other, or wage war? Somewhere between the second and the third, it seems.

A bit of context. We’re a product company; what exactly we do doesn’t matter for this story. What matters is that the product is complex: everything is interwoven with everything, and holding it all in your head — or, as it’s now fashionable to say, in your context window — is beyond both the product manager and the programmer. The system is in its seventh year, and the age shows: pull a feature in one corner and it rattles in three others; almost any new thing drags a refactoring of the neighboring parts behind it. And our emphasis, like many others’, was on speed — piling up a thick layer of features that customers like.

The process was simple. Product managers prepared a feature almost without the programmers — sometimes they’d ask something, but more often they brought “finished” designs to the refinement. Where they got shredded. Features regularly went back for rework or quietly died from the cost of implementation. And there are no villains in this story: the product manager honestly tried and “didn’t distract” the busy engineers; the developer honestly got tired of cleaning up the consequences of other people’s decisions. The meeting that by rights should be the most interesting one — new stuff! a chance to flex your brain, get creative! — everyone simply endured. Product managers came in demotivated, expecting their portion of criticism in advance. Devs came in biased and uninterested. Discussions dragged on forever, and everyone left squeezed dry and “not in the mood.”

When I became tech lead, the first thing that came to mind was “fire everyone.” For a number of reasons irrelevant to the story, that option fell away. I had to think. Where do we fix this? Competences? Soft skills? Or are people so tired of each other that they’re against it before the content even starts? I turned that question over for weeks: in meetings, on the way home, in the shower. Every version looked plausible — and none of them explained anything.

And then it clicked. Just — “click!” — in my head. How had I not seen it before?

The product manager tries “not to distract” the programmers — and ends up solving, alone, problems they’re not competent in. There it is, the substitution of concepts. Yes, a product manager must understand the product: what works, how and why. No question. But understanding the product does not mean understanding the technical details of the implementation, the system’s constraints and capabilities. For years we demanded exactly that from people — and then acted surprised at the result.

I started thinking hard, periodically batting the topic around with Claude and in parallel hunting for what actually works against this disease elsewhere in the world. And gradually a question emerged — the one we should have been asking each other long ago.

Not “how do we build what you brought,” but — “so what problem are we solving?”

Out of that question grew a new process. The product manager no longer brings a solution. They bring a problem, a request. That’s it. We called the request a “Brief,” and the meeting where we take it apart — shaping. At the shaping session everyone speaks from their own side: the product manager — for the customer, me as tech lead — for the engineers, a bit of design, and we often invite someone from support — they’re closest of all to the customers. We work through options, look for a solution, and cut the nonsense right at the start — before weeks of someone’s work and someone’s ego have been sunk into it.

Efficiency grew severalfold. But that’s not even the main thing. The meetings everyone had endured for years stopped being torture. The developer no longer arrives pre-angered: they were invited to think, not to accept something imposed. The product manager no longer awaits execution: there’s nothing to criticize — there is no solution yet.

The whole secret fits in one line: bring the problem, not the solution. My only regret is that the “click” in my head happened in year seven, not year one.