How Discovery and the 5 Whys ensure you build what customers truly need—not just what they ask for.

Software engineers know computers do exactly as instructed—not necessarily what we intend. This gap grows when requirements come from non-technical stakeholders, or when a request addresses symptoms rather than underlying problems.

So how do you reduce the risk of implementing the wrong thing? Two simple practices help a lot:

• Discovery to understand the context and desired outcome
• The 5 Whys to uncover the root cause (so the problem doesn’t come back in another form)

At Notas IT, we use both early in the process, typically in the very first meeting after we receive a requirement.

Discovery: start with context, not code

Whenever a client sends a request like “build X” or “add Y”, we treat it as a starting point — not the final requirement.In the Discovery conversation, we aim to answer:

• Who experiences the problem (roles, teams, customers)?
• When does it happen (frequency, peak times, specific scenarios)?
• What is the impact (money, time, errors, churn, compliance risk)?
• Where does it show up (system boundaries, integrations, process steps)?
• What would success look like (measurable outcome, not feature shipped)?

Only after we understand those, do we use the 5 Whys to pressure-test whether we’re solving the real problem.

The 5 Whys: turn “a request” into “a cause.”

The 5 Whys is simple: take the problem statement and ask “why?” until you reach a cause you can act on.It’s not about interrogating the customer — it’s about building shared clarity. Often, you don’t need exactly five. Sometimes you need three. Sometimes you need seven. The point is: don’t stop at the first plausible explanation.And in software projects, there’s an extra detail: even when the symptom is visible in one place, the cause can sit in a totally different layer.

The “five layers” where problems hide (and why this fits Discovery + 5 Whys)

In most cases, the user notices the error or inconsistent behavior in the User Interface. But systems are more complex than that. A typical business system has multiple layers, and each layer can create symptoms that appear elsewhere. That’s why, when we investigate a problem and work towards a solution, we usually dig through five layers:

1. User interface code
2. Backend logic and frameworks
3. Database structure and datasets
4. User interface, backend, and database servers
5. Operating system (and environment runtime)

These layers naturally force you to ask “why?” multiple times. A UI complaint might actually be caused by backend validation, a database index, server resource limits, or an OS-level issue. The 5 Whys provides a structure to avoid stopping too early — and Discovery helps you choose the right path through those layers based on business impact, real workflows, and constraints. So in practice, Discovery gives you direction, and the 5 Whys gives you depth.

Example 1: “We need an Export to Excel button.”

Customer request: “Add an Export to Excel button on the orders page.”

Discovery questions:

• Who needs the export operations, finance, and sales?
• What do they do with the Excel file afterward?
• How often do they export, and how big is the dataset?
• What goes wrong today if they don’t export?

5 Whys: root cause and layer mapping

1. Why do you need an export?
2. “We need weekly order numbers for management.” (UI symptom / reporting need)
3. Why do you need to send them manually?
4. “There’s no reliable dashboard.” (UI / product capability)
5. Why is there no reliable dashboard?
6. “Order statuses are inconsistent and reporting breaks.” (backend + database)
7. Why are statuses inconsistent?
8. “Different teams use different statuses and sometimes skip steps.” (UI + backend)
9. Why do they skip steps?
10. “The workflow isn’t enforced, and the UI doesn’t guide them.” (UI + backend)

What we implement instead

Instead of only adding an export button, we might implement:

• A simple weekly KPI view (orders, cancellations, delays)
• A status model cleanup + validation (reduce “garbage in”)
• A guided workflow in the UI to ensure statuses are consistent.
• And if export is still needed: scheduled reporting instead of manual exporting

Result: less manual work, more reliable numbers, fewer “Excel truths”.

Example 2: “The system is slow — we need a faster server.”

Customer request: “The system is slow. Can we upgrade the server?”

Discovery questions:

• When is it slow (all day vs peak hours)?
• For which actions (search, save, login, reports)?
• How many users are active when it happens?
• What is “slow” in numbers (2s vs 20s)?

5 Whys: root cause and layer mapping

1. Why is it slow?
2. “Searching customers takes 10–15 seconds.” (UI symptom)
3. Why does searching take that long?
4. “The backend waits on the database query.” (backend)
5. Why is the query slow?
6. “It scans a huge table.” (database)
7. Why does it scan the whole table?
8. “There’s no index that matches the filters.” (database design)
9. Why wasn’t this caught earlier?
10. “No performance baseline + data growth wasn’t part of the review.” (process — and often server metrics)

What we implement instead

Rather than upgrading servers (a temporary fix), better solutions include:

• Proper indexes and query optimization (database)
• Pagination / constraints that match real usage (UI + backend)
• A performance baseline and alerting (servers/OS monitoring)

Result: faster UX and usually lower infrastructure cost.

Example 3: “We need an approval step before invoices are sent.”

Customer request: “Add an approval step before invoices are sent.”Discovery questions (context)

• What risk are you trying to reduce?
• Is the issue wrong invoices, wrong recipients, wrong amounts, or timing?
• How often does it happen, and what does it cost?

5 Whys (root cause) + layer mapping

1. Why do you need approval?
2. “Sometimes invoices go out with incorrect pricing.” (UI symptom)
3. Why is pricing incorrect?
4. “Discount rules aren’t applied consistently.” (backend logic)
5. Why aren’t rules applied consistently?
6. “Sales enters discounts manually in free-text fields.” (UI design)
7. Why is it manual/free-text?
8. “The system doesn’t support discount types properly.” (data model + backend)
9. Why doesn’t it support them?
10. “It grew organically without a pricing model.” (database + product design)

What we implement insteadInstead of adding an approval step for every invoice (friction), we might:

• Introduce a structured pricing/discount model (database)
• Add validation rules and clear UI controls (UI + backend)
• Add an exception workflow only for risky cases (UI + backend)

Result: fewer errors with less operational overhead.

A practical checklist you can use in your next customer meeting

When a customer brings a solution, try this sequence:

1. Restate the request in one sentence.
2. Ask: “What happens if we do nothing?” (impact)
3. Ask: “How do you solve it today?” (workarounds reveal real need)
4. Ask: “What does success look like?” (measurable outcome)
5. Run the 5 Whys, and consciously test which layer you’re in:
   • UI
   • backend
   • database
   • servers
   • OS/environment

Discovery gives you direction. The 5 Whys gives you depth. The five-layer mental model helps you not get stuck in the wrong layer.

Closing thought

Discovery and the 5 Whys don’t slow down delivery — they reduce rework. You still ship solutions, but you ship the ones that actually move the needle for the customer.