How to Validate a SaaS Idea Before You Build

Describe the problem without describing your solution

A SaaS idea often arrives as a feature: a dashboard, an assistant or a new way to organise information. I first ask what situation makes that feature necessary. Describe the work, the person responsible and the difficulty they experience today without mentioning the proposed product.

This separates the problem from your preferred implementation. If you cannot explain who is affected and what they currently do, the next task is discovery rather than development. Write down what you know and which parts are still assumptions so a conversation can challenge them.

Ask for examples of current behaviour

A conversation becomes more useful when it moves from opinions to a specific example. Ask an intended user to walk through the last time the problem occurred. Understand what they tried, which tools were involved and what made the decision difficult. Listen for context that contradicts your initial idea.

Keep observations separate from interpretations. A person saying an idea sounds interesting is different from showing you an unresolved task in their current workflow. Neither is a guarantee of demand, but the second gives you a more concrete starting point for deciding what to examine next.

Choose a small test that can change your mind

Before commissioning a broad build, decide what you need to learn. You might review a simple workflow with a potential user or demonstrate one bounded task. State which assumption the exercise is meant to examine and what would make you narrow, change or stop the direction.

Validation does not eliminate uncertainty or prove that a business will succeed. It helps you make the next commitment with clearer context. When the problem and audience are understandable, a roadmap can translate that learning into a first useful version instead of a collection of guesses.

• Turn the validated problem into a product roadmap →
• Bring your product context to Build →