Chef's Menu Prioritization
Balance reported pain with capability bets customers cannot yet request.
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 88%
Simons compares product prioritization to running a restaurant. Customer feedback tells the chef what did not taste good, but diners cannot specify a dish they have never encountered. A strong roadmap therefore maintains two inputs: recurring customer pain that demands triage and informed capability bets that users are not yet able to request. The product leader allocates capacity between them, using judgment developed through years of launches and market correction. A capability bet is not accepted on intuition alone; it is bounded, shipped, and judged by real reception. Bolt's native mobile support illustrates the mechanism. Existing users were loudly requesting other fixes, and even some people inside the company questioned the priority, but the team believed instant native app creation would be a step-change experience. Its launch became Bolt's strongest reception to that point.
Origin
Faced with requests from roughly a million monthly active users, Simons used a chef-and-diner analogy to explain why Bolt could not simply rank the loudest requests. The team also had to create capabilities users did not know were possible.
Core principles
- 01Customers can report pain but cannot request capabilities they do not know are possible.
- 02A roadmap needs both repair work and new bets.
- 03Product judgment improves through repeated market feedback.
- 04A high-conviction bet still needs a bounded launch and evidence.
- 05The balance changes with the severity of current customer pain.
How to run it
- 1
Read the complaint board
Aggregate recurring customer pain and identify what is broken, confusing, or blocking value. Weight severity and frequency rather than volume alone.
Pro tip Distinguish a request for a specific feature from the underlying problem the customer is trying to solve.
- 2
Scan the capability frontier
List experiences newly possible because of technology, distribution, or partnerships. These candidates may have little explicit demand because customers have no reference point for them.
Pro tip Ask what would feel impossible or mind-blowing if it worked, not merely what users requested next.
Watch out Novelty alone is not value; connect each capability to a real user job.
- 3
Allocate both kinds of work
Protect capacity for urgent triage while placing a limited number of high-conviction capability bets. Adjust the mix when defects threaten trust or a new capability could change the category.
Watch out Giving all capacity to either side creates a brittle roadmap.
- 4
Make the bet concrete
Choose the smallest launch that can deliver the new experience and reveal whether judgment was correct. State what reception or behavior would count as evidence.
Pro tip Put chips on the table without turning one intuition into an irreversible annual roadmap.
- 5
Feed reception back into taste
Compare actual adoption and customer response with the team's expectation. Use both wins and misses to improve future judgment about unrequested capabilities.
Pro tip Document which assumption was right or wrong, not merely whether the metric moved.
In the wild
Bolt users were loudly requesting fixes and additions elsewhere, while native mobile support had little demand because most people did not know prompt-to-native-app creation was possible. The team chose to invest anyway, partnering with Expo and letting users generate and test a React Native app on a phone through a QR code.
→ Simons says native mobile support received the strongest launch reception of any Bolt feature to that point and led to thousands of mobile apps being created each day.
A product team with a long request queue reserves most capacity for reliability but protects one small experiment based on a newly available platform capability. It launches the experience to a bounded audience instead of waiting for customers to describe it first.
→ The team learns whether the new capability changes user behavior without abandoning existing customer pain.
Common mistakes
Turning votes into strategy
Customers cannot vote for an experience they do not know is possible. A request-ranked roadmap systematically excludes category-changing capabilities.
Calling unsupported instinct taste
Simons ties judgment to years of market feedback. A bet still needs a bounded launch and a result that can refine the team's model.
Neglecting painful basics
The framework balances invention with triage. Repeatedly shipping exciting capabilities while core problems remain unresolved erodes trust.
Is it for you?
Best for
Product teams in emerging categories where the technology can create experiences customers have never seen.
Not ideal for
Safety-critical or contract-bound roadmaps where unresolved defects must take precedence over exploratory capability bets.
From the episode
Inside Bolt: From near-death to ~$40m ARR in 5 months—one of the fastest-growing products in history
Eric Simons (founder and CEO of StackBlitz)