6 min read
How much does product design cost, and why
A straight answer for founders on what product design actually costs, what drives the number, and how to spend it well.
pricingfoundersengagements
Product Strategy
Most MVPs are either too thin to prove anything or too bloated to ship. How to scope the version that moves your metrics and your raise.
TL;DR
An MVP is not the smallest thing you can build. It is the smallest thing that proves the one claim your next round depends on. That distinction is where most MVPs go wrong, in one of two opposite directions. Some are too thin to prove anything, a pile of half-features that demonstrates activity but not the thing that matters. Others are so broad they never ship, because the team kept adding until the finish line moved out of reach. Scope from the claim backward and you avoid both. This covers how to find that claim, how to cut to the flow that proves it, why the core loop has to feel finished, how to instrument the proof so the result is evidence rather than opinion, and a worked example from first sentence to shipped test.
Start from the claim
Write it in a single sentence: the specific thing this version needs to show works, for the next milestone or the next investor conversation. "People will pay for this." "This workflow is ten times faster than the spreadsheet." "Users come back on their own without a nudge." Everything else about the product is negotiable; this sentence is not. Until you can state the claim in one line, you cannot scope, because you have no ruler to measure features against, and every feature will look equally justifiable. The discipline of forcing the claim into one sentence is itself useful, because a claim you cannot state simply is usually two or three claims tangled together, and trying to prove all of them at once is exactly how an MVP bloats.
| MVP shape | What it proves | Result |
|---|---|---|
| Too thin | Nothing convincing | No signal, and no raise |
| Too broad | A little of everything | Never ships, or ships as a demo |
| Scoped to the claim | The one thing that matters, well | A metric and a story |
Once the claim is fixed, keep the single flow that demonstrates it and cut everything else. Every screen that does not serve the claim is delay dressed up as progress, and it will feel like progress right up until you notice the proof still is not built. This is genuinely painful, because the features you cut are all real, all things you will build eventually, all things someone on the team is attached to. But eventually is not now, and now you are proving one thing. The cut is easier if you frame it honestly: you are not deciding these features are bad, you are deciding they are not what this version is for. Everything you keep, you then build to a real standard, because investors and early users judge the thing you actually shipped, not the roadmap you described next to it. A narrow product that feels finished beats a broad one that feels like a demo, every single time, because finish is the signal that you can execute and a demo is the signal that you cannot yet.
Finished beats broad
A small product built to a real standard proves more than a wide one built to demo quality. Depth on the core loop is the signal that convinces; breadth is noise until the claim is proven.
The claim should resolve to a number, not a vibe, and you decide which number before you launch, not after you are staring at ambiguous results. If the claim is "users come back on their own," that is day-two and week-two retention, wired up and tested before the first real user arrives, so the data is clean from the start. If the claim is "people will pay," that is the conversion from trying the core loop to actually paying, instrumented end to end. Deciding the metric in advance does two things. It forces you to make the claim falsifiable, which sharpens it. And it means that when the number moves you have both a working product and a story, which together are what actually move a raise forward. When the number does not move, you have learned the cheapest possible way that the claim was wrong, which is its own kind of success, because the alternative was learning it after building the whole product.
Say the claim is "operations managers will pay to automate their weekly reconciliation." The one flow that proves it is small: connect a data source, run a single reconciliation, see the time it saved stated plainly, and hit a paywall. Everything else, team accounts, a second data source, settings, a dashboard, a mobile app, is cut, not because those are bad ideas but because none of them proves this claim. The instrumentation is two numbers decided up front: the conversion from running that first reconciliation to paying, and whether people run a second one unprompted, which tells you the value was real and not a one-time novelty. Build that single loop until it genuinely feels finished, ship it to a handful of the right people, and you have the sharpest possible argument for the raise built from the smallest possible amount of product. That is what an MVP is for.
An MVP is not a smaller version of everything. It is the sharpest possible argument for the one thing that comes next.
What makes an MVP good enough to raise on?
It proves one specific claim your next round depends on, and it proves it with a number. That means a single core flow built to a real standard plus the instrumentation to show the metric moved, not a broad set of half-built features.
How do I decide what to cut from an MVP?
State the one claim you need to prove in a sentence, then cut every feature that does not directly serve that claim. If a screen does not help prove the claim, it is delay, no matter how much you will eventually need it.
How polished should an MVP be?
The core loop should feel finished, because investors and early users judge what you shipped, not the roadmap. Depth on the one flow that matters beats breadth across many rough ones.
What should I measure to know the MVP worked?
Whatever number the claim resolves to, wired up before launch. If the claim is repeat usage, that is retention; if it is willingness to pay, that is conversion from the core loop to payment. Decide the metric first, then build to move it.
What is the biggest MVP scoping mistake?
Trying to prove several claims at once, which bloats the build and blurs the result. Force the claim into a single sentence, and if you cannot, you have more than one claim and should pick the one the raise actually depends on.
Scope an MVP from the claim your raise depends on, cut to the flow that proves it, build that flow like it is the whole product, and instrument the result so the answer is a number. Do that and your MVP becomes the sharpest possible argument for what comes next instead of a smaller, blurrier version of the eventual product. Deciding what is worth building is the same discipline as reasoning about what design work is worth, and earning attention for the result connects to getting cited by AI rather than just ranked. If you are scoping a raise-ready MVP, it can be cut to the claim with you.
Related reading
