At some point, someone in your business said: 'We should build an app for that.' And so the idea took root: an app, a system, a portal – something digital that would fix things.
The trouble is, 'build an app' is not a business objective. It is a means to an end, and if you skip straight to the means, you skip the most important question: what operational problem are we actually solving? Projects that launch without a clear answer tend to drift. Features accumulate. Timelines slip. The end result may be technically impressive and practically useless.
This article is about doing the groundwork before a single screen is designed or a line of code is written – describing your problem so precisely that the right solution becomes obvious, and the wrong ones rule themselves out.
An app is not the objective. The objective is fewer errors, faster service, better visibility, or less repetitive administration. The app is just one way of getting there.
The difference between an app idea and an operational problem
An app idea sounds like this: 'We need a client portal.' Or: 'We should have a dashboard.' Or: 'There must be an app that handles this.'
An operational problem sounds like this: 'Our account managers spend two hours every Monday compiling status reports from three different spreadsheets, and clients still email to ask for updates we have already sent.' Or: 'Every time we take a new order, it gets re-entered into four systems by four different people, and it still gets wrong half the time.'
The first kind of statement opens a conversation about features. The second kind opens a conversation about outcomes – and that is where the real work begins. A client portal might solve the first problem. It might not. A better-structured shared document might do the job. A simple email automation might be enough. You cannot know until you have described the pain precisely enough to examine it.
One useful habit: whenever you catch yourself saying 'we need an app that does X', try replacing it with 'we have a problem where Y happens, and it costs us Z.' It feels clunky at first, but it forces specificity.
How to describe the pain in plain business language
The best problem briefs combine technical and business perspectives – but they should start with consequences, because that is where the real cost lives.
A useful description of a business problem includes three things:
- What is happening now. Not what should happen – what actually happens today, step by step, in the real world. Who touches what, when, and using which tools.
- What goes wrong, and how often. Errors, delays, missed steps, duplicated effort, complaints, workarounds. Frequency matters: something that breaks once a year is a nuisance; something that breaks every day is a crisis.
- What it costs. In time, in money, in staff goodwill, in customer satisfaction, in risk. 'It takes three hours a week' is a start. 'It takes three hours a week per person and we have eight people doing it' is much more useful.
You do not need a consultant to gather this information. You need a conversation – or ideally a short series of conversations – with the people closest to the pain. Front-line staff often know exactly what is wrong; they have simply learned to absorb it.
Why affected users and current cost matter more than favourite features
One of the most reliable ways to lose control of a software project is to begin it with a features wishlist. A feature that sounds brilliant in a meeting can be irrelevant to the actual problem – or actively counterproductive, adding complexity without adding value.
The antidote is to anchor every discussion to two things: the people who are affected, and the cost they are bearing.
Who actually experiences this problem day to day? What do they need to be able to do that they currently cannot, or cannot do reliably? What would success look like for them, specifically? These questions keep the project grounded in reality rather than imagination.
When the business problem is unclear, every feature appears useful and every decision becomes subjective. A clear problem statement gives the project its discipline.
Cost provides the other anchor. If the problem costs you £20,000 a year in staff time and errors, you have a reasonable ceiling for what a solution is worth. If it costs £2,000 a year, a custom-built app almost certainly is not the answer – and knowing that early saves everyone a great deal of wasted effort.
The success measure: what should be faster, clearer, or more reliable?
Once you know what the problem is and who it affects, define what 'fixed' looks like. Most people describe success in vague terms – 'it should be easier', 'things should work better'. Those are aspirations, not measures.
A useful success measure is specific and observable. For example:
- 'Order re-entry time drops from 45 minutes to under 5 minutes per order.'
- 'Client enquiries about order status fall by at least 70% within three months of launch.'
- 'Error rate on invoice generation, currently 12%, falls to under 2%.'
None of these say anything about features or technology. They describe outcomes. A good developer will use them as a target and make their own technical judgements about how to reach it. Your job is to define the target clearly enough that both of you can tell when it has been reached.
If you cannot write down a success measure, you do not yet understand the problem well enough to commission a solution. That is not a failure – it means you need another round of conversations before you go anywhere near a developer.
How a one-page problem brief prevents expensive wandering
Every well-run software project starts with a one-page document – a problem brief – that describes the problem, the affected people, the current cost, and the definition of done. Almost none of the troubled ones have it.
It does not need to be polished. It just needs to exist and be agreed on by everyone with a stake in the outcome. The discipline of writing it is as valuable as the document itself: you will discover that people you thought agreed on the problem do not, that costs are higher or lower than assumed, that the obvious success measure is actually contested. All of that is far better found on paper than six months into a build.
A clear brief also gives your developer something to push back on. If they can read it and say 'I think there is a simpler way to solve this at half the cost', you want them to say that. You can only have that conversation if the problem is clearly articulated.
Practical steps: getting your problem out of your head and onto paper
- Start with the sentence. Complete this prompt in writing: We are building this app because… Do not write about features. Write about the business situation that makes the project necessary. If you cannot complete the sentence in three lines or fewer, the problem is not yet clear enough.
- Walk the current process. Ask one of the people most affected by the problem to walk you through exactly what they do today, step by step. Write it down. Note where they pause, sigh, or reach for a workaround – those are the friction points.
- Put a number on it. Estimate the current cost in hours per week, errors per month, or complaints per quarter. An approximate number is far more useful than 'a lot'.
- Name the people, not the roles. 'The warehouse team' is vague. 'The three staff who process returns on the afternoon shift' is specific. Specific people can be consulted; vague categories cannot.
- Write two sentences on success. What does the situation look like in six months if the project has worked? What is measurably different? If possible, put a number on it.
- Share it and ask for disagreement. Send the brief to the key stakeholders and ask: 'Is this the problem we are actually solving?' You want the disagreement to surface now, not after the development contract is signed.
The business owner's job is not to specify a solution. It is to describe the problem so precisely that the right solution becomes obvious – and the wrong ones disqualify themselves.
Before you call a developer
None of this means you must have everything figured out before speaking to a developer. A good development partner will help you refine your thinking. But there is a real difference between arriving with a rough problem brief and arriving with a features list. One invites collaboration; the other invites a quote for the wrong thing.
Take an hour. Complete the sentence. Walk the process. Put a number on the cost. Name the people. Write two sentences on success. That hour of clarity is worth more than weeks of feature discussion – and it is the foundation on which every good project is built.
