Wow-First MVP
Cut scope to the critical few features, but never compromise quality — so a flop can only mean the idea was wrong
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 90%
A counterintuitive take on the minimum viable product. Instead of shipping a scrappy MVP to a wide audience, you narrow the feature set and the user base but keep the quality, UX, and aesthetics at a 'wow' bar. The logic is diagnostic: if a polished product still fails to get traction, you know the idea is wrong rather than being unable to tell whether users rejected the concept or just a bad build.
Origin
Articulated by Dmitry Zlokazov at Revolut as their approach to launching new products, contrasted with the standard 'scrappy MVP' school.
Core principles
- 01A scrappy MVP confounds two failures: wrong idea vs. bad execution
- 02Cut functionality, never quality
- 03No product is exempt from the wow requirement
- 04Narrow the user base first, polish, then scale
- 05Polish takes time but pays off by removing uncertainty
How to run it
- 1
Assemble a small lean team
Staff a few people to build the first version, cross-functional and end-to-end responsible.
- 2
Cut functionality to only the most critical features
Narrow the product's scope down to just the essential features — but hold the line on quality, UX, and aesthetics.
Watch out Never compromise on quality, UX, or aesthetics to move faster — that is the one thing you don't cut.
- 3
Ship the wow version to a narrow user base
Release the polished, narrowed product to a small set of users to get real feedback quickly.
Pro tip Keeping the first version narrowed to a small user base lets you invest the polish without boiling the ocean.
- 4
Read the signal, then decide
If a genuinely polished product isn't getting traction, treat that as evidence the underlying idea is wrong. If retention and metrics are strong, scale it.
Watch out Do not scale before the product is polished and metrics (especially retention) are proven.
- 5
Scale across the base
Once metrics are fine, multiply the product across the full customer base for instant traction.
In the wild
Revolut launched joint accounts (an account shared with a significant other) as a narrowed, polished feature rather than a rough MVP, then scaled it across the customer base.
→ Grew to over a million active users.
Common mistakes
Shipping a scrappy version and misreading the result
When a low-quality MVP fails to get traction, you can't tell whether the idea is wrong or the product just sucks — so you learn nothing actionable.
Scaling before polishing
Multiplying an unpolished product across a large base bakes in a mediocre experience and wastes the distribution advantage.
Is it for you?
Best for
Product teams inside a company with a large existing user base and a strong quality culture, launching adjacent products
Not ideal for
Cash-strapped early startups where speed of learning outweighs polish, or throwaway experiments meant purely to test demand cheaply
From the transcript
“we can u cut down the product in terms of functionality to to just most critical features but we will never compromise on the quality…”
“when you launch a scrappy version and it's not getting traction how do you know is it because the underlying idea is wrong or maybe…”
“by forcing everyone to build a product that people will love by building a wow product we kind of cut out this part of uncertainty”
“not scale it before you polish the product”
From the episode
How Revolut trains world-class product managers: The “local CEO” model, raw intellect over experience, and a cultural obsession with building wow products
Dmitry Zlokazov (Head of Product)