Founder research guide

How to validate a SaaS idea before you build

Startup idea validation means testing the assumptions behind a product, not collecting compliments about an idea. Use this sequence to decide what evidence you need next.

Start with one customer and one workflow

Write a hypothesis you could disprove: “Independent agencies with several active clients lose billable time reconciling project updates across tools.” This is more useful than “Everyone needs a better project management app.” Name the person doing the work, the triggering event and the consequence of the problem. Include what you do not know, such as how often it happens or who controls the budget.

Choose a narrow segment first. A freelancer, an agency operations manager and an enterprise IT team can use the same product for different reasons. Mixing their complaints can make a broad market look more consistent than it is.

Research the alternatives customers already use

List direct competitors, spreadsheets, manual services and the option of doing nothing. Collect recent customer complaints about the specific workflow. Keep the product, source URL, date and relevant quotation beside each observation. Count independent examples rather than counting repeated versions of the same review.

NicheRadar’s shared discovery feed currently uses App Store reviews, including reviews of business-software apps. Those can suggest questions about a SaaS product’s mobile experience; they do not represent every web-only customer or prove that a market will pay. Broader B2B SaaS market research needs additional sources and direct customer conversations.

Use competitor gap analysis to compare the workflow across alternatives. Separate a temporary bug from a persistent limitation, and check whether an existing plan, integration or setting already solves it.

Ask about the last time it happened

Interview people in your chosen segment. Ask for a recent example before describing your solution. Useful customer discovery questions include:

  • What happened the last time you completed this workflow?
  • Which steps did you repeat or move into another tool?
  • What did the workaround cost in time, money or missed work?
  • Which alternatives have you tried, and why did you keep or leave them?
  • Who would approve a change, and what would make switching difficult?

Record contradictions as carefully as supporting answers. Someone liking a concept is different from someone having the problem, making a purchase decision or agreeing to change an existing process.

Test a small commitment

Choose an experiment tied to your riskiest assumption. A clickable prototype can test whether people understand a workflow. A manual service can test whether the outcome is valuable. A clearly described pilot can test willingness to invest time or budget. Explain what exists today and what the participant will receive; do not present a concept as a finished product.

Set a decision rule before running the experiment. For example, decide which customer behavior would justify a pilot, what would make you narrow the segment and what would make you stop. There is no universal number of interviews or signups that validates every business.

Keep a record of what changed your mind

Maintain a short evidence log: assumption, observation, source, competing explanation and next action. Missing evidence should remain missing. Review volume, keyword searches and opportunity scores can help prioritize research, but they are not a revenue forecast.

To begin, find customer pain points, inspect the sample research dossier, or create a free workspace to organize your research.