How much of your product you actually need to build first

The instinct with a new product idea is to build the whole thing before anyone else sees it (every feature, every polish pass, every integration) and find out in one moment whether the market agrees with you. That's also the most expensive way to find out. More than 65% of product launches missed their own targets in 2023, and the book behind this bundle argues the usual cause isn't a bad product. It's a step skipped somewhere between the idea and the launch, one the builder doesn't notice until the results come in low.

The step that gets skipped most is deciding, before you build anything, what you're actually testing. Most founders can describe their finished product in detail long before they can name the single assumption that would sink it if they're wrong. That's backwards, and it's why so many launches spend months building a complete version of an idea nobody has confirmed anyone wants.

The fix isn't a watered-down version of the real thing. It's a deliberately small one, built to answer exactly one question.

What actually belongs in a minimum viable product

The book calls this your product's skeleton: only the features required to solve the customer's core problem, nothing added for completeness. Its own line for the instinct to over-build is blunt: you don't need a Ferrari when a bicycle answers the question. LinkedIn's first version in 2003 offered profile creation and connections. Nothing else. No messaging, no job boards, no company pages. That was enough to test whether professionals wanted a dedicated place to showcase their work and connect with each other, and the answer came back clearly enough to build the rest on top of it.

Buffer went further before writing a line of code: a two-page site describing the product and showing pricing, with nothing built behind it. The page measured interest directly, before development spending was on the line.

Both examples run on what the book calls the build-measure-learn cycle. Build the smallest version that still delivers real value. Measure actual user behavior (activation, return visits, time on the core feature) rather than opinions people offer when asked. Then use what you learn to decide the next move, instead of the one you'd already planned to make anyway.

Deciding what belongs in that first build is where the book gets specific, sorting every feature idea into three tiers:

• Must-have: core functionality essential to solving the problem. Goes in the MVP, immediately.
• Nice-to-have: features that improve the experience but aren't required to test the assumption. Wait for post-MVP validation before building them.
• Future considerations: features aimed at scale or market expansion. Belongs on the long-term roadmap, not this launch.

Instagram is the example of this framework running in reverse. It started as Burbn: check-ins, plans, points, photo sharing, all at once. Usage data showed almost nobody touched anything but the photos. The team cut everything else and relaunched around the one feature the data had already promoted to must-have. That's a harder move than it sounds: demoting features you've already shipped, on the strength of usage numbers rather than your own read of the product.

Where people go wrong

The most common mistake is treating "minimum" as a smaller draft of everything instead of a single testable assumption. Founders build a rough version of every planned feature rather than the one feature that actually tests the hypothesis, and end up with something that's both incomplete and unfocused: the worst of both options.

The second is skipping the measurement half. An MVP launched without deciding in advance what you're tracking (activation rate, core-feature usage, return visits) just exists once it's live. There's no way to tell whether it worked or merely shipped, which defeats the reason to build it small in the first place. This is the same discipline gap the Business Foundations guide keeps returning to: the plan is rarely the part that fails, the follow-through is.

The third is refusing to cut. Once a feature exists, it's hard to let usage data override the effort that went into it. The Instagram move (killing three-quarters of a shipped product because the numbers pointed at one feature) is rare precisely because it takes real discipline to demote something you already built, even when the evidence says to.