What to cut from an MVP, and the one part to build well

The Product Leaders work group on simplifying assumptions, burnt pizza, testing extremes and stop rules for five to ten users.

Updated October 13, 2026

Decide how high the bar for viable is, cut breadth until one segment does one job on one surface, and build the moment the test depends on well enough that the result means something.

Market maturity sets the bar. Kevin Yien says an MVP in a new market only has to show the problem exists, while a crowded category needs much more, unless you come at it from the side. He writes down the simplifying assumptions that let the team ignore everything else. Ravi Mehta would also enter a crowded consumer category from the side, raising the bar on one dimension, as Swipe Night did at Tinder.
Don't serve burnt pizza. Jiaona Zhang cuts to one or two features and builds them well enough for the test to mean something. She would leave operations, scale and what users take for granted rough, and never the core interaction. Dropbox's presence-only Project Harmony tested a weaker idea than real-time co-editing.
Cut breadth before quality. Kevin writes four constraints into the PRD before design starts: one named segment, usually one pathway to the job, one surface and a short list of principles. If a date forces cuts, he would cut segments and surfaces first and the quality of the tested path last.
Write the thesis, then test the extremes. Lane Shackleton's team at Coda spent about a month on a core thesis doc before most customer research, then put it in front of users as paper prototypes. At YouTube, a tiny skip button in one arm and a giant one in the other gave directional data within weeks.
Write the stop result before launch. Nikhyl Singhal would name the five to ten users, the one assumption and the result that would make you stop, written as behaviors, such as six of ten coming back on their own by week three. A second line asks whether the bet can get big enough to matter. Ravi would judge a crowded-category wedge by whether people return when the incumbent is one tap away.

Group chat with Jiaona, Kevin, Ravi, Nikhyl, Lane — the Product Leaders work group

Question:

How do you scope an MVP down to what tests your idea?

Kevin YienHead of Product, Merchant Experiences at Stripe. Former Head of Lifecycle at Square

Start by deciding how high the bar for "viable" is. Then cut everything that doesn't get you over it.

Market maturity sets that bar. If you're creating a new market, customers can't describe the solution yet, so the MVP has one job: show the problem exists. In a crowded category (another productivity app, say), people compare you to great existing products on day one, so your MVP needs a lot more in it before anyone will take it seriously. The exception is coming at a crowded category from the side, supporting an existing workflow instead of replacing it, which brings the bar back down.

kevinyien

Once the bar is set, the scoping move I use is to write down the most important simplifying assumptions. Weak product sense lists every risk and complication. Strong product sense says "these are the assumptions we're making so we can ignore everything else." Sometimes there's a cheap way to validate an assumption and often there isn't, and that's fine.

Use the customer to settle scope arguments. Someone once asked me when to switch from derisking market need to technical feasibility. They were worried about one very specific, very hard scenario. So I asked whether customers cared about that scenario, and that answered it. If customers don't care about a risk, it doesn't belong in the MVP.

Sometimes the cheapest MVP has no product at all. At Berkeley our team started out building a smartphone glucometer. FDA timelines didn't fit our goal of shipping something within six months, so we went through Steve Blank's Lean LaunchPad instead and talked to nearly 100 diabetics in person over ten weeks. Those conversations told us more than a first hardware build would have.

projects.kevinyien

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

I scope from the problem inward, then cut features until one or two are left, and I build those one or two well enough that the test means something.

The way I explain this to my Stanford students: say you want to test whether people like pizza, and you serve them burnt pizza. All you learn is that they don't like burnt pizza. The cheapest functional prototype often ends up testing a broken version of your idea

review.firstround

My method, step by step:

Draw a vertical line. Problems go on the left. Any solution someone mentions goes on the right, gets acknowledged, and waits. Then pick the single highest-value problem you believe you can solve.
Write the user's why. "Wouldn't it be amazing if this product could..." has to end in value for the user. At Airbnb, "grow supply" was the business why. The user why was more listings in places people actually want to go, and that changed both what we built and what we measured.
Cut to one or two features that deliver that value. If you spread the product across every problem, it does all of them poorly.
Read the reaction. "This is cool, I can see myself using it" is a weak signal. "When can I start using it?" is the one you want. If you don't get it, the usual cause is that you picked a low-value problem.

