Optimize for the Problems You Want to Have
Only build features that stop people from reaching the point where they'd ask you for more.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 3
- Confidence
- 93%
When deciding what belongs in an MVP, Belsky reframes prioritization around the problems you'd be lucky to have. Ship only what removes the brick walls preventing users from getting through the funnel and feeling successful; defer every feature that customers can only ask for once they already value the product. The tell that you're doing it right is users saying 'now I need it on this platform' or 'now let me share this.'
Origin
Scott Belsky's prioritization heuristic, articulated in his advice to product teams and paired with his 'do half of everything' learning from Behance's early years.
Core principles
- 01A 'problem you want to have' is a request that only exists because the user already got value.
- 02Eliminate the catastrophic brick walls first: sign-up, account connection, third-party login.
- 03Deferring a feature is correct if its absence only surfaces after the user already cares.
- 04The MVP's job is to get people to the point of caring, nothing more.
How to run it
- 1
List the brick walls
Identify every major-catastrophe failure that can stop a user before they feel any value: broken sign-up, no way to connect an account, missing Google login.
Pro tip These are non-negotiable; they get built first regardless of how unglamorous they are.
- 2
Sort every other feature by when the need appears
For each proposed feature, ask whether its absence blocks reaching value, or only becomes a complaint after the user is already succeeding.
Pro tip If the complaint can only occur post-value ('I want it on another platform', 'let me share this'), that is a problem you want to have.
Watch out Do not hedge by shipping everything up front; it produces a complicated, unfocused first experience.
- 3
Ship the walls, defer the rest
Build only the brick-wall removers for launch and hold every 'want-to-have' feature until users actually ask.
Pro tip Their asks become your validated roadmap, prioritized by real demand rather than guesses.
In the wild
Unsure whether users wanted groups, a tip exchange, portfolios, or work-in-progress sharing, Belsky hedged and launched with nearly all of it, producing the most complicated version of Behance at the very beginning.
→ Only after killing features did the core metric accelerate, teaching him to defer hedged features instead of front-loading them.
Common mistakes
Hedging with features because you're unsure what users want
Shipping every possibility to cover your bets produces a bloated first experience that buries the core action and confuses new users, as Behance's overloaded launch showed.
Building features that presuppose the user already cares
Sharing, multi-platform support, and advanced options only matter once someone is activated; building them before you can even get users through sign-up wastes the scarce build window on the wrong problems.
Is it for you?
Best for
Founders and PMs scoping an MVP or a v1 who are tempted to hedge by building many features at once.
Not ideal for
Mature products whose users are already activated and whose growth now depends on depth and retention features.
From the transcript
“I always tell them to optimize for the problems they want to have.”
“Only do the things that prevent people from getting to the point where they care enough to ask you for anything.”
“make sure that you eliminate all the brick walls, the major catastrophe type things that can happen”
From the episode
Lessons on building product sense, navigating AI, optimizing the first mile, and making it through the messy middle
Scott Belsky (Adobe, Behance)