[{"data":1,"prerenderedAt":256},["ShallowReactive",2],{"blog-\u002Fblog\u002Fhow-i-scope-an-mvp":3,"blog-surround-\u002Fblog\u002Fhow-i-scope-an-mvp":237,"blog-related-\u002Fblog\u002Fhow-i-scope-an-mvp":246},{"id":4,"title":5,"audience":6,"body":10,"cluster":202,"date":203,"description":204,"draft":205,"extension":206,"factCheckedAt":207,"faq":208,"featured":205,"language":207,"meta":218,"navigation":219,"order":220,"originalAsset":207,"path":221,"pillar":222,"primaryKeyword":223,"relatedProject":207,"releaseScope":207,"reviewCycle":224,"reviewStatus":225,"reviewedBy":226,"searchIntent":227,"seo":228,"sources":207,"stem":229,"tags":230,"type":235,"updated":203,"__hash__":236},"blog\u002Fblog\u002Fhow-i-scope-an-mvp.md","How I Scope an MVP",[7,8,9],"indie-founder","solo-developer","product-builder",{"type":11,"value":12,"toc":192},"minimark",[13,32,37,40,56,63,67,80,87,91,104,108,116,120,127,131,157,165,168],[14,15,16,20,21,26,27,31],"p",{},[17,18,19],"strong",{},"Everyone knows the MVP is the smallest thing you can build and ship."," That's the textbook line, and it's the half that gets people in trouble. Here's the version I've earned: an MVP isn't the smallest thing you can build — it's the smallest thing that's actually useful. I scope mine from the outcome — the one core result the product must deliver to ",[22,23,25],"a",{"href":24},"\u002Fblog\u002Fwhy-i-build-narrow-choosing-who-a-product-is-for","one real user",", built by the shortest path, ",[22,28,30],{"href":29},"\u002Fblog\u002Fhow-i-decide-what-to-build-next","everything else cut",". Not minimum-and-broken. Not the-whole-vision-slightly-smaller. The smallest thing that genuinely delivers the core value. Get that framing right and the scope almost draws itself. Get it wrong and you either over-build for months or ship something too stripped to matter.",[33,34,36],"h2",{"id":35},"the-two-ways-mvps-fail","The two ways MVPs fail",[14,38,39],{},"They fail in opposite directions:",[41,42,43,50],"ul",{},[44,45,46,49],"li",{},[17,47,48],{},"Too much."," The MVP quietly becomes \"the whole vision, a bit smaller\" — neither minimum nor fast, and you're still building when you should be learning.",[44,51,52,55],{},[17,53,54],{},"Minimum but not viable."," So stripped down it doesn't deliver the core value at all — users get nothing they can use, and you learn nothing except that a broken thing gets no traction.",[14,57,58,59,62],{},"Both come from scoping by feature count instead of by outcome. The word doing the work in \"minimum viable product\" is ",[17,60,61],{},"viable"," — it has to actually work for someone.",[33,64,66],{"id":65},"scope-from-the-outcome","Scope from the outcome",[14,68,69,70,74,75,79],{},"I start where I always ",[22,71,73],{"href":72},"\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen","start",": what's the one core result a user should walk away with? For ",[22,76,78],{"href":77},"\u002Fblog\u002Fwhy-i-built-delivery-sheet","Delivery Sheet",", that's turning a raw leadership ask into a decision-ready one-pager. That outcome is the definition of the MVP. Everything else sorts into one of two piles — required to deliver it, or not. The first pile is the MVP. The second is parked.",[81,82,84],"callout",{"type":83},"tip",[14,85,86],{},"The MVP test, applied to every feature: can a real user get the core value without this? If yes, it's not in the MVP — no matter how obvious, reasonable, or cheap it is. \"Obvious and easy\" is precisely how MVPs bloat, one reasonable addition at a time.",[33,88,90],{"id":89},"cut-ruthlessly-park-honestly","Cut ruthlessly, park honestly",[14,92,93,94,98,99,103],{},"The hard part isn't finding what to build — it's cutting what not to. Secondary features, edge cases, settings, integrations, polish past usable, every \"while we're here\" — out. Not deleted: ",[22,95,97],{"href":96},"\u002Fblog\u002Fhow-i-decide-whether-an-ai-product-idea-is-worth-building","parked",", on a list, for later. It's the same ",[22,100,102],{"href":101},"\u002Fblog\u002Fwhy-most-ai-built-apps-feel-like-demos","ruthless subtraction"," that makes any product sharp, only now under a deadline. A cut feature you can always add back. A bloated MVP you can't un-build.",[33,105,107],{"id":106},"why-ai-makes-this-harder-not-easier","Why AI makes this harder, not easier",[14,109,110,111,115],{},"Here's the modern trap. ",[22,112,114],{"href":113},"\u002Fblog\u002Fhow-i-use-ai-without-letting-ai-decide","AI makes building so cheap"," that over-building feels free. When a feature costs an afternoon instead of a week, the discipline to not add it quietly erodes — and you end up with an MVP that's secretly a V3, still unshipped, still teaching you nothing. The cheaper building gets, the more scope discipline matters, because the natural brake — cost — is gone. Cheap to build was never the same as worth building.",[33,117,119],{"id":118},"the-test-of-a-good-mvp","The test of a good MVP",[14,121,122,123,126],{},"A well-scoped MVP passes one test: ",[17,124,125],{},"can one real user get the core value?"," Not \"is it impressive.\" Not \"is it complete.\" Can a genuine user, with the actual problem, reach the outcome and find it worth using? If yes, ship it and learn. If no, it isn't minimum-viable — it's just unfinished, and shrinking it further won't help. Only making it actually deliver will.",[33,128,130],{"id":129},"what-usually-goes-wrong","What usually goes wrong",[41,132,133,139,145,151],{},[44,134,135,138],{},[17,136,137],{},"Scoping by features, not outcome."," Choosing what to include from a list instead of from what delivers the core result.",[44,140,141,144],{},[17,142,143],{},"Over-building."," Treating the MVP as the full vision slightly smaller, so it's slow and bloated and late.",[44,146,147,150],{},[17,148,149],{},"Under-delivering."," Stripping past viable, so it doesn't provide the core value and teaches you nothing.",[44,152,153,156],{},[17,154,155],{},"Letting cheap building erode discipline."," Adding \"just one more\" because AI makes it easy, until the MVP is a V3.",[14,158,159,160,164],{},"Define the core outcome, build the shortest path to it, cut everything else to a parked list, and ship the moment a real user can get that value. That's the MVP doing its job: the smallest useful thing, out fast, telling you what's true. It's ",[22,161,163],{"href":162},"\u002Fblog\u002Fmy-product-operating-system","rule two of my operating system"," under a stopwatch — outcome first, everything non-essential cut.",[166,167],"hr",{},[14,169,170],{},[171,172,173,174,178,179,182,183,186,187,191],"em",{},"Part of ",[22,175,177],{"href":176},"\u002Ftopics\u002Fbuilding-ai-products","Building AI Products",". See also ",[22,180,181],{"href":72},"why I write the expected output before the screen"," and ",[22,184,185],{"href":162},"my product operating system",". The ",[22,188,190],{"href":189},"\u002Fnewsletter","newsletter"," sends one practical build lesson every two weeks.",{"title":193,"searchDepth":194,"depth":194,"links":195},"",2,[196,197,198,199,200,201],{"id":35,"depth":194,"text":36},{"id":65,"depth":194,"text":66},{"id":89,"depth":194,"text":90},{"id":106,"depth":194,"text":107},{"id":118,"depth":194,"text":119},{"id":129,"depth":194,"text":130},"process","2026-07-25","How to scope an MVP: not the smallest thing you can build, but the smallest that's actually useful — one core result for one real user, everything else cut.",false,"md",null,[209,212,215],{"question":210,"answer":211},"How do you scope an MVP?","Scope it from the outcome, not the feature list: find the smallest version that delivers the core result to one real user, and cut everything else. An MVP isn't the smallest thing you can build — it's the smallest thing that's actually useful. So you define the one outcome the product must deliver, build the minimum path to it, and ruthlessly leave out everything that isn't required to reach that outcome, even if it's obviously nice. If a real user can get the core value, it's a viable MVP; if they can't, it's just unfinished.",{"question":213,"answer":214},"What is the most common MVP mistake?","Two opposite ones. The first is building too much — treating the MVP as a slightly-smaller version of the full vision, so it's neither minimum nor shipped quickly. The second is shipping something that's minimum but not viable — so stripped down that it doesn't actually deliver the core value, so users get nothing useful and you learn nothing. The fix for both is the same: define the core outcome first, then build the smallest thing that genuinely delivers it — no more, no less.",{"question":216,"answer":217},"What should you cut from an MVP?","Everything that isn't required to deliver the core outcome to a real user — however reasonable or nice it seems. Secondary features, edge cases, polish beyond usable, settings, integrations, and 'while we're here' additions all get cut from the MVP and parked. The test for each is simple: can a user get the core value without it? If yes, it's not in the MVP. Ruthless cutting is what keeps the MVP minimum; the parked list is where the good-but-later ideas wait.",{},true,16,"\u002Fblog\u002Fhow-i-scope-an-mvp","building-ai-products","how to scope an MVP","annual","reviewed","Tan Gravam","informational",{"title":5,"description":204},"blog\u002Fhow-i-scope-an-mvp",[222,231,232,233,234],"mvp","product","scope","solo-saas","text","WZgiHI5ah48N5qe3-0gXsSUuQJ5FGE_-OUGcLqkm4tA",[238,242],{"title":239,"path":240,"stem":241,"type":235,"language":207,"draft":205,"children":-1},"How I Position a Product (What It Actually Does)","\u002Fblog\u002Fhow-i-position-a-product","blog\u002Fhow-i-position-a-product",{"title":243,"path":244,"stem":245,"type":235,"language":207,"draft":205,"children":-1},"How I Stay Sane Building Products Solo","\u002Fblog\u002Fhow-i-stay-sane-building-products-solo","blog\u002Fhow-i-stay-sane-building-products-solo",[247,250,253],{"path":162,"title":248,"description":249},"My Product Operating System for Building Multiple AI Apps","The product operating system I use to build several focused AI products solo: choosing which problem to build, shipping fast, and killing what isn't working.",{"path":96,"title":251,"description":252},"How I Decide Whether an AI Product Idea Is Worth Building","How to decide what product to build: the short filter I run every idea through — real recurring problem, one-sentence outcome, small enough to ship solo.",{"path":72,"title":254,"description":255},"Why I Write the Expected Output Before the Screen","Define the outcome before design: I write the exact result the user should get before building any screen, because the screen is only the path to an outcome.",1785182340647]