Start with the right problem: a better starting point for your next software investment

When a business decides to invest in software, the conversation usually begins with a solution: an app, a portal, a platform, a migration. The solution feels concrete, so it is tempting to start there. The trouble is that a solution chosen too early quietly narrows every decision that follows. A better starting point is a short period of structured thinking about the problem itself. It costs little compared with building, and it changes what you build.

Describe the problem without describing the answer

Try writing the problem in a sentence that contains no technology. "Our field engineers lose time every day re-entering job details" is a problem. "We need a mobile app" is a solution that may or may not fit. When you can state the problem clearly, you can also see other ways of tackling it, some of which may be cheaper or faster.

Find out who has the problem and how often

A problem that affects many people daily is worth more attention than one that affects a few people occasionally. Talk to the people who live with the problem. Watch the work being done. You will usually learn that the process differs from the one described in the meeting, and that the exceptions matter as much as the standard case.

Challenge the assumptions

Every project rests on beliefs: customers will switch, staff will adopt the tool, the data is clean, the integration is simple. List them. Then identify the two or three that, if wrong, would sink the project, and find a cheap way to test them. A prototype, a spreadsheet model or a conversation with five customers can save months.

Decide what success looks like

Agree on measures before work begins. These might be time saved per task, a reduction in errors, a conversion rate, a response time or an adoption figure. Without a measure, projects drift toward being judged on opinion. With one, you can tell whether to continue, adjust or stop.

Shape a sensible first step

Rather than committing to the full vision, choose a first release that tests the riskiest assumption and delivers real value to a small group. It should be small enough to finish and good enough to learn from. This is the idea behind a minimum viable product, though it applies equally to internal tools and process changes.

Questions worth asking before you start

• What problem are we solving, and for whom?
• How do we know it is a real problem, and how big is it?
• What would we do if we did not build this?
• Which assumption, if wrong, would hurt most?
• What would tell us in three months that we are on the right track?

Good software begins with good questions. The time spent asking them is rarely wasted, and it often turns an expensive guess into a confident decision.