Who owns what, and what you cannot order anyone to do
Lesson 2 of 24, level 01Index
You have picked a problem. The designer says the fix needs a full flow redesign, the engineer says the flow is fine and it is a data bug, and support says both are missing the point. You have authority over none of them.
The three chairs
Every product decision has to answer three questions, and each one belongs to a different discipline. Is this worth doing? Can we build it, and at what cost? Is it usable?
A product manager does not sit in one of those chairs. You sit in the middle, and your job is to make sure all three questions get honestly answered before anyone commits. When three smart people disagree it is almost always because they are optimising different things and nobody has said so out loud.
- Product Owner
- Grooms the backlog for one team. A subset of the PM role, not a synonym.
- Product Marketing
- Owns how it is positioned and sold. Different question, adjacent seat.
- Engineering Manager
- Owns the people and the delivery. You never direct their team.
Product, design and engineering share a decision, but they contribute different evidence. Your role is to make the disagreement explicit enough to resolve.
Use your chosen course project throughout. The additional examples below are fictional practice cases; transfer the method to your own evidence.
Name the question each person answers
Product asks whether the outcome is worth pursuing. Design asks whether a person can understand and use the proposed experience. Engineering asks whether it can be built and operated within the constraints. A strong proposal can fail any one of these tests; enthusiasm in one discipline does not answer another discipline's question.
Distinguish constraints from preferences
“The provider cannot return this field” is a constraint to investigate. “A modal would look cleaner” is a proposed solution. Write the constraint independently from the person's preferred implementation. Once the team sees the underlying restriction, several better options may appear without anyone having to lose face.
Write the trade-off and the owner
A decision note should say which option was chosen, which credible option was rejected, the evidence behind the choice and what would trigger a revisit. Name who owns execution and who needs to be consulted. This prevents the room from leaving with three different versions of what was decided.
One decision, three evidence requirements
- Decision: What should change?
- Value: Worth the cost?
- Usability: Can people do it?
- Feasibility: Can we operate it?
How Spotify handled it
Spotify
Spotify's much copied squads and tribes structure gave every squad a PM, a designer and engineers, with no manager who could order the squad what to build.
It worked at Spotify and failed at most companies that copied it, because the copies took the org chart and skipped the part that made it work: squads owned a metric. Without an owned outcome, autonomy just means nobody agrees and nothing ships. Spotify's own engineers later published that the model was aspirational and never fully implemented even internally.
Influence comes from owning an outcome and having the best picture of it. Not from a title, and not from a process diagram.
Doing it with AI, and where it breaks
Run the argument as a simulation. Give a model three system prompts, a designer protecting coherence, an engineer protecting the sprint, a support lead protecting ticket volume, and argue your case until you find a framing all three accept.
The model is too agreeable. If it concedes in under three exchanges it is role playing politeness, not the person. Add “do not concede unless the argument addresses your specific concern, and push back at least three times”.
Your AI workbench
Start with your own notes or clearly labelled practice data. Remove private details before sharing. Replace the placeholders, run the prompt in your chosen AI tool, and keep the output beside its source.
Role-play a design lead and an engineering lead reviewing my proposal. For each, state the question they must answer, the evidence missing and one alternative. Separate constraints from preferences. Do not invent capabilities of our API. Finish with a decision table that leaves unknowns explicitly unresolved. Here is my proposal: [paste it].
Before you use the output
- Confirm technical constraints with an engineer
- tie design objections to a user task
- state which trade-off you personally own.
Stuck? Try this next
Use the simulated disagreement to prepare questions, not as evidence that a real colleague agrees. Bring the unanswered questions to the actual team.
Keep a brief AI log: input used, useful output, what you checked, and what you rejected. The decision remains yours.
Build it
A one paragraph decision note that states the disagreement plainly and the call you are making anyway.
Claude or ChatGPT
The worked solution
Stuck, or want to compare?
There is a worked solution. Try the build first. Reading it before you have attempted anything is the fastest way to learn nothing.
Checkpoint
If you did the build, these take two minutes. If you cannot answer one of them, that is the part to go back to.
Moving on marks this lesson complete. Finish the build first, it is the part that counts.