Are you solving the right problem? How technology leaders should validate before they build

Many technology initiatives begin with something that already sounds like a solution. A team may say it needs an AI assistant, a new reporting dashboard, or a replacement platform, but none of those statements defines the underlying problem.

Even if a software project is delivered on time and the architecture looks solid, it can turn out that customers use a feature differently than expected, or that leaders discover a simpler approach would have created more value.

This is why the most important decisions happen before writing a single line of code. Understanding and validating what the actual problem is early helps teams focus on the solution most likely to improve the user experience, support business priorities, and justify the investment.

Before leaders commit to development, they should be able to answer two questions clearly: Are we solving the right problem, and does the expected business outcome justify the investment?

Start with the outcome, not the requested feature

Start by asking what should materially improve for the business or user. That means separating the problem itself from the outcome the organisation wants and from the solution that may eventually deliver it.

Take reporting as an example. A customer might ask for a better dashboard, which could quickly become a roadmap item involving visualisations, filters, permissions, and analytics, while the actual need may simply be reliable access to underlying data every Friday. In that case, an API or CSV export could solve the problem more effectively than a new analytics environment.

It’s easy to create a full-time project that requires design, development, testing, support, and maintenance. Sometimes, the solution someone really needs can actually be a one-week job - like adding a small feature to the existing platform. This is why teams should treat a requested feature as a signal that there may be a problem, rather than proof that they already have the right solution. The first questions should focus on what is happening today, what business impact it creates, and what needs to change.

Symptoms vs underlying causes

Many times, I’ve seen the same pattern in technical decision-making. A platform is slow, so the immediate proposal is code optimisation, but the real constraint could be an overloaded database or a process that creates unnecessary load during peak traffic. Refactoring the most visible service may improve the code while leaving the customer experience unchanged. In that case, leaders should ask what actually limits performance and what could be done to remove that constraint.

In such situations, senior-level engineers not only answer whether something can be built, but also challenge whether the proposed solution addresses the real problem in the first place. Because that’s what can actually deliver the real business value.

Validate the problem before validating the solution

Customer conversations are important, but they can create false confidence if teams rely on hypothetical questions. Asking whether someone would use or pay for a feature often produces positive answers because there is no real cost to saying yes.

Past behaviour can be the more reliable answer. Instead of asking whether someone wants automated reporting, ask them to walk through the last time they prepared the report, where the process became difficult, what they did to work around the problem, and what that effort cost.

If a company is already spending time, money, or operational effort to solve a problem manually, that is usually a stronger signal than enthusiasm for a proposed feature. It shows that the issue is already having a real impact.

This is particularly important for complex technology investments, where a polished prototype can make a weak problem look more convincing than it is. Validation should assess whether the problem is worth solving before testing how impressive the proposed solution is.

Bring engineering into discovery early

In many organisations, the process looks like this: the business defines the requirement, the product specifies the feature, and the design team prepares the interface. By the time engineers are involved, some critical solutions may already have hardened into scope.

That is often when teams discover that the proposed solution depends on unreliable data, requires a difficult integration, creates a security concern, or could have been done much more simply. Involving experienced engineers earlier gives the organisation a chance to challenge those assumptions before implementation costs accumulate, reducing development time, maintenance burden, and future architectural complexity.

Test the assumptions that could change the investment decision

Once the problem is clear, the next step is to identify limitations and test them before committing to full development. For most software initiatives, this sits somewhere across value, user behaviour, technical feasibility, economics, security, compliance, or operational readiness. The right validation method depends on which of those questions could materially change the investment decision.

If demand is uncertain, test actual behaviour before building. If usability is uncertain, test a prototype. Technical feasibility may require a focused proof of concept, and uncertain economics may require modelling development, infrastructure, licensing, and maintenance costs.

It’s not about producing a demo just to show the stakeholders what the product may look like. It tests whether the business case and technical direction are strong enough to justify further investment.

AI makes this discipline more important

With Generative AI, it’s increasingly faster to produce a prototype. On the one hand, testing ideas can be more affordable; on the other hand, it introduces a new risk: confusing what can be built with what should be built.

Even if an AI prototype works, that does not prove that the solution is ready for production. The organisation still needs to lay the foundations. Successful implementation depends on readiness across data, architecture, governance, integration, and ownership, not only on the model's capabilities.

That means leaders should establish the workflow and business outcome before deciding which model or tool to use. AI may be the right solution, but AI availability should not become the reason the problem is chosen in the first place.

Treat technical choices as hypotheses too

Once the problem is clear, the next step is to validate the tech side of the project. I’ve seen teams favour trendy technologies over reliable ones simply because of its early promise or choose the one with the lowest initial cost without considering what it would cost to operate, maintain, and evolve over time.

What looks efficient today can create unnecessary costs or dependencies later. Initial delivery can be accelerated while making future migration difficult, or an architecture may work well for the first release but become increasingly expensive as usage grows. These examples point to the same underlying issue: teams commit to a technical direction before fully understanding its long-term consequences.

It is impossible to eliminate uncertainty entirely, but leaders can reduce the uncertainties that matter most. This way they can decide whether the organisation should invest, how much it should invest, or which direction it should take.

Change the questions leaders ask about the roadmap

Once development is underway, leaders need to know whether delivery is on schedule. But before that, they need to know:

• What’s exactly the problem we need to address?
• What’s the expected outcome?
• What are the risks and how can we mitigate them?
• What are the conditions that would justify changing direction?

One particularly important question is what would make the organisation choose a simpler solution or stop altogether. If every idea survives discovery and reaches development, the organisation is not really validating, but simply approving ideas with extra steps.

Sometimes the best option is to decide not to build. It saves engineering capacity, budget, and management attention, which can now be redirected towards something really worth building.

Better validation makes the right projects move faster

Validation can prevent teams from moving quickly in the wrong direction and creating software that consumes engineering capacity long after the original project is finished.

The strongest technology organisations know which uncertainty matters enough to test first, and they commit to work only when the evidence supports it.

So, before committing resources to the project, ask whether you are solving the right problem and whether what you have learned so far justifies the investment. If the answer is unclear, the next step should be to reduce that uncertainty, not increase the development budget. Once the problem and direction are clear, engineering has a much better reason to build.