To validate a small software product idea before you build, you need to find out three things with real people: that the problem exists, that it hurts enough for someone to want it fixed, and that they would trade something real for a fix, whether that is money, time or their data. If you can answer those three questions without writing any code, you have saved yourself weeks. If you cannot, you were about to build on a guess.
Most small products do not fail because the code was bad. They fail because nobody needed them badly enough. The good news is that checking is cheap. It takes conversations, a few simple tests and some honesty about what you find.
Why Validating a Software Product Idea Comes First
Building feels like progress. A working screen is satisfying in a way that a notes document is not. That is exactly why it is dangerous: it lets you avoid the harder question of whether anyone wants the thing.
Validation is not about proving you are right. It is about finding out quickly if you are wrong, while being wrong is still cheap. A weekend of conversations can kill a bad idea. A three-month build usually cannot, because by then you are too invested to see clearly.
There is a second benefit. Even good ideas arrive with wrong details, such as who has the problem or what they would pay. Validation fixes those before they are baked into your product.
Start With the Problem, Not the Product
Write your idea as a problem statement rather than a feature list. A useful format is: who has this problem, what are they trying to do, what gets in the way, and what do they do about it today.
For example, "a LinkedIn tool" is a product. "Consultants who know they should post regularly but run out of time to write" is a problem. The second version tells you who to talk to and what to ask.
The last part matters most. What do people do today? If the answer is "nothing", be careful. Sometimes that means a huge opportunity. More often it means the problem is not painful enough to act on. If people already use a spreadsheet, a workaround or an expensive service, you have proof that the problem is real.
Talk to Real People in Your Target Group
The best early evidence is conversation. Aim for ten to fifteen short conversations with people who match your problem statement. Friends and family are tempting and almost useless, because they want to be kind to you.
When you talk to people, follow a few rules. The book The Mom Test is a good short guide to this, and its central idea is simple: do not ask people whether they like your idea, because they will say yes to be polite. Ask about their life instead.
Good questions are about the past, not the future:
- When did you last run into this problem, and what happened?
- What did you do about it?
- What have you tried, and what did you pay for it?
- What is the most annoying part?
Bad questions are hypothetical. "Would you use an app that did this?" produces a polite yes that means nothing. "How are you handling this today?" produces a story you can learn from.
Listen for emotion and for effort. If someone sighs, laughs at the mess or describes the elaborate workaround they built, that is a signal. If they shrug, that is also a signal.
Look for Evidence That Costs Something
Words are cheap. Behaviour is better evidence. As you validate a software product idea, rank what you hear by how much it cost the person to say it.
- Weakest: a compliment such as "that sounds great".
- Better: a specific complaint, told with detail.
- Stronger: they give you time, such as agreeing to a longer call or a follow-up.
- Stronger still: they give you a favour, such as an introduction to a colleague with the same problem.
- Strongest: they give you money, or commit to something that costs them, like joining a waiting list with a real email address and a real description of what they need.
You are looking for the pattern across many people, not one enthusiastic voice. Three people describing the same problem in nearly the same words is worth more than one person who loves your idea.
Test Demand With a Small, Honest Experiment
Once conversations suggest a real problem, run a cheap test of demand. The aim is to see whether strangers take a meaningful action, not just whether your friends are supportive.
A few low-cost options:
- A simple landing page. Describe the problem and the outcome in plain language, then ask for an email address or a booking. Measure how many visitors take the action.
- A concierge version. Deliver the result by hand for a handful of people. If you imagine an automated tool, do it manually first and see if people value the outcome.
- A pre-order or deposit. Nothing validates demand like payment. Even a small amount separates curiosity from need.
- A clickable mock-up. Show a few screens and watch how people react. The Nielsen Norman Group has a helpful overview of usability testing that applies even when your prototype is rough.
Be honest about what the test can and cannot tell you. A landing page with a few hundred visits tells you something about interest, not about whether people will stay. Treat results as clues.
Paul Graham makes a related point in his essay on doing things that do not scale: in the early days, doing manual work for your first users is not a failure of ambition. It is how you learn what the product should really do.
Decide What Counts as Success Before You Start
Before you run any test, write down what result would make you carry on and what result would make you stop. Without this, it is far too easy to read every outcome as encouraging.
For example, you might decide that if fewer than three of ten people describe the problem unprompted, you will rethink the idea. Or that if fewer than five percent of visitors to your landing page leave an email address, you will change the message before spending more. The exact numbers depend on your market, so choose ones that you would genuinely act on.
Writing it down in advance protects you from your own optimism, and it turns the decision into a comparison rather than an argument with yourself.
Map How the Person Would Actually Use It
A good product fits into someone's day. If your idea needs people to change a habit, remember a login or move data between three tools, that friction counts against it.
Sketch the path from the moment someone feels the problem to the moment they get the result. A customer journey map is a handy way to do this even for a product that does not exist yet. Note every step and every point where someone could give up.
It also helps to list the places your product would touch the person, such as the sign-up screen, the first email and the moment of first value. These are your customer touchpoints, and thinking about them early shows you where the idea is fragile. Many products with a good core idea fail because the first five minutes are confusing.
Know When to Build, Change Direction or Stop
At the end of your validation work, you will usually land in one of three places.
Build. People describe the problem in similar words, they already spend time or money on workarounds, and a meaningful share took a real action in your test. Build the smallest version that delivers the core outcome, and nothing more.
Change direction. The problem is real but you were wrong about the details. Perhaps a different group feels it more strongly, or the real pain sits one step away from where you aimed. This is a good result. You learned something expensive for free.
Stop. Nobody described the problem, nobody acted and the workaround is good enough. Stopping here is not failure. It is the whole point of validating, and it frees you to spend your effort on something that has a better chance.
If you do build, keep the loop going. Launch to a small group, watch what they actually do and keep asking questions. Validation does not end when you start building. It becomes how you decide what to build next, a loop the Lean Startup method describes as build, measure, learn. You can see how we approach this in the products we build and run ourselves on our products page.
Common Mistakes When You Validate a Software Product Idea
- Asking friends. They love you and will tell you what you want to hear.
- Pitching instead of listening. If you spend the call describing your solution, you learn nothing about their problem.
- Testing with the wrong audience. Ten enthusiastic people who do not have the problem prove nothing.
Frequently Asked Questions
How long does it take to validate a software product idea?
For most small products, two to four weeks is enough to get a clear signal. That usually covers ten to fifteen conversations and one small demand test. If you cannot find people to talk to in that time, that is itself information about how reachable your audience is.
How many people do I need to talk to?
There is no magic number, but patterns tend to appear after ten or so conversations with people who truly match your target group. If you keep hearing new problems rather than the same ones, you may need to narrow who you are talking to.
Can I validate an idea without any technical skills?
Yes. Conversations, landing pages, manual versions of the service and mock-ups need very little technical skill. Many people validate an idea entirely with interviews, a form and a spreadsheet before involving a developer.
Is a landing page test enough to validate an idea?
On its own, no. It shows whether your message attracts interest, but not whether people have the problem or will pay. Use it alongside conversations and, where you can, a real commitment such as a deposit or a booked call.
What should I do if the idea does not validate?
Look at what you learned before you give up. Often the conversations point to a nearby problem that is more painful. If nothing does, stop with confidence and move on. You have spent days instead of months.