Project Harmony at Dropbox is my cautionary tale here. We shipped presence in shared Office docs, and the press was good. Users actually wanted real-time co-editing, so presence ended up showing them what Dropbox couldn't do. Every iteration after that improved a local maximum

review.firstround

Get viable right first, then add the lovable layer on top

Lane ShackletonHead of Superhuman Docs. Former Chief Product Officer at Coda

Kevin's simplifying assumptions are the right starting point, and I'd write them down as a stake in the ground before talking to customers so you can tell later whether the market moved you or you drifted. In the early days of Coda we spent about a month writing a core thesis doc that stated precisely what we believed. We did that before much customer research and before most of our time with alpha customers. Then we put that thesis into the market in its lightest form, which was a lot of paper prototypes. I ran probably hundreds of those interviews.

Spotify

Once the belief is written down, I scope the MVP to show the upper and lower bounds of the idea instead of a polished middle version. At YouTube we were stuck debating skippable ads. The leader in the room stopped the debate and said to test the extremes and start the experiment tomorrow. Jamie Kearns launched a tiny skip button in one arm and a giant skip button covering the whole player in the other. Within a few weeks we had conviction from very directional data.

Spotify

The last step is matching the fidelity to what the idea depends on, which is jz's burnt pizza point applied to prototypes. Paper stopped working for Coda's formula builder because the value lived in how it felt to type. Our mocks grew to around 100 Figma frames trying to spell out every cursor interaction. Chris, one of our lead engineers, made it possible to spin any code branch into a full, isolated environment that customers could use. After that, a pod could write "prototypy crappy code" and put it in front of real users without touching production. The code was rough, but the interaction users were judging was real.

Spotify

So my scoping filter is this. Write the thesis, then cut every feature that doesn't help confirm or kill it. Push the remaining variable to its extremes, and use the cheapest format that still lets a user feel the core interaction.

Nikhyl SinghalFounder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma

I scope an MVP by audience first and by features second.

The question the MVP needs to answer comes from the stage you're in. Before product-market fit you're on what Dave Whorton calls the "drunken walk": stumbling around, failing fast, and lucky to plan a few steps ahead. So I write down the one assumption that kills the idea if it's wrong, and the MVP is whatever answers that in weeks. A roadmap at this stage does harm, because you can't forecast what customers want six months out. The closer to the ground, the better.

review.firstround

Jiaona's burnt pizza point gets stronger with AI tools, and it changes what you cut. In a recent podcast conversation about how Stripe builds, I learned that Stripe Projects (one of the hits of this year's Sessions) started with two and a half people building for a few weeks for five to ten trusted users. Early releases there go wide and feature-rich, because building is now cheap. What's expensive is user attention and trust. So keep the user group tiny and well chosen, give them enough product to judge the real experience, and read their reactions closely before you widen access.

Inside a company that already has a working product, the scoping rule is one bet at a time. A year into my time at Credit Karma, we had chased so many shiny new things that our focus had swung too far from the core business. We pulled back, and only then did we launch half a dozen product lines without hurting the core.

review.firstround

My test for the scope: can you name the five to ten users, the one assumption you're testing, and the result that would make you stop?

Kevin YienHead of Product, Merchant Experiences at Stripe. Former Head of Lifecycle at Square

Jiaona's burnt pizza is what you get when you cut quality to save time. Nikhyl's tiny audience is one way to cut breadth instead. I'd make every breadth cut explicit and leave the quality bar alone.

These are the constraints I write into the PRD before anyone designs anything

Spotify:

Customer segment and their specific role. One segment, named.
The job they're trying to do, and how many different pathways to that job you're willing to entertain. Usually one.
Availability: desktop web, mobile web, or native mobile. Pick one surface for the MVP.
A short list of principles for the things you refuse to compromise on.

Each constraint removes a big chunk of scope, and none of them burns the pizza. One segment doing one job on one surface can still be excellent. Ten segments on three surfaces at half quality teaches you nothing, because when the test fails you can't tell which part failed it.

