Understand before building.

A business comes to you with an idea. “We need an app.” Another says: “We need a dashboard.” Someone else has already decided: “We need AI.” And occasionally, the requirement arrives with a complete list of screens, buttons and features.

It can be tempting to open Figma immediately. Or create a backlog. Or start setting up the repository. But there is a step that is easy to skip because it doesn’t look like much from the outside: understanding the problem.

It doesn’t produce a beautiful screen. It doesn’t generate a demo. It doesn’t give anyone something impressive to show in the first meeting. But it can determine whether everything that comes after it is useful.

The first deliverable shouldn’t be the prototype

There’s a common idea in the software development process that the faster you build something, the faster you learn. There’s truth in that. But speed without direction isn’t really speed. If the team has misunderstood the problem, a fast prototype simply helps everyone get to the wrong answer faster.

A prototype can show what an interface might look like. It can’t automatically tell you whether you’re solving the right problem. That’s why good projects usually begin with a different kind of deliverable: a shared understanding of what needs to be solved.

• What is happening today?
• Who is affected?
• Where does the process break?
• What are people doing manually?
• What information is missing?
• What decisions need to be made?
• What does success actually look like?

Until those questions are reasonably clear, designing the solution is premature.

Start with how the business actually works

A requirement document might say: “The system should allow managers to approve requests.” That’s technically a requirement. But it isn’t much of a picture.

• What kind of request?
• Who creates it?
• What information is required?
• Who approves it?
• Can it be rejected?
• What happens after rejection?
• Can someone edit it?
• What happens if the manager doesn’t respond?
• Does the customer need to know?
• Does another department need to act afterwards?
• What happens today?

Those questions matter because software doesn’t operate in isolation. It becomes part of a process that already exists. And sometimes the process itself is the problem.

Watch the work, don’t just document it

One of the most useful things a technology team can do is talk to the people who actually use the process. Not just management. Not just the person who requested the software. The people doing the work every day. They often know things that never appear in requirement documents.

• Which fields nobody uses.
• Which reports are manually prepared every Monday.
• Which step requires three phone calls.
• Which “temporary” Excel sheet has quietly become essential to the business.
• Which part of the existing system everyone hates.
• Where people have created shortcuts to make the process survivable.

Those details are incredibly valuable. Because they reveal the difference between how the business is supposed to work and how it actually works.

Requirements aren’t always the problem

Sometimes a project starts with perfectly reasonable requirements. The problem is that the requirements describe the solution rather than the underlying need.

We need a mobile application where customers can track their service requests.

That’s useful. But why? Perhaps customers are calling the support team repeatedly because they have no visibility into the status of their request. If that’s the real problem, there might be several possible solutions. A mobile app could be one. A web portal could be another. Automated notifications might solve part of it. Better internal status management might solve another part.

The original requirement may have been correct. But understanding the underlying problem gives the team more options. And more options usually lead to better decisions.

Ask “why” a few more times

This doesn’t need to become a complicated consulting exercise. Sometimes you simply need to keep asking one question. Why?

“We need an automated report.” Why? “Because the operations team spends three hours preparing it.” Why does it take three hours? “Data comes from four systems.” Why? “Those systems don’t share data.” Why do they need four systems? “Different departments use different tools.”

Now the problem looks very different. The original request was an automated report. The underlying problem might actually be fragmented data and manual reconciliation. That distinction matters. Otherwise, you could spend weeks building a beautiful reporting system that automates only one part of a much larger problem.

The people using the software matter

Software requirements often make sense when written down. Users don’t read requirements documents. They use software. And users bring context that isn’t always visible in a specification.

A warehouse worker might use the system while moving between locations. A sales representative might have thirty seconds to update a customer record. A finance employee might need a complete audit trail. A manager might only open the dashboard once a week. The same feature can therefore behave very differently depending on who is using it.

Understanding the user isn’t about creating elaborate personas for the sake of a presentation. It’s about understanding their reality. Where are they? What are they trying to accomplish? What information do they have? What constraints are they working under? What happens if they make a mistake? Those answers should influence the product.

Define what success means

