Bring Problems, Not Prescriptions
Align teams on the problem owner, then let specialists shape the solution
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 98%
When collaborating with a specialist team, bring a well-evidenced problem rather than a predetermined implementation order. Clarify who is accountable for identifying and prioritizing the problem, then involve engineers, designers, or other specialists in shaping the solution. State customer needs, evidence, constraints, and desired outcomes while avoiding unnecessary prescriptions about how the work must be built. If conflict continues, inspect whether participants disagree about who owns the problem definition or who supports solution development. Explicit decision rights convert a waiter-and-chef dynamic into joint problem solving, preserve specialist judgment, and make proposed solutions easier to evaluate against a shared objective.
Origin
Extracted from Marketing Against The Grain's discussion of Brian Chesky's waiter-and-chef metaphor for the relationship between marketing and engineering.
Core principles
- 01Engineers are problem solvers rather than order takers
- 02Problem definition and solution design are different responsibilities
- 03Cross-functional conflict often begins with disputed problem ownership
- 04Specialists should help create the solution
- 05Clear roles reduce unproductive control battles
How to run it
- 1
Frame the problem
Describe the customer or business condition that must change, including evidence of its importance.
Pro tip Separate observed facts from your preferred implementation.
Watch out A feature request disguised as a problem statement still constrains solution thinking.
- 2
State constraints and outcomes
Clarify required boundaries, success criteria, timing, and risks without prescribing unnecessary technical details.
Pro tip Explain why each hard constraint exists.
Watch out Do not label preferences as immutable constraints.
- 3
Assign problem ownership
Agree on who is accountable for identifying, prioritizing, and refining the problem.
Pro tip Use one accountable owner even when many people contribute evidence.
Watch out Ambiguous ownership encourages repeated authority disputes.
- 4
Co-create solutions
Invite the relevant specialists to develop and compare ways to solve the agreed problem.
Pro tip Ask engineers and designers to expose trade-offs early.
Watch out Do not treat specialists as order takers.
- 5
Select against the problem
Evaluate solution options by how well they address the shared outcome within the stated constraints.
Pro tip Return to the original evidence when preferences collide.
Watch out Avoid choosing solely by seniority or functional politics.
- 6
Diagnose recurring conflict
When collaboration breaks down, inspect whether the true dispute concerns problem ownership or solution authority.
Pro tip Restate decision rights before debating another proposal.
Watch out Do not mistake an ownership conflict for a personality conflict.
In the wild
Marketing observes that qualified customers abandon setup after a confusing integration step. Instead of ordering engineering to build a specific wizard, it presents recordings, abandonment data, constraints, and the desired activation outcome. Engineering and design propose several lower-cost solutions and jointly select one.
→ The team solves the underlying customer problem without reducing engineering to an order-taking function.
Common mistakes
Delivering a menu of orders
Dictating exactly what specialists must build prevents them from applying their problem-solving expertise.
Bringing an undefined complaint
Avoiding prescriptions does not excuse weak framing; teams still need evidence, constraints, and a clear outcome.
Leaving ownership implicit
Unclear authority over problem definition causes functional conflict to reappear during every solution debate.
Is it for you?
Best for
Cross-functional product, marketing, design, and engineering teams solving ambiguous customer problems.
Not ideal for
Routine, fully specified implementation tasks with established solutions and unambiguous technical ownership.
From the transcript
“engineers are problem solvers, not order takers.”
“Basically bring problems, not solutions, and articulate problems, not try to like just give orders, give solutions.”
“most conflict within a company is rooted in who is the person identifying the problem to be solved.”
From the episode
Airbnb Just Copied Apple’s Product Development Strategy... Here’s Why (#138)