Most software projects that end up in a dead end don't start failing in the code. They fail in the first meeting, the one where a manager says "we need an app to manage orders", the developer nods, and both walk away believing they understood each other.
A few months later the software is delivered, and it works, but the problem it was meant to solve is still there. Not because anyone slacked off, but because nobody ever put the problem on paper.
This article is about one simple habit: before you commission or build software, write the problem down on a single page. Not a feature list, not screen mockups; the problem itself.
Short answer: Before commissioning or building software, write one page that states who has the problem, how the work is done today, what the problem costs, what measurable criteria define "done", and what is deliberately out of scope. That single page prevents the most common failure: software that works correctly but doesn't solve the real problem.
Why requirements written as features fail
Ask a manager what they want and you usually get a list of features:
- An admin panel
- Sales reports
- SMS integration
- A mobile app as well
The trouble with this list isn't that it's wrong; it's that it's a list of solutions, not a problem. Each item is someone's guess at how to relieve a pain that was never written down. When the pain isn't written down:
- You can't prioritize. If you don't know which decision the "sales report" is supposed to make easier, you don't know which columns matter and which are decoration.
- You can't tell when you're done. The report has been built, but is the problem solved? Nobody knows, because there's no criterion.
- Simpler solutions go unseen. Sometimes the pain behind "a mobile app" can be solved with a simple form or a change to a workflow, but once you've ordered an app, nobody dares say so.
- Scope keeps growing. A feature list has no boundary. Every meeting adds an item, and it's never clear which ones are essential.
A good developer asks these questions in the first meeting. But if the business owner has written down the answers beforehand, both sides save time and the cost and time estimates actually mean something.
A one-page problem statement template
The template below is deliberately short. If you can't fit the problem on one page, you've probably mixed several problems together and should separate them.
# Problem statement: [a short title]
## Who has this problem?
- The exact role or group (not "users"; e.g. "evening-shift warehouse staff")
- Roughly how many people, and how often per day/week they run into it
## What happens today?
- The current process, step by step, as it is actually done
- Where it gets stuck, where work is duplicated, where errors occur
## What does this problem cost?
- Time: how many hours a week go into it
- Money: lost sales, penalties, returns, extra staff costs
- Risk: what could go wrong if it isn't solved
- (If you don't have exact figures, give a rough range and cite the source)
## What does "done" mean?
- Measurable criteria, each with its current value and its target value
- Who measures, and when
## Out of scope
- Things we are deliberately not solving at this stage
## Constraints and assumptions
- Rough budget, deadline, systems it has to work withA few notes on filling it in:
Be specific about "who"
"Customers" or "employees" isn't an answer. A first-time buyer has a different problem from a customer who reorders every month. The more precise this section is, the simpler the solution becomes to design.
Describe "today" as it is, not as it should be
The best approach is to spend a day sitting next to someone who actually does the work. The process defined on paper and the process actually followed almost always differ, and the problem usually lives in that gap.
Estimate the cost, even roughly
The number doesn't have to be exact. "About ten hours a week, according to the warehouse supervisor's estimate" is far better than "it takes a lot of time". That number also sets a sensible ceiling on the budget later: if a problem costs little per year, an expensive solution isn't justified.
Success criteria must be measurable
The most important part of the template is "what does done mean?". A good criterion has three properties:
- It has a number: "faster" isn't a criterion; "under two hours" is.
- It has a baseline: you need to know today's value, or you can't measure the improvement.
- It's tied to a business outcome, not to the software: "launch an admin panel" is an output, not an outcome. "Reduce order dispatch errors to fewer than one a week" is an outcome.
A simple test: if the software gets built but this number doesn't change, would you consider the project a success? If the answer is no, you've chosen the right criterion.
An example: a store that keeps losing orders
To make the template concrete, let's fill it in for a hypothetical case. Imagine a home appliance store that sells in person and also takes orders through a messaging app. The manager says: "We need an order management system."
Hand that sentence to a development team and they'll probably propose a full system with a shopping cart, payment gateway, warehouse panel and reporting. But let's write the problem down first:
Who has the problem? The two salespeople who answer order messages, and the customers who order through the messaging app.
What happens today? An order comes in through the messaging app. The salesperson phones the warehouse to check stock, notes the price in a notebook and, once payment arrives, sends the order to packing on paper. When messages pile up, some orders get buried under newer ones and the customer follows up days later.
What does it cost? By the salespeople's own estimate, several orders a week ship late or are forgotten altogether. Some of those customers never come back. A lot of time also goes into answering follow-ups.
What does "done" mean?
- No paid order stays more than 24 hours without a clear status.
- "Where's my order?" follow-up messages drop by half compared with today (the salespeople start counting next week so there's a baseline).
Out of scope: direct online sales through the website, accounting integration and full inventory management.
With this page in hand, the conversation changes completely. The real problem is "orders getting lost", not "not having a system". The first solution might be a simple shared list with a few statuses (received, paid, shipped) that can be up and running in a few days. If after a month the numbers improve but not enough, you can decide about custom software based on real data.
Note that this example doesn't say custom software is bad. It says that once the problem is written down, you can match the size of the solution to the size of the problem.
Common mistakes
Writing a solution dressed up as a problem
"Our problem is that we don't have a mobile app" isn't a problem. Ask: what pain, exactly, does not having an app cause? The answer to that question is the problem.
Leaving "out of scope" empty
This section is often more important than the rest. Anything not written there will sooner or later show up in a meeting as "but that was obvious".
Writing it alone
A problem statement isn't something a manager writes alone at a desk. At the very least, review it with one person who deals with the problem every day. That conversation often reveals that the real problem is somewhere else.
Criteria nobody measures
If you define criteria but nobody is responsible for measuring them, after delivery you're back to gut feeling. Assign a person and a time to every criterion.
Turning one page into thirty
The goal isn't a full requirements document. The detailed spec gets written later, with the technical team. This page only needs to be clear enough that anyone who reads it understands why the project exists.
Before you send it to a contractor or your tech team
Before you send the problem statement to anyone, ask yourself:
- Would someone who doesn't know this business understand the problem from this page?
- Does any technology or feature appear in the "who" or "today" sections? If so, a solution has probably crept into the problem.
- Does every success criterion have a number, a baseline and someone responsible for measuring it?
- Have you listed at least three items under "out of scope"?
- Is the cost of the problem in line with the budget you have in mind?
Frequently asked questions
What is a problem statement in a software project?
A problem statement is a short document, usually one page, that describes the business pain before any solution: who is affected, what happens today, what it costs and what number will measure success. Unlike a feature list, its description of the problem mentions no technology or software features.
What is the difference between a problem statement and a requirements document?
A problem statement explains why the project exists and what pain it must relieve. A requirements document is written later, with the technical team, and specifies the details of the solution, meaning exactly what the software should do.
How do you define success criteria for a software project?
A good success criterion has a number, a known baseline and a link to a business outcome rather than a software output. Assign a person and a specific time to measure each one.
What should I prepare before commissioning software?
Prepare a one-page problem statement covering who has the problem, the current process, what it costs, what "done" means and what is out of scope. Add constraints such as a rough budget, the deadline and the systems the software has to work with.
How long does it take to write a problem statement?
Usually an hour or two, plus a review with someone who deals with the problem every day. If it doesn't fit on one page, you've probably mixed several problems together and should split them.
Wrap-up
Writing the problem down before the code isn't complicated and takes an hour or two at most. Yet that single page prevents the most common failure in software projects: building something that works correctly but doesn't solve the problem.
Write down who has the problem, what happens today, what it costs, what number defines "done" and what is deliberately left out. After that, choosing a solution, estimating cost, and even deciding not to build software at all all become easier.