“Build the application.” That’s a delivery goal. It isn’t a business outcome. A better conversation is: what should be different after this software exists?

• Order processing should take 10 minutes instead of 45.
• Customers should be able to resolve common requests without calling support.
• Managers should see operational performance without waiting for a weekly report.
• Sales teams should stop entering the same information in multiple systems.
• Field teams should be able to complete their workflow from a phone.

Now the development team has something to measure against. A feature can be technically complete and still fail to create the intended outcome. Success needs to be defined before development makes that distinction difficult to see.

Then decide what actually needs to be built

Once the problem is understood, something interesting happens. The original scope often changes. Sometimes it gets smaller. Sometimes it gets bigger. Sometimes an entirely different solution becomes obvious. That’s not a failure of product discovery. That’s the point of it.

If the first conversation says you need twenty features and the third conversation reveals that five of them solve the actual problem, you’ve saved time. If it reveals that the original five features aren’t enough to make the workflow useful, you’ve discovered that before spending months building them. Either way, understanding has done its job.

That is also the right moment to ask whether custom software development is even the answer — or whether the work should stay with what you already have. When custom software is worth building is the next question, not the first.

A good first version should answer a question

The first version of a product doesn’t need to prove that the entire future exists. It needs to prove something useful.

• Can users complete the core workflow?
• Does the new process actually save time?
• Will customers use it?
• Does the data become more reliable?
• Can the business operate with it?
• Does the new workflow work outside the development team’s laptop?

These are much better questions than: “How many features can we get into version one?” A smaller product that answers an important question is often more valuable than a larger product that answers none.

Technology decisions come later than people think

Once the problem and workflow are clear, technology becomes much easier to discuss. Should this be a web application? A mobile application? Both? Does it need real-time updates? Does it need integrations? What data needs to be stored? What needs to be automated? Where does AI genuinely help? What security requirements exist? What needs to scale?

These are important questions. But they become much easier when the team understands what the system is actually supposed to do. Otherwise, technical conversations can become detached from the business. You end up debating frameworks before agreeing on the problem.

Understanding isn’t a phase you finish and forget

There is another misconception worth clearing up. Discovery isn’t something you do once, produce a document and never revisit. Good software product development is iterative. You learn something from users. You build something. Users interact with it. You discover something you didn’t know. The product changes.

That doesn’t mean the project lacked planning. It means reality provided new information. The goal isn’t to predict everything before writing code. The goal is to make better decisions as you learn.

What a useful discovery process can look like

It doesn’t have to be complicated. For a new software project, a practical starting point could be:

01 — Understand the business

What does the company do? How does the relevant process work today? Where does money, time or information move?

02 — Understand the users

Who actually uses the system? What are they trying to accomplish? What constraints do they work with?

03 — Map the current workflow

What happens from beginning to end? Where are the handoffs? Where are the delays? Where are the manual steps?

04 — Identify the real problem

Which problems are worth solving? Which are symptoms? Which are simply preferences?

05 — Define the outcome

What should improve? How will you know?

06 — Shape the first version

What is the smallest useful system that can test the idea?

07 — Then design and build

Now the team has enough context to make technology decisions with purpose.

The best software teams ask uncomfortable questions

A good technology partner shouldn’t simply translate every request into code. Sometimes the most useful answer is: “Why do you need this?” Or: “What happens if we don’t build this?” Or: “Could your existing system already solve most of this?” Or even: “Do we need to build this at all?”

Those questions can be uncomfortable. They’re also useful. Because the objective isn’t to maximise the amount of software delivered. It’s to create something that genuinely improves the business.

Before you build, make sure you understand

If there’s one thing worth taking away from all of this, it’s simple: don’t confuse a requested feature with a defined problem. A feature is what someone asks for. A problem is what the business needs to solve. The difference between the two can be the difference between software that gets launched and software that actually gets used.

So before the first wireframe, before the first sprint and definitely before the first line of production code, spend some time understanding. Talk to the people doing the work. Map the process. Question the assumptions. Define success. Then build.

Because the first artefact of a good software project isn’t necessarily a prototype. It’s a shared picture of the problem.