Build Only What You've Validated

If Module 5 sent you here, this is the method it meant.

If you just came from raising money against pilotsA small paid first project a customer runs with you to test whether the thing works before committing to more., you already made a promise: three to five paying customers before you pitch scale. Nobody yet told you how much of your product that pilotA small paid first project a customer runs with you to test whether the thing works before committing to more. actually requires. That is this section. Scoping the smallest slice a customer will pay for, before you write the check-writing pitch, is the skill the pilot needed and didn't have yet.

And if you arrived here another way, the claim underneath still holds on its own: most product failure is not a bad idea badly executed. It is a good idea, over-built, before anyone confirmed the market wanted it. The three learnings ahead come from a real company living out exactly that failure, caught in the act and rebuilt in real time.

The biggest failure mode is building everything before anyone asked for it.

A competitor had started eating into the exact market a team was building for, and the instinct in the room was to build faster and build wider, matching feature for feature before the competitor got there first. The instinct was wrong. The single biggest way a product company fails is designing the product to do everything and starting to build before validating any of it in the market.¹ The things you believe about your customer are hypothesesA belief about your market stated plainly enough that a real test could prove it wrong.. Building the full vision on top of them, before a single one is confirmed, is how a year disappears.

The company had already lived this failure once. A year into the first version of the platform, the team sat down and named plainly what had gone wrong, and it was not what anyone expected.

Two habits came out of that post-mortemA look back at finished work, often failed work, to name what actually went wrong., a look back at the failure to name what actually went wrong, and they show up across every product the corpus touches. First, don't model your business around your first client. A founder tempted to generalize a demanding early customer's requests into the permanent roadmapThe ordered plan of what you intend to build or do next., the ordered plan of what to build next, ends up building a product for an audience of one.³ Second, before adding a feature, ask whether anyone has already tried this and why it stalled; a stalled prior attempt is market information you get for free.⁴ Some of the most durable products, Hootsuite and Bench among them, started as a manual service and only became a repeatable, sellable product, productizedTurning a service you do by hand into a standard product you can sell over and over., once the service proved what customers would actually pay for.⁵ Ship the smallest usable slice, let the next feature request tell you what to build next, and keep everything else on a list marked "demand pulls it," not a backlogThe waiting list of features or tasks you have noted but not committed to. you're already committed to.⁶

You are thinking as a developer. Users want less to manage.

The same disagreement plays out in most product teams building for customers with very different needs. One side pushes hard for letting each account run multiple storefronts, arguing from firsthand experience managing several distinct collections: more capability, more control, obviously better. The other side stops it cold.

The feature that excites the builder and the feature that helps the customer are not the same feature, and the gap is invisible from inside the build. The fix is a standing question run against every capability before it ships: whose life does this simplify, yours or theirs? If the honest answer is yours, it goes on the "demand pulls it" list from the last page, not the roadmapThe ordered plan of what you intend to build or do next..⁷

This is the same failure the Cheesecake Factory menu names for consumer psychology: too many options and people freeze instead of choosing.⁸ One team's own cofounder abandoned her own product's sign-up form mid-flow, live, because it asked for too much at once. The fix that followed was one question per screen.⁹ The same instinct, applied deliberately, produced a cleaner design pattern on the marketplaceA platform where many independent sellers offer products to the platform's buyers., a platform where many sellers list to one shared set of buyers, behind Learning 1: strip every barrier out of signup, name and email, nothing else, and only gate the one action that actually carries risk. Unverified users could upload, organize, and invest real effort in their account, but not publish a listing or take payment, until identity verification finished running quietly underneath. The user gets hooked on their own sunk work while the one genuinely risky step waits its turn.¹⁰ FrictionAnything that slows a customer down on the way to buying or using your product., anything that slows a customer down, removed everywhere it costs you signups; frictionAnything that slows a customer down on the way to buying or using your product. placed exactly once, where the cost of getting it wrong is real.

Sales makes this worse if you let it: sales oversimplifies to close the deal, onboardingThe first steps a new customer goes through to start actually using what they bought., the first real steps a new customer takes with the product, tells the truth, and the gap between the two breaks trust before the product gets a fair chance.¹¹ Validate the simplified version with your power usersA customer who uses your product far more deeply than most., the customers who already push your product hardest, before the broad rollout, not after.¹²

Hold ship discipline: buy what isn't core, stage what is.

The architectural answer to the post-mortemA look back at finished work, often failed work, to name what actually went wrong. on page 2 was not a redesign. It was splitting the build into two independent layers, run by two teams that rarely need to touch each other's work.

The service layer doesn't care how anything looks; it just has to work every time it's called. The experience layer can be figured out slowly, iterated on, or handed to a small outside team, because it plugs into services that already work in isolation. When something breaks, the right team fixes it without touching the other layer. And the same back endThe behind-the-scenes machinery of software that stores the data and does the work. ends up doing more than one job: "even if our platform has zero interface, we can walk into an account, understand what they want, and build for them a marketplace like no other" on top of the same APIA connection point that lets one piece of software talk to another automatically., the connection point that lets two pieces of software talk automatically.¹³ The split turns a technical decision into a go-to-marketThe plan for how a product reaches and wins its first customers. weapon, the plan for winning your first customers.

The diagnostic that catches architecture built the wrong way doesn't require touching code. Something small should take no time; if it keeps taking a lot of work instead, the system underneath is the problem, not the task.¹⁴ Pair that with a standing buy-versus-buildThe standing choice between paying for an existing tool and building your own. sweep, the standing choice between paying for an existing tool and building your own: don't build what you can connect. Existing tools reached over an APIA connection point that lets one piece of software talk to another automatically. cover most non-core capability better than a custom build ever will, and building it yourself is not the business you're in.¹⁵ Where you do have to touch something that already works, migrate it in stages and preserve what's functioning rather than ripping it out. Don't promise a delivery date until the thing is in testing, and hold a standing scopeThe agreed boundary of what a piece of work includes and excludes. cutoff, the sentence you say out loud the moment the client asks for one more thing before signing.¹⁶

What ship discipline looks like in practice

Every habit on this page traces back to one of the three learnings above. Write the customer's objective in their words. Cut to the smallest slice that proves it. Sweep for what you can buy instead of build. Count the choices you're handing a first-time user, and cut until the first action is obvious.

1. Name the objective, not the roadmap.Write the customer's objective in one sentence, in their words, not yours. If your roadmapThe ordered plan of what you intend to build or do next. can't be traced back to that sentence, it's not validated yet.
2. Cut to the slice that proves demand.Everything that doesn't ship this round goes on a "demand pulls it" list, not a backlogThe waiting list of features or tasks you have noted but not committed to. you've already committed to building.
3. Sweep for buy-versus-build.Mark every remaining capability an existing APIA connection point that lets one piece of software talk to another automatically. or tool already covers. Cut those from the build plan entirely.
4. Count the first-session choices.Count every decision your user faces before their first real action. Cut until it's obvious. One question per screen where you can manage it.