Problem-First, Wheelhouse-Checked, Unit-Economics-Proven
Three gates a product idea must pass before you build the solution you already fell in love with.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 90%
Jiaona Zhang (VP Product at Webflow, formerly Airbnb) identifies the single hardest habit to untrain in product people: jumping to solutions. Airbnb Plus is her case study — a competitor-fear-driven, solution-first program to inspect and manage inventory. The framework forces three gates before a solution is allowed: name the actual user problem, check it's in your strategic wheelhouse, and prove the unit economics at the start rather than assuming scale will save them. Then solve per-problem with targeted instruments, not one blunt one.
Origin
Jiaona Zhang's account of Airbnb Plus, launched during the rise of managed marketplaces (Sonder et al.) when Airbnb was, in her words, 'competitor afraid'.
Core principles
- 01Do not think at all about the thing you want to build; start with people in the real world and their problems.
- 02Competitive fear produces solution-first thinking dressed as strategy.
- 03A solution outside your strategic wheelhouse asks the company to build a whole new muscle from the ground up.
- 04Magical thinking about unit economics — 'it'll work out at scale X' — is where the money dies.
- 05Prefer the instrument your platform already generates for free (reviews) over the one you must operate (inspectors).
- 06One blunt instrument for all listings is worse than a targeted solution per problem.
How to run it
- 1
Untrain the solution attachment
Notice the solution you're already carrying in your head — 'I want to build X startup', 'let's inspect our inventory'. Name it explicitly and set it aside. Explicit naming is what stops it from silently steering discovery.
Pro tip Watch for competitor fear as the tell. If the sentence starts 'what are we going to do about [competitor]', you are in solution space, not problem space.
- 2
Name the real user problem
Go out and understand the problem before deciding an opportunity exists. Airbnb's real problem wasn't 'our inventory is unmanaged' — it was 'people want to know what they're getting themselves into; we need to represent the homes a lot better'.
Pro tip Say the problem in the user's voice. 'I don't want to stay in someone's home, I don't know what it'll be, it's unpredictable' is a problem. 'We need managed inventory' is a solution.
Watch out A solution restated as a problem passes this gate falsely. Test: does your problem statement mention any part of your product?
- 3
Check the strategic wheelhouse
Ask what your company's actual strength is, and whether the candidate solution sits in it. Airbnb was a platform and marketplace, not an operations company. Physical inspection required building an ops muscle from zero — extremely difficult, and not the thing they were good at.
Pro tip If the solution requires a capability you'd have to hire an entirely new org to acquire, that cost belongs in the decision, not the roadmap.
- 4
Prove unit economics at the beginning, not at scale
Do the per-unit math before committing. Sending inspectors and pillows against a modest per-booking take rate does not close, and no amount of scale changes that. Reject 'when we get to scale X it'll all work out'.
Pro tip Write the per-unit contribution as a single arithmetic line. If you can't, you don't have unit economics, you have a hope.
Watch out Magical thinking around unit economics is the specific failure mode. Scale magnifies a negative unit margin, it doesn't fix it.
- 5
Match instrument to problem, listing by listing
Decompose the quality problem into its actual components — cleanliness, lockouts, accuracy of representation — and pick the cheapest instrument for each. Guest reviews are essentially free signal. A lockbox is cheaper than an inspector. A local cleaner partnership is cheaper than an inspection. Target the specific listing's problem rather than applying one blunt instrument to all.
Pro tip Rank candidate instruments by cost-per-listing-per-problem. The ranking usually inverts the intuitive solution.
In the wild
During the rise of managed marketplaces, Airbnb — competitor-afraid — went hard down the solution space: inspect our inventory, manage our inventory, guarantee a quality bar. The real problem was that guests couldn't predict what they were getting. Airbnb had no operations muscle, and the unit economics of dispatching inspectors and shipping pillows against a per-booking take rate never worked.
→ Zhang's verdict: the unit economics were never going to work, and they should have known — or dug into it — at the very beginning. Cheaper, more targeted instruments (reviews, lockboxes, local cleaner partnerships, better home representation) addressed the same underlying problem.
Common mistakes
Getting attached to a solution
The most common and hardest-to-untrain PM error: arriving with a thing you can see in your head that you want to build, then running discovery that confirms it. The fix is to start from users and their problems and only then ask whether there's an opportunity.
Magical thinking around unit economics
Believing that at some future scale the numbers will resolve themselves. If the per-unit math doesn't work at the start, scale makes the losses bigger, not smaller.
One blunt instrument for every listing
Inspection was a single heavy tool applied uniformly. Different listings had different quality problems (cleaning, access, misrepresentation), each with a much cheaper targeted fix.
Is it for you?
Best for
Product leaders under competitive pressure who are about to greenlight an operationally heavy program to defend against a rival's model.
Not ideal for
Cheap, reversible software experiments where the cost of running the solution is lower than the cost of the analysis.
From the transcript
“we went really hard down the solution space we essentially were like let's go inspect our inventory”
“there are things where I think you have like magical thinking around unit economics you're like well when we get to the scale of X…”
“what as a company is your strategic strength and like what's in your wheelhouse”
“it is actually cheaper to go send everyone a lockbox than to deploy an inspector”
From the episode
Failure