Look Before You Leap: Validating a Product Idea Before You Build
The idea that seemed worth pursuing
Pradeep, a technology entrepreneur, identified a problem that many businesses face as they grow: organisational knowledge becomes scattered across emails, PDFs, spreadsheets, chat conversations, notes, and other systems.
Finding information is one challenge. Reconstructing the history behind a decision is another.
Imagine a team trying to understand how a problem was solved previously. What approaches were attempted? Which ones failed? Why was one option rejected in favour of another? What ultimately worked, and what evidence supports that conclusion?
The answers might already exist somewhere in the organisation. But finding them could require hours of searching across multiple sources, piecing together conversations, and connecting information that was never deliberately organised.
Pradeep saw an opportunity to make this knowledge accessible through natural-language questions. Instead of searching for files or remembering keywords, users could ask questions and receive meaningful answers drawn from their organisation's accumulated knowledge.
It seemed like a worthwhile problem to solve.
But before writing a single line of production code, Pradeep needed to answer a more fundamental question:
Was there a product here that businesses would actually need to buy?
Testing the idea against existing AI tools
Pradeep decided to investigate what existing AI tools could already do.
He started with a seemingly straightforward use case: asking questions about business data.
For example, could an AI assistant examine a financial ledger and answer a question such as “How much revenue has a company generated since inception?”
In his experiment, Google Gemini could answer the question using the available information, including billed amounts, payments received, outstanding amounts, and invoice-level details.
That was useful, but it raised an uncomfortable question: if an existing tool could already retrieve information and make sense of it, how much additional value would a separate product provide?
Perhaps the opportunity lay in something more sophisticated than searching organisational data. A dedicated product might reconstruct the history of a problem across multiple sources, identify what had been attempted, distinguish abandoned approaches from implemented ones, and establish what had worked.
That was closer to the original product vision. So Pradeep tested this more demanding proposition.
The harder test: could AI reconstruct organisational history?
Pradeep began exploring whether Gemini could piece together a complex history from emails and other available information.
Could it identify what had been tried? Could it distinguish between an approach that was merely discussed and one that was actually implemented? Could it explain why an option had been abandoned, describe the eventual outcome, and point to the supporting evidence?
These questions went beyond simple information retrieval. They tested the very capability that was supposed to differentiate Pradeep's proposed product.
Google's Gemini performed well on the scenarios he tested.
This finding mattered because it challenged a central assumption behind the idea: that reconstructing organisational history would, by itself, provide a sufficiently compelling reason for customers to adopt a separate product.
The result did not establish that Gemini could solve every organisational knowledge problem, or that a specialised product could never do better. Nor did it demonstrate that every potential customer would find existing AI tools adequate. It showed something more specific: in those scenarios, the proposed differentiation was less convincing than he had initially expected.
That was valuable information to discover before committing substantial development effort.
Pradeep could have continued building, reasoning that a dedicated application would offer a better interface, a more specialised architecture, or greater control over the underlying data.
The question was no longer simply whether the product could be built.
It was this:
What would make a customer choose it over the tools they already had?
A real problem does not automatically make a viable product
Pradeep's original hypothesis was that businesses needed a better way to search and retrieve their accumulated knowledge. His experiments suggested that this capability alone was not enough to establish a compelling product proposition.
A product opportunity rests on several assumptions:
The problem occurs frequently enough to matter.
The people experiencing it consider it important enough to address.
Existing tools do not solve it adequately.
A new solution can deliver a meaningful improvement.
Customers are willing to pay for that improvement, and adopting the solution is practical.
These assumptions are related, but they are not interchangeable.
A problem can be genuine without being sufficiently painful. It can be painful without customers wanting a separate product. And a product can work exceptionally well without offering enough additional value to justify its cost.
Pradeep's experiment did not invalidate the underlying problem, but it made continuing with the original proposition without further investigation difficult to justify.
This is an important distinction in early product development:
Validating that a problem exists is not the same as validating that a particular product is worth building.
The temptation to find a reason to continue
Once an idea has captured a founder's imagination, it becomes tempting to look for reasons to preserve it.
Perhaps a competitor's interface is inadequate. Perhaps its architecture is too general-purpose. Perhaps a specialised solution would produce more accurate answers. Perhaps customers would prefer a dedicated application.
Any of these arguments could be true. But each is a hypothesis that needs to be tested, not an excuse to dismiss inconvenient evidence.
The danger is to respond to an unsuccessful differentiation hypothesis by adding technical sophistication and assuming the resulting product will be more valuable.
This is where the distinction between validating an idea and defending one becomes important.
Validation means actively looking for evidence that could prove an assumption wrong. Defending an idea means finding ways to explain away evidence that challenges it.
The first can save months of development effort. The second can turn months of effort into a sunk cost.
Perhaps the product isn't search at all
Pradeep's experiments suggested a different way to approach the opportunity. Instead of asking how to build a better organisational search tool, he could investigate which specific business problems remained difficult even when people had access to capable AI assistants.
Consider a few possibilities.
A service organisation might need to identify recurring failure patterns across thousands of maintenance records, connect them to previous interventions, and recommend the next diagnostic step.
A professional services firm might need to turn project histories into structured delivery knowledge, identify recurring risks, and incorporate those lessons into future project planning.
A business with complex operational processes might need an auditable record of how decisions were made, what evidence supported them, and whether the expected outcomes materialised.
These are possible directions, not validated opportunities. Existing tools might already handle parts of them well, and each would need to be evaluated on its own merits.
But they lead to a more useful question: could a product own a specific workflow, deliver a measurable business outcome, or address requirements that general-purpose tools do not adequately satisfy?
That is a different starting point for product development. It begins with an outcome the customer values rather than a capability the technology makes possible.
It also changes what the founder needs to validate. Instead of demonstrating that the product can answer questions, the founder must establish that it solves a consequential problem better than the alternatives—and that customers consider the improvement worth paying for.
What this teaches us about early product validation
Pradeep's experience illustrates five lessons that are easy to overlook when an idea initially looks promising.
Do not mistake a problem for a product opportunity.
Recognising a genuine problem is valuable, but it does not establish that a new product is necessary. The founder still needs a credible reason why customers would choose the proposed solution over their existing alternatives.
Test existing solutions before building a new one.
Feature lists and marketing claims reveal only so much about competing products. Testing what those products can actually accomplish can expose assumptions that might otherwise go unchallenged until much later in development.
Test the hardest part of the hypothesis first.
If the proposed differentiation is the ability to reconstruct complex histories across multiple sources, that is precisely what should be tested before development begins. Demonstrating a capability that existing tools already handle well is not sufficient validation.
Do not equate technical sophistication with customer value.
A product can involve specialised models, complex data pipelines, advanced retrieval systems, and carefully designed architectures without solving a problem customers are willing to pay to address. Technical choices matter when they contribute to an outcome customers value.
Be willing to change the original proposition.
The initial product idea may be wrong even when the underlying problem is real. The appropriate response might be to narrow the scope, choose a specific customer segment, change the workflow, or conclude that an existing solution is already good enough.
These lessons do not, by themselves, establish product-market fit. They help founders decide whether an opportunity deserves further investment and identify what evidence they need to gather next.
Technical experiments can test feasibility and expose competitive gaps. Customer conversations and willingness-to-pay tests can help establish whether the problem matters enough for people to adopt and pay for a solution. Evidence of sustained use and customer value is needed to understand whether a product is achieving product-market fit.
Each type of evidence answers a different question, and mistaking one for another can lead founders to invest heavily in a technically sound solution before establishing that a viable market exists.
Looking before leaping
Pradeep’s tests did not prove that general-purpose AI can solve every organisational knowledge problem. They revealed something more immediately useful: the proposed product’s differentiation was weaker than expected.
The next step was to identify a business problem important enough to solve, understand where existing tools fell short, and test whether a focused alternative could deliver a measurable improvement.
No checklist can guarantee that a product will succeed. Founders need evidence from technical experiments, competitive analysis, customer conversations, and willingness-to-pay tests. The challenge is to understand what each piece of evidence establishes—and what remains unproven.
The goal is not simply to build something that works. It is to build something customers need, value, and have a reason to choose over the alternatives.
Principal Tech Advisors helps founders evaluate product ideas, challenge assumptions, and assess whether an opportunity justifies substantial development investment. The objective is to establish what should be built, who it serves, and why the proposed solution deserves investment before the cost of getting it wrong becomes too high.
Comments