How do we find the real problem when we started from the solution?

Many corporate innovation concepts do not begin with a customer problem. They begin with something the company already has. A technology that works. A manufacturing asset with spare capacity. A dataset nobody has monetized. A distribution relationship. A capability the company is known for. Someone sees potential in it, and it becomes a solution looking for a problem.

That can be a legitimate place to start, and plenty of real businesses began exactly that way. But it leaves a specific piece of work undone, and it is the piece teams often skip: nobody has established that the problem the concept now claims to solve is real, that enough customers have it, or that they are dissatisfied enough with how they handle it today to change what they are doing.

The concept then moves forward carrying an assumption that was never examined. And because the assumption is about the customer rather than about the technology, the technical work can go extremely well right up until the moment the business does not materialize.

Three ways an assumed need goes wrong

The first is the one people are most likely familiar with. Someone becomes personally attached to the solution. They have lived with it, they can see what it could be, and their conviction outruns the evidence. The need gets assumed, or assumed to be much larger than it is.

The second is sneakier and more common in technically strong companies. The technology can do something, so the team assumes there’s a viable market that needs it done. Those are different claims. A process that runs faster, an output that is more accurate, a task that takes fewer steps: each is a genuine improvement but none of them automatically implies a problem worth paying to solve. The gap between “this is better” and “this is better in a way that matters enough to change behavior” is where a lot of retargeted solutions get snagged. A related version of the same error is assuming that the improvement addresses the whole problem, or the most important part of it, when it addresses one part of a job the customer has to complete some other way regardless.

The third is the one that catches experienced companies with real assets. A capability that is genuinely differentiating in one market is assumed to be just as differentiating in another. Intel spent decades winning the personal computer market on raw processor performance, which was the attribute that market valued most. When mobile computing arrived, the attribute that decided the market was performance per watt of battery power and super low power sleep states, and designs based on the ARM architecture delivered it. Intel’s asset and its differentiation in personal computers were real. But it was differentiation on the attribute that mattered less than the ones it was missing in the new use case.

What all three have in common is that the need was assumed rather than discovered, and was never stated in terms that could be compared against what the customer already does.

Start by establishing that there is a problem at all

The correction is not necessarily to abandon the solution. It is to go and find out what customers are actually trying to accomplish, and which parts of it they are unsatisfied with, without steering the answer toward the thing you already have. The solution you’re assuming may be just one small change away from being the right answer, or it might require starting from a clean slate.

That means open-ended inquiry rather than just validation. A question framed around your solution gets you agreement, because people are agreeable and because describing something useful invites people to say it sounds useful. A question framed around what the customer is trying to get done, what they currently do about it, what that costs them and what they have already tried gets you something you can act on. The critical discipline needed is that the conversation should be capable of telling you that your assumptions are wrong.

There are at least three things worth establishing before going further. Is the problem real, meaning customers recognize it without being prompted. Is it present at enough scale to support a business. And is it poorly enough served today that someone would actually switch.

All three are demand-side questions, which is what Desirability focused evaluation criteria cover. Scale belongs there at this stage too, read qualitatively as how broadly the need is felt rather than as a market size. The other two lenses, execution Feasibility and financial Viability, rest on choices that cannot be made well until the demand side and solution requirements are understood.

The third test is where many hypotheses break, because the alternative customers currently use rarely appears on a competitive slide. It is often a manual workaround, a partial tool, or simply tolerating the problem. It is also often a real competitor.

Then find where the value actually is

Establishing that a problem exists is not the same as knowing what a solution has to do. That requires understanding the full set of things the customer is trying to accomplish, and how they rank.

A solution-first origin truncates that set in a predictable way. The team examines the one job the technology addresses, for the one person who would use it, at the one point in the process where it applies. What goes unexamined is everything around it: the other people involved in the decision and in living with the outcome, the phases before and after the main use of the solution, and the outcomes that are not functional at all. Confidence in a decision, defensibility to a boss, and the risk someone carries personally if it goes wrong are all things customers are trying to achieve, and they can often outrank the functional improvement on offer.

Our jobs-to-be-done page covers how to frame these properly and why a job is the front end of a strategy rather than a research artifact. The part that matters for a concept that started from a solution is scope and rank. Scope, because the jobs you did not look for are the ones that determine whether your improvement is sufficient. Rank, because a complete list is not a priority order, and a solution that satisfies several low-ranked jobs while leaving the highest-ranked one untouched will lose to an alternative that does the reverse.

Then find what is underserved

Real competitive differentiation lives in a narrow place: the aspects customers consider highly important and are poorly served by existing alternatives today.

