Define What Problem Matters
The single highest-leverage PM skill: get crystal clear on which problem you're solving, first
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 90%
Asked for the one skill that most advances a product career, Shah names understanding and defining what problem matters. Not 'what should we build' but 'which problem are we solving' — because the answer cascades into pricing, business model, roadmap, prioritisation and team motivation. The framing turns feature debates ('SDK or NFT API?') from a vacuum comparison into a derivable answer. Shah concedes it's a cliché, and argues the cliché status is evidence of how true it is; the difficulty is in the application and the nuance, not the sentence.
Origin
Jason Shah's answer, grounded in his first company (a test-prep/college-readiness business he started at 15) and in current prioritisation calls at Alchemy. Lenny corroborates with Michael Pollan's observation that psychedelic epiphanies land on truths like 'love is all you need' — annoying because they are clichés, but clichés precisely because so many people found them so true.
Core principles
- 01Never compare two solutions in a vacuum. Solutions are only comparable once you name the problem they're each solving.
- 02The problem you choose determines the business model, not the other way round.
- 03A clearly-defined problem is a motivation mechanism — it tells the team why what they're building matters.
- 04It scales across altitudes: the same question governs a feature, a roadmap, and a company mission.
- 05Cliché status is not a reason to skip it. Everyone knows the answer; almost nobody does the application and the nuance.
- 06Getting crystal clear is energising, not bureaucratic — clarity is what makes people want to build.
How to run it
- 1
Catch yourself comparing solutions
Notice the shape of the debate. 'Should we build an SDK or an NFT API?' is a solution-versus-solution argument in a vacuum. That is the signal that the problem has not been defined.
Watch out These debates feel productive and can consume weeks. They are unresolvable by construction.
- 2
Name the candidate problems explicitly
Convert each solution back into the problem it presumes. Is the problem developer experience — we want things to be easier to develop? Or is the problem that a whole suite of NFT marketplaces are trying to grow and need more support from us? These are different problems with different answers.
Pro tip Writing the problems side by side usually makes one obviously more important than the other — that is the whole trick.
- 3
Choose the problem that matters, and make it crystal clear
Pick and articulate the problem with precision. Vague problem statements produce vague products. This is the artefact everything else derives from.
- 4
Derive the rest — model, pricing, roadmap, focus
Let the problem definition dictate the downstream decisions rather than deciding them independently. Shah's rule: if you had chosen a different problem, the business model would have been different — so if your business model isn't visibly downstream of your problem, you haven't actually used the problem.
Pro tip Test it: name one concrete decision (pricing, monetisation, what you cut) that changes if the problem changes. If nothing changes, the problem statement is decorative.
Watch out The failure is choosing an initial product and a business model you think can work, then retrofitting a problem to justify them.
In the wild
Shah's first company (started at 15, run for seven years) defined its problem as: low-income students don't have access to the same resources to get into college as other students. Because that was the problem, the product was free for a long time and monetisation came from college sponsorships — and the team focused maniacally on pedagogy and curriculum.
→ The problem definition directly produced the pricing model, the monetisation strategy, and the focus area. Shah's counterfactual: had the problem simply been 'there's no good college readiness program', the company would have optimised a business model and an initial product instead of the curriculum, and been a different, worse company.
As a developer platform, Alchemy faces choices like: build an SDK so there's an abstraction that's easier for developers to use, or build an NFT API because it's an important part of the stack and use case to support. Shah refuses to argue these against each other directly.
→ The debate resolves only once the problem is named — is the problem developer experience, or is the problem that a suite of NFT marketplaces need more support from us? The chosen problem picks the build.
Common mistakes
Debating solutions in a vacuum
'This versus that' with no problem statement is an unwinnable argument — there is no criterion by which either side could be right. Teams burn enormous time here without noticing the missing premise.
Choosing the business model first and backfilling the problem
If you start from an initial product and a monetisation model you think can work, you never get to the maniacal focus that a real problem produces. Shah's education company would have optimised the wrong thing entirely.
Dismissing the question because it's a cliché
People mock PMs for asking 'what problem are we solving'. Shah's rebuttal: it's a cliché precisely because so many people found it so true for so long. Everyone knows the answer, like 'your health, your family, your sense of purpose' — the whole game is the application and the nuance.
Is it for you?
Best for
Product managers and founders facing a roadmap fork or a prioritisation deadlock, and anyone whose team is arguing about what to build without agreement on why.
Not ideal for
Pure execution phases where the problem is already settled and the job is shipping — re-litigating it there is procrastination in a lab coat.
From the transcript
“like like the others but i think that understanding and defining what problem matters is the most important skill that i think i've taken away”
“well the question is what problem are we solving it's not this versus that just in a vacuum it's is the problem developer experience and…”
“and it goes back to my first company it was an education company and the problem was that low-income students didn't have access to the…”
“than say the business model and an initial product that you think can work so that's what i found to be the most useful and…”
From the episode
Building a meaningful career
Jason Shah (Airbnb, Amazon, Microsoft, Alchemy)