The greatest danger facing a new venture is spending its time and money building something nobody wants. That is why methods developed that treat a venture as a series of small experiments. In this chapter we present the lean startup method, the types of minimum viable product, the stages of design thinking, the concept of the pivot, and the role of AI tools in testing.
After studying this chapter, you should be able to:
Imagine a team that spent six months coding an app for booking football fields, spent a large sum on its design and development, launched it, and discovered that young people book fields by calling a field manager they know, and see no need for an app. The team could have discovered this in a single week had it tested before building.
This story repeats itself often, and it is why methods emerged that treat a new venture differently: instead of planning at length and then executing, test small, learn fast, then decide. This chapter presents two complementary methods: the lean startup and design thinking.
Eric Ries set out this method in The Lean Startup (2011), drawing on Steve Blank's ideas about customer discovery and on Toyota's "lean production," which focuses on reducing waste. The core idea is that the biggest waste in new ventures is building something nobody wants. So the goal of a venture at the start should be validated learning: knowing, with evidence, what the customer actually wants.
A lean venture works in a repeating loop, and the faster the loop, the faster the learning:
Every experiment starts with a clearly written hypothesis, so that you know in advance what you are testing and when the experiment counts as a success. A useful template:
Notice that the hypothesis sets a number before the experiment. If only 3 households subscribe, you cannot say "the result is fairly good," because you decided in advance what success means.
A minimum viable product is the simplest version of a product that lets you learn from real customers with the least effort and cost. The concept is often misunderstood: it is not a poor version of the final product, but an experiment designed to answer a question. It may need no coding or manufacturing at all.
There are many kinds, listed here from the simplest to the most committed:
You draw the app's screens or the service's stages on paper and ask the user to "use" them with a finger while you flip the pages. It quickly shows whether the user understands the idea and how to use it. Its cost is almost zero, and it takes an hour.
A simple web page that describes the service as if it already existed, with a "Register your interest" or "Reserve your spot" button. You post the link where your customers are and measure: How many people visited the page? How many signed up? The sign-up rate indicates real interest. Such a page can be built today with free tools and no coding.
A short clip showing how the service will work. It is used when the product is hard to build but easy to explain. You publish it and measure engagement, questions and sign-up requests.
You deliver the service manually, yourself, to a small number of customers, who know you are doing it by hand. Example: before building a delivery app, you take orders via WhatsApp and deliver them yourself to twenty customers for two weeks. You will learn what people actually order, when, and what annoys them, before writing a single line of code.
The name comes from the story of the wizard who appears mighty and turns out to be an ordinary man behind a curtain. The customer sees an interface that looks automated or intelligent, but a person is working behind it by hand. Example: a "smart book recommendation" service where the customer fills in a form and receives recommendations within an hour, while a team member writes them personally. The difference from the concierge MVP is that the customer does not know the work is manual.
You offer the product for sale before making it, and the customer pays in advance or commits to buy. This is the strongest possible evidence of demand, because paying is a real commitment with no politeness in it. Crowdfunding platforms rely on it.
| Type | What it mainly tests | Strength of evidence |
|---|---|---|
| Paper prototype | Understanding and ease of use | Weak to medium |
| Landing page and video | Interest in the idea | Medium |
| Concierge and Wizard of Oz | Actual use and operational details | Strong |
| Pre-order | Willingness to pay | Strongest |
Design thinking is a problem-solving approach that puts the human being at the center of the process: it starts with a deep understanding of people's needs, feelings and behavior, then designs solutions with them and for them. It grew out of the way designers work, and was spread by the design firm IDEO and Stanford University's design institute (the d.school). Tim Brown, IDEO's chief executive, describes it as an approach that balances three things: what people desire, what is technically feasible, and what is commercially viable.
Design thinking differs from the traditional way of solving problems in two respects: it does not jump to a solution before understanding the problem from the person's point of view, and it is non-linear, meaning the team moves between stages and returns to earlier ones whenever it learns something new. The Stanford d.school divides it into five stages, which we explain one at a time and apply to a single example:
The goal: to understand the people you are designing for: What do they do? What do they say? What do they feel? And what do they not say?
How? Through three main means:
In the example: the team accompanied three older people to their appointments, and interviewed five others and their adult children. They noticed that an older person arrives an hour before the appointment for fear of being late, gets lost between departments, and that his son has to take time off work to accompany him; and that what bothers the older person most is not the waiting but the feeling of being a burden on his children.
Output of the stage: observations and quotes from people, which the team sometimes organizes into an "empathy map" with four parts: What do they say? What do they do? What do they think? What do they feel?
The goal: to turn the observations you gathered into a clear definition of the real problem from the person's perspective, not yours.
How? The team gathers the observations and looks for recurring patterns and surprises, then writes a point-of-view statement in the form: "[User] needs [need] because [insight we discovered]." Then it turns it into a "How might we…?" question.
In the example: the team noticed that the problem they assumed at first ("the wait is long") was not the real problem. They wrote: "An older person who visits the hospital regularly needs to go and return independently and with peace of mind, because he feels embarrassed about being a burden on his children." And the question: "How might we help older people attend hospital appointments independently, without worrying or wearing out their children?"
Why does this stage matter? Because the definition of the problem determines the type of solutions. Had the team kept the definition "the wait is long," it would have designed a faster booking system, a solution that does not touch what really bothers the older person.
The goal: to produce as many varied solutions as possible to the question you framed, before choosing.
How? With the techniques from Chapter 3: brainstorming, reverse brainstorming and SCAMPER, with criticism postponed. The team is encouraged to propose bold ideas, because they often lead to practical solutions once adjusted. Then the team chooses 2–3 ideas to test, by voting or using evaluation criteria.
In the example: the team came up with more than thirty ideas, including: a volunteer companion from the neighborhood's young people, a dedicated transport service for older people, a printed guidance card in large type for each appointment, voice messages before the appointment, and a group of older people who go together. They chose two: "a trained companion from health-sciences graduates" and "a personal appointment guidance card."
The goal: to make the idea tangible quickly and cheaply, so people can interact with it and comment on it. People cannot judge an idea they hear about, but they can judge something they see or try.
How? In any form that suits the idea: a sketch, a cardboard model, a printed card, acting out the situation (role play), or delivering the service manually once. The rule: do not get attached to the prototype; it is made to change, and sometimes to be thrown away.
In the example: the team designed a printed card in large type with the department name, a simple map showing how to get there, and the companion's number. They also arranged a companion trial for two appointments with three nursing graduates.
The goal: to try the prototype with real users, to learn what works and what does not, and to understand the user better.
How? Let the user deal with the prototype themselves, and do not explain too much. Observe, and after the trial ask: What did you like? What confused you? What if it were like this? Record the observations carefully.
In the example: the team discovered that the card is useful, but older people prefer the companion to call them a day before the appointment "for reassurance." They also discovered that the adult children are willing to pay for a reliable companion service, because it saves them taking time off work. Here the team went back to the define stage: perhaps the paying customer is the son, and the beneficiary is the father.
The two methods complement each other: design thinking is stronger at understanding the problem and finding the solution that suits people, and the lean startup is stronger at testing the business model (Will people pay? Can the venture grow?). Many teams start with design thinking and move to the build–measure–learn loop once the solution is clear.
When experiments show that part of your hypotheses is wrong, you face three options: persevere because the results are encouraging, pivot, or stop. A pivot, as Ries defines it, is a deliberate change in one part of the business model based on what you have learned, while keeping what has proven to work. The term comes from the basketball player who keeps one foot planted and moves the other to change direction.
Common types of pivot include:
Generative AI tools have become part of entrepreneurs' work today, and they save a great deal of time in the testing stages. You can use them to:
But these tools have limits you need to know:
In a study I conducted with 123 university students from several disciplines (Alsamani, 2026), students applied a structured protocol for collaborating with generative AI tools for two weeks within an innovative business project. They reported that this collaboration helped them prepare deeper SWOT analyses and generate innovative ideas, and that among the most useful things they did were rephrasing prompts, asking for clarification, and questioning their projects' assumptions. The key word here is "structured": knowing what to ask the tool for, when and why, and remaining the one who makes the decisions.
The practical rule: use AI as an assistant in developing and building ideas, not as a substitute for your thinking and for your own voice in writing.
The answers are on the Answers to Self-Assessment Questions page. On the interactive course page you can answer and check these questions directly, with practical tools linked to the chapter.
Write one hypothesis for your venture, and design the cheapest experiment that tests it within a week.