Put the Whole Problem in the Room
Even when product managers don’t control the decision, they can shape the shared context it’s based on.
The feature has already been promised. Sales committed to it last week to save a deal, and now the room is arguing about how to build it. Nobody is arguing about whether. That got decided somewhere else.
Sales sees a deal that’s losing momentum and could disappear this quarter. Engineering sees a system they’ll still be maintaining two years from now. The CEO is thinking about runway, payroll, the last board discussion, and maybe the last company they nearly ran into the ground. Product is thinking about customers who aren’t in the room.
For years I thought people argued about product decisions because they disagreed. I don’t anymore. A lot of the time they’re looking at the same situation from different reference frames. More often than you’d think, they aren’t looking at the same problem at all.
Each person has a real piece of it. Trouble starts when one piece gets mistaken for the whole thing. Then everyone argues about the answer before they’ve agreed on what is actually happening.
I used to think alignment meant getting people to agree. Now I think it starts earlier than that. You have to get enough of reality onto the table for the disagreement to mean anything.
Marty Cagan’s answer, roughly, is the empowered product team. Give good people a problem, give them the context, let them decide how to solve it. I like that answer. A lot. I’ve spent much of my career trying to build teams that way. It also requires the people running the company to give up decisions, and most won’t.
So, sales promises the feature. The CEO changes the roadmap. Another large customer jumps the queue. The team gets handed a solution, a deadline, and occasionally the opportunity to perform some post-decision discovery.
The product world tells those PMs they’re working in a feature factory. Accurate. Okay, but then what? They still have to show up Monday morning.
I think representation is part of the answer. I know. It’s a clumsy word. A little academic. I keep coming back to it because I don’t have a better one yet.
What I mean is the picture of reality sitting behind a decision. Every decision has one. Usually it’s invisible. Often it’s accidental.
It might be a heated call the CEO took from a customer threatening to leave. A revenue number nobody questioned. An engineering constraint nobody explained properly. A story sales has repeated so often it has hardened into fact. A conviction someone has been carrying around for ten years.
That picture becomes the basis for the decision whether anyone admits it or not. And nobody can hold the entire company in their head. We have to compress.
DNA does this. Four bases carry a compressed set of instructions that, in the right environment, becomes a living organism. A financial model does it too, compressing a company into a set of assumptions and relationships you can change, test, and argue about.
Neither contains every detail. That would defeat the point. A useful representation keeps the details that matter for the job in front of you. A bad one throws away the thing that should have changed your mind.
Organizations do this constantly, mostly without thinking about it. A roadmap is a representation. So is a dashboard, a forecast, a customer journey, or a spreadsheet somebody made three years ago that now quietly runs half the company.
Unfortunately the most important representations never get written down. They live in the heads of your most experienced people.
The CFO knows which vendor is bluffing. The engineer knows which “small” feature will crack open six months of platform work and a wasp’s nest of accumulated technical debt. The account exec knows the customer is threatening to leave but probably won’t. The founder knows which assumptions in the plan are real and which ones were invented for the board deck.
This is what expertise actually is. Not more facts. A better compressed model of the situation. Experts know what matters, what can be ignored, and which small signal means the whole thing is about to go sideways.
Then that person misses the meeting, goes on vacation, or leaves the company, and everyone discovers how much of the operating model was living in somebody’s head.
The point of representation is to make more of that knowledge usable by the group. You are trying to give the team access to what the expert sees. That does not mean documenting every thought anyone has ever had. Nobody will read it, and it won’t help.
The hard part is finding the smallest representation that still preserves what matters. What’s happening. Which parts are still guesses. Why the team believed any of it in the first place.
Back to that promised feature. It’s going to be tough to undo, but step back anyway. What problem is the customer actually trying to solve? How much revenue is truly at risk? What will it cost to carry for the next five years, and what gets delayed while you build it?
Get those things into the same frame. Maybe the CEO still says yes. Maybe yes is the right answer. At least now yes has a shape, and everyone can see the trade being made.
Write down the assumptions too. Companies are astonishingly good at forgetting why they made a decision. Six months later, every bad bet was apparently forced on them and every good one was obvious from the beginning. Corporate fan fiction.
A usable representation gives the organization something to learn against. We believed this customer represented a larger market. We thought the integration would take six weeks. We assumed the sales team could sell the feature separately. Then reality shows up and you get to see where your model was wrong.
Without that, the company does not improve its judgment. It just accumulates stories.
This goes well beyond product meetings. Complex organizations spend a ridiculous amount of time trying to establish what is actually true before they can decide anything. Usually the information exists somewhere. It is scattered across dashboards, documents, Slack threads, customer calls, spreadsheets, and the heads of people who weren’t invited.
Someone has to assemble it and it most likely it will be you.
Then a customer changes direction. The numbers come in wrong. The picture has to be rebuilt. That is a huge amount of what we call coordination: keeping enough shared reality intact for a group of people to act together while the world keeps changing.
And to what end? Better decisions. That’s it.
The veteran still matters. Their judgment matters enormously. The goal is to make more of what they see available to everyone else. That is how a team gets smarter without adding another meeting.
It is also the practical agency available to a product manager who does not control the decision. You may not own the roadmap. You may not have the final word. You may work for a CEO who changes direction in the room or a sales team that makes commitments before product hears about them.
You can still improve the representation. Expose the assumptions. Add the missing customer. Show the engineering consequence. Put the opportunity cost beside the revenue. Some leaders will ignore all of it. A product manager cannot diagram their way out of a power problem.
But a lot of bad decisions have a more ordinary cause: everyone had a piece of the truth and nobody assembled it.
Put the whole problem in the room.