Does Building a Smaller Version Really Count as Validation?

I recently watched a video from 理性避難所 about MVPs. Its example of selling shoes online made me reconsider what we mean by building a first version.

The video uses Zappos's early approach: put photographs of shoes online, then obtain and ship the goods when someone places an order. Before investing in a complete warehouse and operating process, it asks an earlier question: will anyone buy shoes this way?

The shoe-selling example comes from this video. It reminds me to choose what we want to validate first, rather than start by building everything.

The point I most want to keep is this: the important part of MVP is not the MV, or the P. It is the experiment you want to run.

Do not first decide how small a product to build. Decide what to validate, then how much you need to build. What do you believe? Which assumption remains uncertain? Which result would make you continue, adjust, or stop?

This is close to the intent of the Lean Startup approach: learning through trying and observing, rather than treating a small version as the goal. In Chinese, the approach is called 精益創業; the Taiwanese edition uses 精實創業：用小實驗玩出大事業.

Beyond selling shoes, I also think of Dropbox's early demonstration video. Founder Drew Houston has shared its story: a concrete demonstration helped people understand a way of using the product that was otherwise difficult to explain, and attracted attention.

To me, the lesson is not that making a video is enough to start a company, or that Dropbox had done no product development. It is that a demonstration can be part of an experiment when you want to find out whether people understand the idea and are interested in using it. You do not have to complete every part of full-scale operations before observing reactions. But interest does not establish long-term use, willingness to pay, or viable operating costs.

Webvan shows me the other side. The company delivered groceries ordered online. Ben Foster, who worked at Webvan, recalls that it built expensive warehouses and order fulfillment infrastructure for large-scale operations before demand had caught up.

This does not mean warehouses are unimportant. It means the order matters. My interpretation is that, before investments that are difficult to reverse, we should ask whether enough people will buy frequently enough, and whether that demand supports delivery and operating costs. We cannot turn “people should need this” into an answer, then build that assumption into a warehouse.

Together, the examples remind me of more than spending less. Zappos first tried completing the shoe purchase. Dropbox used a demonstration to help people understand and express interest. Webvan's retrospective warns against building scale before demand and the business model are established. The questions differ, so the experiments should not all look the same.

What I mean is not “get something out first and make it good later.” It is to use an experiment small enough, but sufficient to answer a question, to decide whether the next step is worth taking. Neglecting quality that should be under control gives you a poorly made version—not necessarily a reliable answer.

An experiment also has limits. Willingness to place an order does not automatically validate logistics, costs, or the long-term business. Knowing one thing also means knowing which questions remain unanswered.

Before a new project, I want to agree with the person bringing the request on what result, after the first step, will justify further investment.

They may not know how to describe the scenario or set metrics for us. From the difficulty we already understand, we can propose an approach: what we want to find out, what we will observe, and what we cannot yet guarantee. Then ask them to correct it.

We help design the validation method. Customers should not have to learn MVP theory before they can work with us. We should also agree how much time they need to invest and which authorized data they must provide.

If you are assessing a new service and do not yet know whether people will use it or pay for it, this question needs an answer before a complete feature plan does.

When a new request arrives, it is easy to start thinking about features.

Do we need an app, a login, data integrations, or an administrative interface? Feature by feature, the plan becomes more complete, and the work seems to move forward.

Returning to the shoe example, I would pause at one question: does making that feature plan smaller tell us the idea is worth pursuing?

When we say “build a first version,” we may mean different things.

Sometimes customers already know what they need. The workflow and delivery scope are agreed. A first version makes that agreed work usable, with improvements to follow.

Other times, we do not yet know whether the problem matters enough, whether users will change their habits, or whether someone will pay. Yet we are already planning how long it will take to build.

Both can be called MVPs.

But they need to answer different questions.

If we are still validating demand, the first step may not require a complete system. We could choose one real scenario and one sample, help someone complete the work manually, and observe which part matters most to them.

Suppose the problem is finding information. Start by watching a real search: how long it takes now, what people get wrong, and whether they can proceed after finding it. Before that is clear, a more polished interface may not make the answer clearer.

If someone first wants to see our capabilities, we can use de-identified or illustrative data to demonstrate a candidate approach. That may make it easier for them to identify what does not fit their workplace. But demonstrating feasibility and improving actual use are different things. The latter still needs to be checked against real work.

I also want to agree which response makes further work worthwhile.

Saying an idea is interesting is one response. Arranging actual use, or discussing payment and adoption, are others. We cannot count them as the same thing.

If data is not immediately available, that does not prove there is no demand. Permission may be missing, or we may have asked for too much preparation. First see whether we can narrow the request to one sample, one operation, or the right person to authorize access. If necessary evidence remains unavailable, explain the limits of what we can do. Do not present a demonstration as a validated result.

If results fall short, we also need room to reconsider. The problem may not be important, the method may not fit, or we may have chosen the wrong use scenario. Understand which before deciding what comes next.

This does not mean every task should be done casually.

Customer data, payments, and professional judgments still need appropriate permissions, review, and tests. We can narrow the scope of validation; we cannot narrow away necessary responsibility.

Nor can we remove agreed development and delivery commitments afterwards by saying it was only an MVP.

The moment I want to change is earlier.

While deciding whether to invest, write down the greatest uncertainty and choose a method that has a chance of answering it. Do not wait until everything is built to ask whether anyone actually needs it.

In the next project discussion, I want to leave some time for this question.

After the first version, what do we hope to know that we do not know now?

— Adam｜metabiz Founder

Further viewing: 理性避難所｜MVP and Lean Startup. Read the Chinese original.