How to validate a startup idea in four weeks

Most startups do not fail because the product was built badly. They fail because they built something that not enough people needed. The sad part is that this can be discovered cheaply, in weeks, before the long, expensive work of building. A short, disciplined validation sprint is the best investment a new founder can make.

This guide is a four-week plan. It needs no code and little money. Its aim is not to prove that you are right. It is to find out the truth as quickly as you can, whichever way it points.

Before you begin

Write down your idea in one paragraph, and then write down what you believe has to be true for it to work. Founders usually hold three beliefs: that the problem is real and painful, that a specific group of people has it, and that they will pay for a solution. Each belief is a risk. The next four weeks are designed to test them in that order.

Week 1: define the problem and the customer

1. 01Write the problem in one sentence: who struggles with what, and when.
2. 02Name the specific customer. “Small hotels in Pokhara” is a customer. “Everyone who travels” is not.
3. 03List what these people do today about the problem, including doing nothing or using a spreadsheet. That is your real competition.
4. 04Write your decision rule now, while you are calm, for example: “If 6 of 15 people describe this as a top-three problem and 3 agree to a paid pilot, we continue.”
5. 05Make a list of 30 people you could talk to, and who could introduce you to more.

Week 2: talk to people

Interview 15 to 20 people who fit your customer description. Aim for 20 to 30 minutes each, in person or on a call. The goal is to learn, not to sell.

Ask about the past, not the future. People are poor at predicting what they will do, but good at describing what they did.

• Tell me about the last time this problem happened. What did you do?
• What did it cost you, in time or money?
• What have you tried to fix it, and what happened?
• Who else is involved in deciding or paying?

Avoid pitching your idea or asking “Would you use this?”. Almost everyone says yes to be polite, and it tells you nothing. Take notes, record the exact words people use and look for patterns across conversations, not single opinions.

Week 3: test demand with something real

Words are cheap. In week three, ask for a small commitment, because it separates interest from intent. Choose the lightest test that fits your idea.

• A simple page that explains the offer and asks for an email address, a deposit or a booking, with some effort to bring real visitors to it.
• A manual version of the service, which you deliver by hand to three to five customers. The service can be messy behind the scenes. You are testing whether people value the result.
• A pre-order, a paid pilot or a signed letter of intent.

Week 4: decide

Put your decision rule from week one beside what happened. Be as honest as you can.

• Continue: the evidence met your rule. Plan the smallest version you can build and sell.
• Change: people have the problem, but your solution, price or customer was wrong. Adjust one thing and test again.
• Stop: the problem is not painful enough or the market is too small. Stopping now is a success, because it saved you months.

What to do with what you learned

Whatever you decide, write a one-page summary: the customer, the problem in their words, what they do today, what they were willing to commit to and the main surprises. If you continue, this page becomes the heart of your plan and your pitch. If you stop, it protects the next idea.

Mistakes founders make

• Talking only to friends and family, who want to be kind.
• Describing the solution too early, and so biasing the answers.
• Counting enthusiasm as demand.
• Skipping the decision rule, then explaining away poor results.
• Building a polished product before testing a rough one by hand.

A worked example: a guide-booking idea

A founder wonders whether to build an app that connects trekkers with local guides.

• Week 1: the problem is that trekkers struggle to find trustworthy guides at a fair price. The customer is independent trekkers planning a trip to a particular region. Today they rely on forum posts and agencies. The decision rule: continue if 8 of 20 trekkers say they would book through a platform and 3 agree to pay a deposit.
• Week 2: she interviews 18 trekkers. Most have trouble judging trust, and few care about an app. They want reviews and a clear price.
• Week 3: she builds a simple page listing three guides she knows, with prices and reviews, and a button to request a booking. She shares it in two trekking groups. Twelve people request bookings, and four pay a small deposit.
• Week 4: the rule is met. She decides to continue, but to begin with a handful of guides and handle bookings by messaging, not building the app first.

In four weeks and almost no money, she replaced a guess with evidence and discovered that the app was not the first thing to build.

An interview script you can copy

1. 01Tell me about the last time you planned a trip like this. What did you do?
2. 02What was the hardest part? What did you try?
3. 03What did it cost, in money or time?
4. 04Have you paid someone to help? How did you choose?
5. 05If this were solved, what would be different?
6. 06Who else is involved in the decision?
7. 07Would it be all right if I came back with something to try?

Frequently asked questions

How many interviews are enough?

Around 15 to 20 with the same type of customer is a good start. You will usually hear the same themes repeat before you reach the end.

What if people say they like the idea but won’t commit?

Treat it as a no. Politeness is not demand. Ask what would have to be true for them to commit, and learn from the answer.

Do I need a prototype to validate?

Not at first. A page, a conversation or a manual service tests demand far faster than software.

When is it right to stop?

When your own decision rule, set in advance, is clearly not met after honest testing, or when you learn that the problem is too small or the customer cannot pay.

The aim of validation is not certainty. It is to replace hope with evidence, so that when you do start building, you are building something that real people have already told you, with their time and money, that they want.