Before You Write the Requirement, Understand the Problem
A day in product management shows how easily a request becomes a commitment — and why the distinction matters.
It is 9:05 a.m. The coffee is still hot when the first message arrives.
“Can we add a save-and-resume feature?”
By stand-up, engineering wants to know whether it belongs in the next sprint. The designer asks where the button should sit. The business stakeholder wants an estimate before the afternoon meeting.
Everyone is doing their job. The request is moving quickly.
I open the backlog and start typing: “As an applicant, I want to save my application…”
Then I stop.
We have discussed the feature, the design and the delivery date. We have barely discussed the problem.
A clear requirement can help a team build something correctly. A clear problem statement helps the team decide whether it is worth building.
By 10 a.m., the request already sounds like a requirement
“People are abandoning the application because the form takes too long,” the stakeholder explains.
That makes save-and-resume sound sensible. But there are two different claims here: people are leaving, and the length of the form is causing them to leave.
The first might be visible in our data. The second still needs investigation.
Perhaps applicants cannot find a required document. Perhaps an eligibility question is confusing. Perhaps they are leaving intentionally and returning later.
The stakeholder’s request is useful input. It gives us a starting point. It does not yet tell us which explanation is true.
When we turn that request straight into a requirement, we can quietly turn an assumption into scope.
A problem statement and a requirement do different jobs
A problem statement describes a difficulty experienced by a particular group, in a particular situation, and explains its consequence.
A requirement defines a need, capability, rule or constraint that must be satisfied.
Both matter. Without requirements, the team lacks a clear agreement about what to deliver. Without an understood problem, that agreement may be about the wrong thing.
A requirement also does not have to prescribe the interface. “Applicants must be able to retain their progress” leaves room for the team to explore how that should work.
At lunch, the problem becomes clearer
In this example, I sit with a support colleague and review the application journey. We then speak to applicants who paused before completing it.
They describe a familiar situation: they start the form, reach the document section and discover that they need something stored elsewhere. When they return, their entered information is gone.
The form may still be long. But we now have a more specific difficulty to address: leaving to gather documents creates repeated work.
Our problem statement becomes:
Applicants who pause to gather supporting documents lose their entered information. Restarting creates repeated work and can prevent them from completing the application.
That statement identifies the user, the situation and the consequence. It also avoids pretending we have measured how widespread the problem is. We should still establish that before making a large investment.
A clearer problem gives the team more options
By the afternoon, save-and-resume is still on the table. So are other possibilities.
Get Xavier Tan’s stories in your inbox
Join Medium for free to get updates from this writer.
We could explain the required documents before applicants begin. We could let them retain progress and return. Where policy allows, we could change when documents are requested.
These options address different parts of the experience. A checklist may prevent some interruptions. Retaining progress may help when an interruption is unavoidable.
Understanding the problem gives us a basis for comparing them: likely impact, effort, constraints and the uncertainty we still need to resolve.
We might use a quick prototype to check whether applicants understand how to return to a draft. We might test clearer document guidance first if it is cheap to change.
The investigation does not guarantee the right choice. It makes the choice easier to explain and challenge.
Turn the problem into a requirement — and keep the connection
Suppose the team chooses to support returning to an incomplete application. Here is how the reasoning carries through.
The acceptance check verifies the capability. The outcome measure checks whether it helps users.
User need: “I need to gather missing documents without losing the work I have already done.”
Requirement: “An authenticated applicant must be able to return to an incomplete application and recover previously saved information.”
Acceptance example: “After saving a draft and signing out, the applicant can sign in again and continue with the saved fields populated.”
This is the beginning of the requirement discussion. We still need to agree which information is retained, how long drafts remain available, who can access them and how saving failures are communicated.
Those details make the capability dependable. The problem statement keeps us clear about its purpose.
Shipping the feature answers only part of the question
A successful acceptance check tells us that saved information can be recovered. It does not tell us whether more applicants complete their applications.
For that, we need to observe what happens after release.
Do applicants who pause return and finish? Are they still contacting support because they have lost work? Does returning to a draft introduce new confusion?
We should establish a baseline, define the return window and account for other changes that might affect completion. Otherwise, we risk crediting the feature for a result we cannot explain.
The work continues beyond launch because the intended benefit exists in the user’s experience.
Before tomorrow’s request enters the backlog
I would ask five questions:
- Who experiences this problem, and when?
- What have we observed, and what are we assuming?
- What consequence makes it worth solving?
- What change would show that we have helped?
- Why is this capability the best next option?
The depth of investigation should match the uncertainty and the cost of getting it wrong. A small, well-understood fix may need a short conversation. A costly capability built on an uncertain explanation deserves more work.
In consulting, an agreed scope can also constrain our options. We still need to make assumptions visible and discuss changes through the agreed process. Understanding the problem gives that conversation substance.
By 5 p.m., the stakeholder asks again: “So, when can we deliver save-and-resume?”
This time, we can explain whose problem we are addressing, why we chose this capability and what we will watch after release.
Before the next request becomes a requirement, ask: “What have we observed that makes this worth building?”
