Not every business problem needs software

01

Turn the proposed solution back into a problem

‘We need a dashboard’, ‘we should automate this’ and ‘there is an app opportunity here’ are proposed interventions. Restate each one as an observable problem: who encounters it, what they are trying to complete, what happens now, how often it occurs and what the failure costs in time, money, risk or experience.

Keep observed evidence separate from belief. Process records, support patterns, repeated manual work, interviews and direct observation can show that a problem exists. A feature request, competitor product or founder preference may be a useful lead, but it does not yet show which intervention will improve the outcome.

02

Map the current workflow before replacing it

Trace one real case from trigger to outcome, including handoffs, spreadsheets, inboxes, approvals, workarounds, exceptions and recovery. The map often reveals that the visible task is only one step in a larger service and that the expensive failure sits elsewhere.

Establish a baseline you can revisit: volume, time per case, waiting time, error or rework rate, support demand, operating cost, risk exposure and the quality of the user outcome. Use ranges when the data is incomplete and label assumptions rather than turning them into invented precision.

1. 01
   Fix the workflow

   Remove a step, clarify ownership or standardise the process before adding technology.

2. 02
   Run an assisted service

   Deliver the outcome manually long enough to learn where judgement and exceptions live.

3. 03
   Add targeted automation

   Automate one stable, repeated step while keeping human review where it matters.

4. 04
   Buy or build software

   Compare off-the-shelf and purpose-built options against the same needs and constraints.

5. 05
   Do not build yet

   Stop, observe or collect evidence when the problem, value or operating owner is not clear.

03

Compare interventions, including business as usual

Put at least three plausible routes beside the current state. A useful list might include a process change, an assisted service, a narrow automation, an off-the-shelf tool and a custom system. Judge each against the same critical outcomes, costs, dependencies, risks, accessibility needs, ownership and reversibility.

Treat ‘do nothing yet’ as a real comparator. Discovery has done its job when it supports a proportionate next decision—even when that decision is to stop, wait or solve the problem without new software.

04

Test the riskiest assumption with the smallest credible move

If the unknown is whether customers value the outcome, run an assisted pilot before automating delivery. If the unknown is integration or data quality, test that boundary. If a current tool may already be sufficient, configure and trial it before commissioning a replacement.

Define what the test should teach, the evidence you will collect, who owns the decision and the point at which you will continue, change direction or stop. A prototype is valuable when it reduces a named uncertainty, not because it looks like a smaller finished product.

05

Make a 90-day decision another person can inspect

Record the problem evidence, current workflow, options considered, decision criteria, recommended intervention, rejected routes, assumptions and an explicit 90-day action. Show what the action includes, what it does not include, what it will cost or consume, and what evidence will trigger the next decision.

A decision pack is not a guaranteed forecast or a substitute for legal, financial or regulated advice. Its value is an inspectable chain from evidence to recommendation, with enough diagrams, assumptions and handover material for the business to challenge the choice or commission the next phase without starting again.