"MVP" is used to describe two different projects that don't always turn out to be the same thing, and conflating them is where a lot of founders lose months. One is a learning instrument: the smallest thing you can build to find out whether your core assumption is true. The other is a piece of fundable evidence: something that can start generating a number an investor will recognize as real, growing traction. A well-built learning instrument can be almost worthless as fundable evidence, and a demo built to impress investors can be a terrible way to actually learn anything. Scoping an MVP well means being honest about which job it's doing, because the smallest version of each one is often a genuinely different product.
What an MVP is actually for, precisely
Eric Ries, who popularized the term, defined it in his original write-up not as "a small version of the product" but as the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort. That's a narrower, more useful bar than "fewer features." It means the question isn't "what can we cut," it's "what's the cheapest way to find out if the thing we're most unsure about is actually true." Under this definition, a landing page that measures signup intent, or a manually operated back end pretending to be automated software, can be a completely legitimate MVP — because both can generate real learning about the riskiest assumption without months of engineering.
What investors are actually evaluating
The excerpt's framing — investors fund traction, not features — has a specific, well-documented basis in how early-stage investors think about young companies. Paul Graham's essay "Startup = Growth" makes the case directly: he argues a startup is best defined by its growth rate rather than its size at any given moment, and that the trend is the number worth tracking above almost anything else. That's one influential figure's perspective, not a universal rule every investor applies identically, but it reflects a real pattern in how early-stage evaluation works: a single snapshot — "we have 400 users" — says very little on its own, while a repeatable, upward-trending number over a defined period says a great deal, even at a small scale.
Y Combinator's own guide to seed fundraising reflects the same logic in practical form, framing traction as something best presented with a timeframe attached — growth from one point to another over a specific period — rather than as a static achievement. That distinction is the whole reason "features, not traction" is the right frame: a list of what the product does answers a question nobody serious is asking. A curve answers the one they are.
The trap of scoping purely for learning
As a hypothetical example: a founder validating a B2B scheduling idea builds a "concierge MVP" — a simple form, with a human manually coordinating every booking behind the scenes. By Ries's own definition, this can be an excellent MVP: cheap, fast, and capable of proving whether the core problem is real. But it generates almost nothing an investor can point to as traction, because it can't scale past a handful of manually-handled customers, so there's no growth curve to show, only anecdotal confirmation that a few people wanted the service. Learning and fundable evidence diverged here — the MVP did its actual job perfectly and still left the founder with nothing usable in an investor conversation.
The trap of scoping purely to impress
The opposite mistake is at least as common and considerably more expensive. As a second, unrelated hypothetical: a founder building a consumer app spends four months and most of their seed runway building polished iOS and Android apps, a marketing site, and a handful of features they assume investors will expect to see in a demo, before ever putting the product in front of a real user. By the time it launches, there's no runway left to let a growth curve actually develop, and the first data point arrives too late to show a trend at all — only a snapshot, months after the money that could have funded the next stage was already spent building for an audience of one investor rather than for real usage.
Reconciling the two: scope around the number, not the feature list
The practical fix is to decide, before writing any code, which single number this MVP exists to move — signups, repeat usage within a week, paid conversions, whatever most directly reflects the assumption actually being tested — and then build the smallest thing that lets that number start accumulating real data points as early as possible. Everything not required to produce that number honestly is a candidate to cut, including features that would make a demo look more finished. The concierge MVP from the first hypothetical could have been adjusted to solve its evidence problem without abandoning its learning value: charging real money from the first booking, even manually, converts "people said they'd want this" into a repeatable revenue number with a timeframe attached — a small change in scope that turns a pure learning instrument into something closer to fundable evidence, without the cost of the second hypothetical's four-month build.
The common thread in both traps is time: the earlier a real, repeatable number starts existing, the more of it there is to show by the time a fundraising conversation happens, and a growth curve with six months of real data points is a fundamentally different pitch than a single number from last week — regardless of how complete the underlying product looks in a demo.
Further reading
