Which Business Problem Should You Solve With Software First?

A business may have several credible software opportunities and enough resources to pursue only one. The first choice should reflect the value of solving the problem, the evidence available, and the practical ability to deliver a complete improvement. The most visible complaint is not always the strongest investment, especially when its cause lies outside the proposed system.

Compare recurring effort with commercial consequences

List candidate problems in operational terms. A hypothetical professional services firm might face repeated invoice preparation, inconsistent enquiry follow-up, and difficulty assigning consultants. Avoid beginning with product names such as a dashboard or an application; describe what goes wrong and who must compensate for it.

For each problem, record frequency, people involved, time spent, and consequences. Repeated invoice checks may consume predictable effort. An occasional missed enquiry may have a different commercial effect. Neither should automatically win: the owner needs to understand the kind of value involved and the reliability of the evidence.

Distinguish capacity from direct savings. If automation frees an employee's time, the benefit may be more work completed or faster customer responses. It becomes a cash saving only under particular staffing or purchasing conditions. State the intended benefit explicitly so the business can assess it later without moving the goalposts.

Consider the customer's experience

Ask whether the problem affects a customer's ability to buy, receive service, or obtain a dependable answer. An internal task can deserve priority when it creates repeated uncertainty for customers. Conversely, a prominent management report may have limited effect if the information does not change any decision.

The Government Digital Service's user-needs guidance recommends understanding what people are trying to accomplish and treating untested opinions as assumptions. For a commercial owner, this suggests interviewing customers and front-line staff before prioritizing a feature solely because senior managers request it.

In the hypothetical firm, inconsistent follow-up might reflect lack of responsibility rather than lack of reminders. Speak with the person receiving enquiries and examine recent examples. If nobody is assigned to respond, a new notification system may make the omission more visible without correcting it. Ownership must be resolved alongside software design.

Assess urgency without letting it obscure readiness

Some work has a real deadline: a branch opening, a changed partner requirement, or the end of an existing service arrangement. Record the deadline and consequence rather than assigning every candidate the same urgent label. Consider temporary measures when a complete system cannot reasonably be introduced in time.

Evaluate dependencies. A scheduling system may require agreed availability rules, reliable employee records, and cooperation from a partner. An invoice workflow may depend on rates that managers have not standardized. These prerequisites affect whether a promising project can deliver value now.

Prefer a first problem whose boundaries can be explained and whose decision-maker is available. This is a practical recommendation, not evidence that simple projects always provide greater returns. A more complex opportunity may deserve priority when its commercial importance outweighs the uncertainty and the business can fund the necessary investigation.

Select an outcome you can verify

Define a baseline and a desired operational change before ranking the final candidates. The firm might track time from enquiry arrival to an accountable response, or the effort needed to prepare an invoice from approved work. Choose a measure that follows the underlying goal rather than counting how many employees sign in.

The discovery guidance from the Government Digital Service includes considering the current cost of a problem and how success will be measured. This provides a useful discipline for prioritization without requiring a business to copy the government's delivery process.

Review the likely benefit against delivery effort, continuing operation, and disruption. Document the rationale in a short comparison that another manager can understand. A numerical score can help organize discussion, but it should not hide weak assumptions behind a precise-looking total. Explain uncertainty and identify what evidence could change the choice.

Use the first project to establish a foundation

Holism combines AI-assisted implementation, a Software Product Line foundation of reusable business capabilities, and a human developer. A focused first project can use that combination to address one operational need while preserving consistent rules for later additions. The owner defines commercial priorities; the developer directs how the solution is built and maintained.

For the services firm, improving enquiry ownership might be the first step, with scheduling added later when availability rules are settled. Reuse has value when subsequent capabilities fit the business, rather than when extra features are added simply because they are available. A retainer can support continued prioritization, subject to the engagement's agreed arrangements.

The strongest first problem combines meaningful business impact, credible evidence, manageable dependencies, and an observable result. Choosing it deliberately gives the company a way to judge software investment through operational improvement and a clearer basis for deciding what should follow.