The tradeoff is that holding the quality bar can cost you dates. On one launch we had a strict deadline and I pushed it out three times. One animation didn't cause that. It came from a string of decisions where we said "this is what we believe we need to ship," and that mattered more than an artificial external GA date

Spotify. So if the date is about to force cuts, cut segments and surfaces first. Cutting the quality of the one path you're testing should come last.

Question:

Kevin argues that market maturity sets how much an MVP must include: a new market only needs proof the problem exists, while a crowded category needs much more before anyone takes it seriously. Ravi, from Tinder and Tripadvisor, how would you scope an MVP for a crowded consumer category? Would you build a fuller product, or come at the category from the side the way Kevin suggests? Please cite a public example.

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

In a crowded consumer category I come at it from the side, and I still keep the MVP narrow. Kevin is right that the bar is higher, but I'd raise it on a single dimension where you're clearly different, and match incumbents only on what users take for granted. A fuller product built to match Tinder or Tripadvisor feature for feature loses to them, because users already have those apps and their history lives there.

Swipe Night at Tinder was a side entry inside the most crowded category we had. It didn't add another swiping feature. It was an interactive, choose-your-own-adventure event built for Gen Z that gave people something to talk about and a new reason to match. The scope was one event format aimed at one audience, and the part users actually saw had to be excellent.

Suno shows the same move for a startup. When I talked with Mikey Shulman on my podcast, we covered why Suno launched its first product on Discord. Discord gave them distribution and a feedback channel they didn't have to build. Early subscriber feedback shaped the roadmap, and the web app came later, which is when growth took off.

Being crowded also changes what you measure. In a crowded category trial is cheap and comparison happens immediately, so first-session excitement tells you almost nothing. My test is whether people come back to your wedge even though the incumbent is one tap away. Facebook ranked retention above user growth and checked that features actually engaged people before scaling them. I'd hold a crowded-category MVP to that bar before spending anything on acquisition.

Small numbers make the result easy to misread, so pair the retention data with user conversations. The data tells you whether people returned, and the conversations tell you whether they came back for your wedge or for things the incumbent already does.

Question:

Lane tests ideas with deliberately rough versions: a giant skip button covering the whole YouTube player, and "prototypy crappy code" for Coda's formula builder. Kevin says to cut segments and surfaces first and cut quality on the tested path last. Jiaona, by your burnt pizza test, when does a rough prototype still give a valid read, and when does it burn the pizza? Name one thing you would leave rough and one you would never leave rough, using a public example.

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

A rough prototype gives you a valid read when the roughness sits outside the thing the user is judging. It burns the pizza when the rough part is the value itself. Lane's two examples both pass that test. A giant skip button looks ugly, but skipping actually works. Coda's branch code was rough, but typing a formula felt real.

The thing I would never leave rough is the core interaction. Project Harmony is where I learned that. We shipped "see who else is in this doc" and treated it as a fair first step toward collaboration. The thing people love in Google Docs is watching each person's edits land in real time, cursor by cursor. Our presence-only version left out that experience, so it tested a weaker idea and ended up showing users what Dropbox couldn't do yet

review.firstround

The things I'd happily leave rough are operations, scale, and the parts of the product people take for granted. On Airbnb Plus, we inspected homes with people on the ground, which was slow and expensive. It still told us what guests valued. Once we learned the manual approach wouldn't scale, I moved off and worked on the review system, because the scalable version was automated checks at the moment a host uploads a listing

Apple Podcasts

Plus also shows the opposite failure. Our first quality bar was a 200-point hotel amenity list, and requiring all of it would have left us with zero qualified homes. We kept quality high on the one thing that sets Airbnb apart, the feeling of a real home, and built a Home Tour that lets guests walk through each room in photos. That was far cheaper than putting physical items into homes

review.firstround

So mark the one moment where the user should say "when can I use this?" Build that moment to full quality, and leave everything around it rough.

Question:

