Don't Start With the Software. Start With the Business Problem

AI can help us build software faster than ever. That makes it even more important to understand what actually needs to be solved before we start building.

Software projects often begin with a solution already embedded in the request:

"We need an AI agent."

"We need to replace this legacy application."

"We need to automate this process."

Or it can be the architect/developer with a hammer and for whom everything looks like a nail:

"You need a dashboard."

"You need a mobile app."

Those may eventually be the right answers.

But none of them describes the business problem.

That distinction matters because once a project is framed around a particular technology or application, the conversation naturally shifts toward features, architecture, platforms, timelines, and cost. The most important question can get skipped:

What are we actually trying to change for the business?

At FADLtech, we believe that question should come before the software.

A solution is not the same thing as a need

Suppose someone says, "We need an AI agent to handle customer support."

There is already a solution embedded in the statement: an AI agent.

But the underlying business need might be something quite different.

Perhaps support volume is increasing faster than the team can handle it. Perhaps customers wait too long for answers. Perhaps employees spend too much time answering the same questions. Perhaps support costs are increasing. Perhaps the real problem is that customers cannot find information that already exists.

Those are different problems.

And they may have different solutions.

An AI agent could be appropriate. So could better self-service documentation, improved search, workflow automation, integration between existing systems, changes to the support process, or some combination of them.

Starting with "build an AI agent" makes it much easier to spend time optimizing the wrong intervention.

Starting with the business problem keeps the options open long enough to understand what actually needs to improve.

AI makes this more important, not less

AI-assisted development has dramatically reduced the effort required to turn an idea into working software.

That is a major advantage. We use AI-assisted development extensively ourselves.

But faster implementation creates an interesting risk:

We can now build the wrong thing faster, too.

When creating software was slower and more expensive, organizations had a strong incentive to scrutinize projects before committing significant development resources.

Today, a working prototype can appear remarkably quickly. That can create the impression that the difficult part of the problem has been solved.

It may not have been.

A prototype can demonstrate that something can be built. It does not necessarily demonstrate that it should be built, that users will adopt it, that it addresses the root problem, or that the resulting business improvement will justify the effort of putting it into production and maintaining it.

The lower the cost of producing software becomes, the more valuable disciplined problem definition becomes.

Falling into the trap of solution bias (leading with the "initiative") risks:

• Solving the wrong problem, which wastes time and capital.
• Addressing the symptoms instead of the root cause, which could allow the issue to return.
• Creating unintended complexity, which adds software and training that people now have to manage.

What should be understood before discussing features?

The starting point is not a requirements document containing dozens of features.

It is a shared understanding of the current situation and the desired business outcome.

Before deciding what to build, we want to understand questions such as:

• What problem or opportunity triggered this conversation?
• Who experiences it?
• How often does it occur?
• What happens today?
• What is the business consequence of leaving it unchanged?
• What constraints, existing systems, data, regulations, and workflows affect the problem?
• What assumptions are we making?
• What outcome would make the project worthwhile?
• How would we know that outcome occurred?
• Does solving this problem actually require new software?

That last question can be uncomfortable for a software development company.

It is also an important one to ask.

If an existing product, a process change, a small integration, or a configuration change addresses the business need better than a custom application, discovering that before development starts is a good outcome.

The objective is not to manufacture a software project.

The objective is to solve the business problem.

Our process starts with a conversation

This is why FADLtech engagements do not begin with "send us the feature list."

They begin with a 30-minute conversation.

The purpose of that first discussion is not to design the entire system. It is to understand enough about the business need to determine what should be explored next.

What is happening today?

Why has it become a problem now?

Who is affected?

What has already been tried?

What would a better state look like?

What would make the investment worthwhile?

Sometimes that conversation confirms that the problem is well understood and that the likely technical direction is reasonable.

Other times it reveals that the requested application is actually one possible solution to a problem that needs more investigation.

That leads to discovery.

Discovery turns a request into an understood problem

Discovery is where we move from "here is what we think we want built" toward a clearer picture of the current state, desired state, and gap between them.

That can mean understanding business processes and user workflows. It can mean talking to stakeholders who experience the problem differently. It can mean examining existing applications, integrations, and data.

For a modernization project, it can mean determining which parts of an older system actually create business risk and which parts continue to work perfectly well.

For an AI project, it can mean separating the places where generative AI adds real value from work that is better handled through deterministic software or conventional automation.

The objective is not to produce documentation for its own sake.

It is to reduce uncertainty before uncertainty becomes code.

A useful discovery process should leave us better able to explain the problem without referring to the proposed technology.

That is an important test.

"We need to implement AI" describes technology.

"We need to reduce the amount of time employees spend manually categorizing incoming requests while maintaining the accuracy required by the business" describes a problem and an outcome.

Only the second statement gives us a meaningful basis for evaluating different solutions.

Assessment comes before commitment

Once the business need and current environment are understood, we can evaluate possible approaches.

Sometimes the answer will be a new custom application.

Sometimes it will be modernization of an existing system rather than replacement.

Sometimes the best path will be incremental: remove a bottleneck, automate one high-value workflow, expose an API, replace one unsupported component, or add AI to a specific step where it provides meaningful leverage.

And sometimes the assessment should conclude that the proposed project does not yet have enough expected value to justify building it.

That is useful information.

The goal of assessment is to make the technical recommendation traceable back to the business need.

If we recommend a capability, we should be able to answer:

What business problem does this solve?

If we cannot answer that clearly, it deserves another look.

Then we talk about the solution

Only after we understand the business problem does it make sense to make serious decisions about architecture, functionality, platforms, and implementation.

At that point, requirements have context.

Priorities can be evaluated against an outcome instead of against whoever requested a feature most recently.

Tradeoffs become easier to discuss because there is something concrete to optimize for.

And scope becomes more defensible because every major part of the solution can be connected to a business reason for its existence.

This does not mean requirements become fixed forever.

Discovery continues as people learn. Assumptions get tested. New information appears. Priorities change.

The objective is not to predict everything before development begins.

It is to make sure development begins in the right direction.

Building the right thing is only the first half

Understanding the business problem does not eliminate the need for engineering rigor.

It precedes it.

Once we have determined what is worth building, the next responsibility is to build it so it can actually be depended on: architecture, security, testing, reliability, observability, operational planning, maintainability, and the many failure conditions that do not appear during a demonstration.

We wrote about that side of the problem in Process Rigor in Developing Solutions.

Together, the two ideas form the approach we want on every project:

First, make sure we are solving the right problem.

Then, make sure we are solving it the right way.

AI can make the implementation dramatically faster.

Neither responsibility goes away.

Before you ask what to build, ask what needs to change

Technology conversations naturally gravitate toward solutions.

Which model should we use?

Should we build or buy?

Should this become microservices?

Should we replace the legacy system?

Should we add an agent?

Those can all be useful questions.

They just are not the first question.

The first question is simpler:

What business outcome are we trying to create, and what is preventing it today?

That is where we start at FADLtech.

A 30-minute conversation can sometimes prevent months of work on the wrong problem.

And when software really is the right answer, understanding why we are building it gives everything that follows — discovery, architecture, implementation, and measurement — a much stronger foundation.

Have a business problem that may need a software solution? Start with a 30-minute conversation with FADLtech.