That is a more demanding test than it sounds, and it is why the work has to become measurable rather than descriptive. Importance and current satisfaction have to be assessed for each thing the customer is trying to achieve, across the alternatives they actually use. What falls out is a much clearer picture than a feature comparison provides. Some aspects are important and badly served, and that is where a defensible position exists. Some are important and already served well, and competing there means matching a strong incumbent on their own ground. Some are already served beyond what anyone needs, and further improvement there buys nothing, which is exactly the trap a company with a strong technical asset walks into. And some simply do not matter much, whatever the engineering effort they would absorb.

Expressed this way, the needs become requirements: specific, comparable statements about what a whole solution has to deliver and how well. That is what makes a concept evaluable against alternatives instead of argued about, and it is the foundation for defining what the whole solution has to include. It is also the honest test of an inherited asset. If the attribute your capability leads on turns out to be one the market considers adequately served, you have learned something expensive early rather than late.

Why the usual tools leave gaps

Most teams already have tools that touch this work. Survey tools collect answers quickly, but the questions are usually framed around the solution, which makes them good at validation and poor at discovery. Interview notes end up in documents and shared drives, where they are hard to compare across conversations and rarely get reused. Product management and roadmapping tools capture requirements and feature requests, typically from existing customers, and rank them by how often they are asked for rather than by how important and poorly served they are. The opportunity scoring, where it happens at all, lives in a spreadsheet built for the occasion.

What is missing is a connected path from the conversation to the job to the scored requirement, so that each step builds on the evidence of the one before.

There’s an app for that: how Growth Forge® Software addresses this

Growth Forge provides that path, with a tool for each step and the output of one feeding the next.

Problem Discovery is where the inquiry happens. It includes a baseline discovery script written as open-ended, non-leading questions, with guidance on what to listen for in the answers. You can run it as it stands, edit it, or write your own. Responses are captured as reusable evidence rather than notes. AI Summary Assistants then roll up insights per question across interviews, preserving the interviewee’s voice, surfacing contradictions, and marking a question unanswered rather than inferring an answer.

Jobs to Be Done is where what you heard becomes structure. Each need is captured as a solution-agnostic job, tagged by who performs it, where it sits in the customer journey, how often it occurs, and whether the outcome sought is functional, emotional or social. The frame also records how people get the job done today. Those tags are what make the scope problem visible: a job list covering one performer at one journey phase looks obviously thin once it is laid out this way.

Requirements Definition is where it becomes comparable and informs a real solution. Each job translates into one or more measurable requirements, scored for importance and current satisfaction with the evidence behind each score. Those two scores place each requirement on an opportunity map: underserved, appropriately served, overserved, or unimportant. Underserved is where differentiation is available. Overserved is where additional performance earns nothing. Requirements can then be flagged for competitive benchmarking, which carries the analysis into the competitive work that follows.

The output is a prioritized, evidence-backed statement of what the solution has to do and how well, traceable back to the customer conversations it came from.

What no software can settle

None of this addresses why the concept started from the asset in the first place.

Teams reverse-engineer a problem or a market because the asset is what the company already has, what it already knows how to do, or a need the team itself feels that the rest of the world does not, or is content to meet with something that already works well enough. Those are reasonable responses to how new work actually gets approved.

Changing the pattern means changing what a proposal has to contain before it receives resources. If a concept can be funded on the strength of the asset and the story, teams will keep leading with the asset and the story. If it has to arrive with evidence that the problem is real, present at scale, and inadequately served, discovery stops being optional work that a confident champion can skip. That is a decision about how the organization allocates early money, and it has to be defined and held by someone inside the organization, usually the person running the innovation function. An outside perspective can help design it and can sometimes argue for it more freely, but the internal work of enforcing it belongs to whoever owns the function.

Putting it into practice

When a concept starts from a solution, a few steps test whether the problem behind it is real. Run open-ended conversations framed around what customers are trying to get done, not around the solution. Establish whether the problem is recognized without prompting, present at enough scale and poorly served today. Turn what you learn into requirements scored for importance and current satisfaction, and check whether the capability you started from lines up with the underserved ones. These steps can be worked through with a framework, facilitated by an experienced consulting firm, or with purpose-built software such as Growth Forge, where Problem Discovery, Jobs to Be Done and Requirements Definition provide the guidance and the analysis. Whether the technology works still matters. On its own, it is not what decides whether there is a business.

If the gap is not in how your teams discover and prioritize customer needs but in whether your organization is set up to require that work before committing money, our Innovation Capability Assessment is a short scored read on where that stands.

Next in this series: choosing where a new venture sits in its value network, instead of inheriting the core business’s position by default.

BRI Associates helps companies grow by drawing on decades of practitioner experience in corporate innovation and new business development — practitioners, not pundits or academics — through direct consulting, training workshops, and Growth Forge® Software, built for the unique requirements of corporate innovation and growth organizations.