Nikhyl, your scope test ends with naming the result that would make you stop. Ravi warns that MVP numbers are small and easy to misread, and judges a wedge by whether people come back when the incumbent is one tap away. With only five to ten trusted users, how do you write that stop result before launch so you can't move the goalposts later? Please give one public example of a team that set or missed a kill threshold.

Nikhyl SinghalFounder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma

With five to ten users, I write the stop result as named behaviors, because percentages mean little at that size. Before launch the owner writes something like: "By the end of week three, at least six of these ten people have come back on their own, and at least three have asked when they get more. If we fall short, we stop or change the bet." The team gets that page before anything ships, and it also sets how big the team is allowed to grow.

Tido Carriero describes this gate well. He keeps a new product to about three engineers, a PM and a designer until there is clear evidence of pull. That evidence can be revenue, or even a screenshot of a customer asking whether it will be ready next week. He has also seen projects where 30 to 50 engineers worked for six to twelve months and the product never took off, because the team never understood the problem well enough for a customer to repeat it back with excitement.

review.firstround

The missed version is usually "popular, but small." Todd Jackson tells the story of Carousel at Dropbox. It was a beautiful photo app, very popular in some circles, and a lot of people worked on it. It just wasn't growing enough to matter to the company, so they shut it down and put everything into the SaaS business ahead of the 2018 IPO.

review.firstround That's why the stop rule needs two lines. One says whether these users love it. The other says whether the bet can get big enough to matter. At Credit Karma, those enthusiastic side bets are what pulled our focus too far from the core business.

The person who owns the bet should sign the page, which before product-market fit means the founder. In my startups, PMs I hired early to find the winning idea sometimes didn't feel empowered to call a stop.

review.firstround

Ask a follow-up

Product Leaders

220

Product Leaders

3M+ insights

Product leaders from Google, Airbnb, Stripe & 7 more

by Lenny Rachitsky

Frequently Asked Questions

What goes into a good product strategy?
A customer problem the team can describe, one clear choice about the value to deliver first, the work set aside, and the evidence that would show the bet is working. It should let the team explain a specific 'no' to an important customer.
How do you tell a product strategy from a roadmap?
A strategy changes decisions: who the team builds for, where people are staffed and which requests get declined. Noam Lovinsky's test is which staffed project the team would stop to make room for its top bet.
How do you run customer interviews that change what you build?
Tie them to a decision someone owns, ask why the customer has the problem, watch them use a working prototype with realistic data, and check which segment each finding came from before it reaches the roadmap.
How should a product team handle feature requests?
Route them by source, write down the problem behind each one, rank only near-term work, and protect capacity for bigger bets and reliability so the request queue can't fill the whole roadmap.
How do you tell whether a new feature worked?
Write down what a win looks like and when you'll read the metric before launch. Read adoption, then sentiment, then behavior change, and check that the whole product gained rather than usage moving from one feature to another.
How do product managers keep stakeholders aligned on scope?
Put the scope decisions and the cut list in one shared record, ask what moves whenever someone adds work, name who owns each call, and check that agreement is real, for example by asking stakeholders to explain the decision back.
How do you forecast delivery for a project full of unknowns?
Give a range and the decisions that set it rather than one date, resolve the unknowns on the path to customer value first, and re-forecast at milestones that get feedback from outside the team.
How is AI changing the way product teams are organized?
New bets increasingly go to small pods with wide roles, while large companies keep specialists and find code review and judgment becoming the bottleneck. Either way, someone on the team still has to push for the user.
What makes a product brief useful?
It lets the people building decide well without the PM in the room: the customer problem and evidence, the outcome, the trade-offs made, what is still open, and which constraints the team can challenge.

All product management questions →

Frequently Asked Questions

What to cut from an MVP, and the one part to build well

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you run customer interviews that change what you build?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How do you forecast delivery for a project full of unknowns?

How is AI changing the way product teams are organized?

What makes a product brief useful?

Your ideas, super powered.

What to cut from an MVP, and the one part to build well

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you run customer interviews that change what you build?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How do you forecast delivery for a project full of unknowns?

How is AI changing the way product teams are organized?

What makes a product brief useful?

Your ideas, super powered.