Think-First Problem Selection (The Anti-MVP)
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- —
Ek openly rejects the minimum viable product orthodoxy. His argument: cheap experimentation removes the pressure to think, so founders run faulty experiments — and because the first experiment dictates the subsequent ones, an under-thought start compounds into an under-thought business. The real MVP is thinking, which is cheap. The method is to invest serious time defining what value you create and for whom before any building, and then — since Ek believes the total work ends up roughly the same either way — deliberately choose the harder problem, because hard problems create more value than simple ones. He pairs this with a caveat: most people never start at all, so thinking must terminate in action, not replace it.
Origin
Extracted from Deep Dive with Ali Abdaal
How to run it
- 1
Answer 'what value, for whom' in writing
Before code, before design, force yourself to state precisely how value is created and who receives it. Ek says the entrepreneurs he meets have consistently under-thought the space, the solution, and the value created — and that pain arrives later as expensive rework.
Pro tip If you can't name the person who gets the value, you haven't finished this step.
- 2
Treat the thinking as the real work
Ek argues the thinking exercise is a big effort regardless of whether the implementation is fast or slow. Budget days or weeks for it explicitly, rather than treating it as a preamble to the 'real' build.
Pro tip Thinking is cheap in money and expensive in discipline — schedule it or it won't happen.
- 3
Sequence experiments deliberately
Because the first experiments dictate subsequent experiments, choose the first test for what it teaches, not for what is easiest to ship. A careless first experiment sets a trajectory the whole company then inherits.
Watch out Cheap experiments tempt you to skip the reasoning entirely — that's how they end up faulty.
- 4
Compare a hard problem and an easy one at the same work level
Ek's observation is that things end up being about the same amount of work anyway. So put a hard version and a simple version of your idea side by side and price the effort honestly — usually the gap is smaller than it feels.
Pro tip Ask which version you'd still be interested in three years from now.
- 5
Pick the hard one and take the value asymmetry
If the effort is comparable, choose the harder problem: tackling something really hard makes it more likely you create a lot of value than tackling something simple. Ek frames this as shooting for the stars and landing on the moon.
Watch out Ek half-concedes this may be post-rationalisation for his own taste in difficult businesses — test it against your own appetite.
- 6
Start, and let commitment carry you
Thinking must end in action. Ek notes that merely starting puts you ahead of 99% of people, and that being 'half pregnant' — a team depending on you — is what forces you through the moments you'd otherwise quit.
Pro tip Manufacture the dependency early: a co-founder, a customer, a public deadline.
In the wild
Rather than launching a quick audiobook MVP into an entrenched publishing market, Spotify spent the better part of two years understanding what publishers' issues fundamentally were before introducing the model. The thinking phase surfaced the actual structural insight — one dominating player, stagnant on innovation, in a category where audiobooks are massively under-penetrated at roughly 5% of the US market versus about half in Germany and Sweden. Only then did the model take shape: bundle audiobooks into existing Premium subscriptions to deliver scale to publishers immediately.
→ A launch model that arrived with publisher buy-in and instant scale, rather than a fast experiment that would have had to be unwound.
A developer spends a weekend shipping a habit-tracking app because it's cheap to build. It gets modest traction, so he spends a year adding features. Only when growth stalls does he ask who the product actually creates value for — and discovers the answer is a segment he never designed for. Applying Ek's order of operations retroactively, he writes the value statement first, realises the genuinely hard problem is behaviour change rather than tracking, and rebuilds around it. The wasted year was not the building; it was the reasoning he deferred.
→ A year of feature work discarded because the first cheap experiment silently set the direction for every experiment after it.
Common mistakes
Using cheap builds as a substitute for thinking
When shipping is cheap, you stop being forced to think things through, and the experiments end up faulty. Speed of iteration doesn't rescue a project aimed at the wrong problem, because the first experiment shapes every one that follows.
Thinking forever and never starting
Ek is explicit that getting started is the hardest part and the failure mode for 99% of people. Analysis that never terminates in action fails the framework just as badly as building without analysis.
Picking easy problems to reduce risk
If the total work is roughly the same either way, choosing the simple problem buys no safety — it just caps the value created. Ek's interest is in big problems, not gimmicky things people find amusing for a week.
From the transcript
“I actually don't subscribe to the theory at all I'm I'm kind of um opposed to minimal viable products um instead I think you should…”
“you might just as well tackle something that's really hard because if you tackle something that's really hard it's more likely that you create a…”
“there aren't a lot of high quality people spending thousands of hours thinking about how to solve a certain problem you're very likely to come…”
From the episode
Spotify Founder: “Your Music Taste Could Signal The Books You NEED to Read” - Daniel Ek
Daniel Ek