How do you validate a product idea before building it?

You validate a product idea by finding people who have the problem, learning how they deal with it today, and checking whether they will give you something real, such as time, a deposit or a pilot, for a better way. A good opinion about your idea is not validation. A change in someone's behaviour is.

What are you actually trying to find out?

Most ideas rest on four assumptions. Write them down before you talk to anyone.

1. A specific group of people has this problem.
2. It is painful or costly enough that they already try to solve it.
3. They would switch to your approach.
4. You can reach them at a cost that makes sense.

Founders often test only the third one by asking "would you use this?" The first two are usually where ideas fail. If nobody is already working around the problem with spreadsheets, WhatsApp groups or a part-time employee, the problem may not matter enough.

Who should you talk to first?

Pick one narrow group, not "small businesses". "Owners of coaching institutes in Pune with 200 to 500 students" is a group you can find, call and recognise. "Travel agents in Dubai who sell to Indian families" is another.

Find ten to twenty of them through your network, LinkedIn, trade associations, WhatsApp communities and local meet-ups. Ask for twenty minutes. Say plainly that you are researching, not selling.

How do you run a useful conversation?

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

Useful questions:

• Tell me about the last time this problem came up. What happened?
• What did you do about it? What did that cost you in time or money?
• What have you tried? Why did you stop?
• Who else is involved in fixing it?
• If this disappeared tomorrow, what would change?

Avoid pitching during the call. Listen for specifics: names of tools, workarounds, numbers they quote from their own business. Write those down in their own words. Those phrases later become your product copy.

What counts as a real signal?

Stronger signals, in rough order:

• They pay or put down a deposit for a pilot.
• They give you access to their data, their team or their time for a trial.
• They introduce you to someone else who has the problem.
• They ask when they can start.

Weaker signals are compliments, "send me more information" and "sounds interesting". Count them, but do not build on them.

Be wary of one loud customer. A single person who asks for many features can pull the whole product towards their needs. Look for the same problem described in similar words by several people who do not know each other. When three or four unconnected owners describe the same workaround, you have found something worth solving.

Can you test before writing any software?

Yes, and you usually should. Three low-cost tests work well.

A manual service. Deliver the outcome by hand to three or five customers. If you are building an appointment reminder tool, send the reminders yourself through WhatsApp for a month and see what breaks.

A clickable prototype. A designer or product team can build screens that behave like the real thing in a short time. Put it in front of users and watch them try to complete a task. You will find confusing steps before any code exists.

A simple landing page. Describe the outcome, show the prototype and offer a waitlist or a pilot. Send it to the group you identified, not to the general public. Track how many take the next step.

Our note on how much of an MVP to build first picks up from here, once your tests say the idea is worth building.

How do you decide to build, change or stop?

Before you start testing, write down what would count as a yes. For example: "If at least six of twelve owners agree to a paid pilot, we build." Write what would count as a no, too. Without this, it is easy to read every result as encouraging.

After the tests, there are three outcomes:

• Build. The signals are strong and the scope is clear.
• Change. The problem is real but the audience or solution needs to shift. Adjust and test again.
• Stop. People do not care enough. This is a good result if you reach it before building.

What should you have in writing at the end?

A short document is enough:

• The problem, in one paragraph, and who has it.
• What people do today and what it costs them.
• The evidence you collected, with the questions you asked.
• The first version's scope: what is in and what is left out.
• A prototype or screens.
• A recommended technical approach and a build plan.

This document is also what you hand to any development team, including ours, so a quote can be based on a clear scope instead of a guess. If you are weighing a quote you already have, a tech second opinion can show whether it matches your scope.

Where does a discovery sprint fit?

If you want help doing this properly, a discovery sprint compresses the steps above into a fixed period: research, scoping, a prototype and a written build plan, ending with a clear decision. We describe our approach under Product Development and MVP development.

This is the kind of work we do in Product Development. The starting point is the Product Discovery Sprint. If you would like to talk through your idea first, Let's Talk.