Check the problem before the solution

“We need a customer portal” contains a proposed answer. The problem might be repeated status calls, missing documents or customers who do not know what happens next. A portal could help with all three, but each calls for a different intervention.

The first idea often becomes the project brief before anyone tests its explanation of the problem. From then on, intelligent people can make increasingly good decisions inside a mistaken premise. Better implementation does not repair that premise.

Ask what would still be wrong if the idea worked

Imagine the portal launches exactly as proposed. Customers can see every status. Yet they keep calling because “in progress” tells them nothing about when to arrange a delivery. The software has fulfilled the request while leaving the important uncertainty intact.

That thought experiment reveals something a feature checklist may miss: the user needed a decision they could act on. A clearer delivery estimate or an honest explanation of what is still unknown might serve them better than more visibility into internal labels.

A real recent example helps test the premise. Ask what the person was trying to decide, what information was missing and what they did instead. The answers can preserve the useful ambition of a project while changing its shape substantially.

Distinguish a cause from a symptom

An overdue queue is an observation. “Our software is too slow” is a possible explanation. Other explanations include unclear priorities, incomplete requests or a decision that only one busy person can make.

Write down more than one plausible explanation and what evidence would support each. For the queue example, compare time spent entering information with time waiting for approval. If approval accounts for most of the delay, replacing the entry screen may have little effect on the result.

The GOV.UK discovery guidance emphasizes understanding the problem and its constraints before committing to a build. That habit is useful at a much smaller scale too: a focused investigation can prevent a large project from starting on the wrong premise.

Run the smallest useful test

Choose a test that could genuinely change the decision. A manual status update for a small customer group might show whether better visibility reduces repeated calls. A revised intake checklist might reveal whether missing information causes the backlog.

State what you expect to observe and when you will review it. A demonstration that merely shows the proposed technology working does not necessarily test whether it solves the business problem. Look for a change in the work or experience that matters.

Make room for a different answer

The investigation may support the original idea, narrow it or make it unnecessary. That is useful progress. A portal might still be worthwhile, but only for document exchange. Status questions might be handled by a reliable notification from a system already in use.

Record what changed your understanding. This gives the eventual team a reason for the scope and helps prevent discarded assumptions from reappearing as requirements later.

Carry a clear brief forward

A useful brief names the people affected, the recurring situation, the consequence, the evidence and the desired improvement. It also identifies what remains uncertain. You can then compare approaches without treating the first suggestion as an obligation.

A technical second opinion can help challenge that brief or a proposed solution. The value may be a better build, a smaller build or a decision to solve the issue through a different change in the business.