Prioritizing what to build

Right now you are probably tempted to build everything you have dreamed of. This lesson is about the opposite: building as little as possible while learning as much as possible. The art is to figure out what must be true for the idea to work — and test exactly that first.

The MVP mindset

MVP stands for "minimum viable product." The most common misunderstanding is that it means a cheap, half-finished version of the final product. It does not. An MVP is the smallest experiment that teaches you what you are most unsure about. Sometimes it is not a product at all.

There are several types:

• Landing-page MVP: A simple page that explains the offer, with a button to register interest. You measure whether people click and leave an email.
• Concierge MVP: You deliver the service entirely by hand to your first customers, with no technology. Maria can match dog owners and sitters manually by phone and payment app before building anything.
• Wizard-of-Oz MVP: From the outside it looks automated, but behind the scenes you do everything manually.
• Single-feature MVP: One single feature, done properly, instead of ten half-finished ones.

Jonas did not need to build the whole accounting tool to test whether firms wanted automatic reconciliation. He could offer to do it manually for three customers and see if they followed through.

Prioritize by value and effort

When choosing what to build first, a simple four-square grid helps: value to the customer against effort for you.

• High value, low effort: Do this first. These are the quick wins.
• High value, high effort: Plan it, but break it into pieces.
• Low value, low effort: Can wait.
• Low value, high effort: Avoid. This is a time sink.

Draw the grid, place your features, and be honest. Almost everyone overrates the value of their own favorite feature.

Map assumptions and risk

Behind every idea sits a stack of assumptions you believe without proof. "People will pay." "Sitters will sign up." "I can reach the target group at a reasonable cost." Write them all down.

Then sort them along two axes: how sure are you, and how much depends on it being true? The assumption that is both uncertain and decisive is your biggest risk. That is the one to test first — not the one that is easiest to test.

Frame hypotheses you can test cheaply

Turn the most dangerous assumption into a testable hypothesis. A workable form: We believe that [this is true]. We will know we are right if [this measurable thing happens].

"We believe dog owners will pay for safe sitting. We will know we are right if at least ten of fifty landing-page visitors leave card details for a pre-order." Now you have something concrete to test in the next module, instead of a gut feeling.

Keep the MVP honest

An MVP should still give real value to the person using it. "Viable" means it can stand on its own: a product so stripped down that it solves nothing tests nothing but people's patience. Distinguish between cutting scope and cutting quality. You can launch with fewer features, but the few you have should work properly.

A useful image: do not build half a vehicle. If the goal is to move someone from A to B, a complete bicycle is a better first version than a car chassis with no engine. The bicycle does the job in a small way; the chassis does nothing until everything is in place. So always ask: what is the smallest complete thing that does the job for one real user?

Do this now

Write down all the assumptions your idea rests on. Rank them by risk: uncertain and decisive at the top. Take the top one and rewrite it as a single testable hypothesis in the form "We believe that… We will know we are right if…". Then choose which MVP type lets you test it as cheaply as possible. You will carry that plan into the prototyping module.