Hello again. In the previous lesson, you selected Technical Business Analyst as the primary target role and Requirements Analyst as the adjacent role, based on recurring responsibilities in Bengaluru postings rather than title alone. Both roles begin with a discipline that employers value highly: not accepting a requested feature as the problem itself.
This lesson develops that discipline. You will learn to turn a stakeholder statement such as “We need a dashboard” or “Please add automated notifications” into a concise, evidence-based problem statement. It will identify who is affected, describe the operational impact, and define a measurable target without prematurely committing the team to one solution.
A feature request is a proposed answer, not yet a defined problem
Stakeholders usually describe a solution because it is concrete and urgent:
- “Add a WhatsApp status notification.”
- “Create a dashboard for pending requests.”
- “Add an approval field to the form.”
- “We need an API to synchronize customer data.”
Each request may be sensible. But each skips several questions that a Technical Business Analyst or Requirements Analyst must surface:
- What is happening now?
- Who experiences the difficulty?
- What outcome is harmed?
- What evidence shows the scale or seriousness of the issue?
- How will we know that a change has helped?
If these questions are not answered, a team can deliver exactly what was requested and still fail to improve the underlying situation. For example, a dashboard may make pending work visible, but if requests remain pending because ownership is unclear, the dashboard alone will not reduce delay.
The distinction is useful:
| Item | What it does | Example |
|---|---|---|
| Feature request | Proposes a solution | “Build automatic WhatsApp updates.” |
| User need | States what a specific user needs to accomplish | “Customers with an open service request need to check its current status without contacting support.” |
| Problem statement | Describes the harmful current condition, affected people, impact, and intended measurable improvement | “Status uncertainty generates avoidable support contacts and delays agents handling other issues.” |
| Requirement | Defines what the agreed solution must do | “The system shall send a status update when an appointment is confirmed, rescheduled, or completed.” |
A problem statement belongs before detailed requirements. It gives the team a reason to choose and prioritize requirements later.
{"type":"video","title":"User Need Statements in Design Thinking","learning_duration":97,"video_id":"kT0ZqwdPYRM","par_intro":"Watch “User Need Statements in Design Thinking” from NNgroup for a concise explanation of why teams should define the user problem before investing in a solution.","par_directions":"Watch from <span data-type=\"resource_video_timerange\" data-resource-subitem-id=\"7627d0a1\" data-range-start=\"0\" data-range-end=\"38\">the opening</span> to see why solving the wrong problem wastes delivery effort. Then continue through <span data-type=\"resource_video_timerange\" data-resource-subitem-id=\"f2e1c65f\" data-range-start=\"66\" data-range-end=\"125\">the core structure</span>. Focus on the three elements: a specific user, an action-oriented need, and the outcome that matters to that user. Notice the warning against defining needs through interface elements or technology.","isV2":true,"blockId":"53a43aeb-487b-445d-aaeb-5579959e4a02","lessonId":"1f19ef97-3f6e-4293-bcba-f4c87d6c9f3e"}
{
"type": "exercise",
"id": "89d93483-24e7-4913-a00c-d7b29c73b715"
}
Move from “what to build” to “what needs to improve”
A stakeholder’s preferred solution is valuable information, but treat it initially as a hypothesis:
“Automated WhatsApp messages might reduce status-enquiry contacts.”
That hypothesis can be tested, but it should not replace analysis. Start by separating the request into four layers.
| Layer | Question to ask | Example response |
|---|---|---|
| Requested solution | What has the stakeholder asked for? | Automated WhatsApp notifications |
| Observed condition | What is currently going wrong? | Customers contact support to ask for appointment and order status |
| User need | What must the user be able to do? | Check a reliable current status independently |
| Desired outcome | What needs to improve, by how much, and by when? | Reduce status-enquiry contacts from to or less within eight weeks of release |
The first layer is not discarded. It becomes one potential solution option after the underlying problem is understood. The other layers prevent a discussion from becoming “How quickly can we build the requested feature?”
The International Institute of Business Analysis makes the same point directly: accepting a solution request and immediately writing requirements can leave the root problem unresolved.
{"type":"reading","par_intro":"Read the “Deadly Sin #1: Lack of a Clear Problem” section from IIBA. It provides a practical structure for turning a solution-led request into a shared problem definition.","par_directions":"In “Deadly Sin #1: Lack of a Clear Problem,” begin with the paragraph explaining the risk of accepting a solution request without understanding the problem. Then read the structured-problem-statement guidance and its explanation. Pay particular attention to <span data-type=\"resource_reading_textrange\" data-resource-subitem-id=\"7e7a192d\" data-range-start=\"Describe what you think the problem is, list the stakeholders affected by the problem, and explain how the problem impacts them.\" data-range-end=\"End with what a successful solution would do.\">the four components</span>: problem, affected stakeholders, impact, and the definition of success.","learning_duration":"5 minutes","url":"https://www.iiba.org/business-analysis-blogs/the-7-deadly-sins-of-business-analysis-and-what-to-do-instead","title":"The 7 Deadly Sins of Business Analysis (and How to Avoid Them) | IIBA","isV2":true,"blockId":"7eabade4-bcf6-49ba-80e0-bb11a363902f","lessonId":"1f19ef97-3f6e-4293-bcba-f4c87d6c9f3e"}
A compact BA-oriented template is:
The problem of [undesirable current condition] affects [specific users or stakeholder groups], causing [business, user, operational, or compliance impact]. A successful change would [desired outcome], measured by [metric, baseline, target, and time frame].
For user-centred discovery, pair it with a need statement:
[Specific user] needs to [action, not feature] in order to [goal or outcome].
The two statements are related but serve different purposes:
- The need statement keeps attention on the user and their goal.
- The problem statement gives the delivery team operational context and a measurable definition of success.
Evidence makes the statement defensible
“Users are unhappy” is not a problem statement supported by evidence. It is a claim that must be investigated.
Evidence does not need to be perfect before discovery begins. It does need to be traceable: a reader should be able to see what was observed, where it came from, and what still requires validation.
Useful evidence commonly includes:
| Evidence type | What it can show | Example |
|---|---|---|
| Operational data | Frequency, volume, delays, rework, cost | status-enquiry contacts in one month |
| System records | Error rates, workflow states, completion time | of requests were pending beyond the expected window |
| Support tickets or call reasons | Recurring user difficulty | “Where is my technician?” is the largest contact category |
| User interviews or observation | Context, workarounds, motivations | Customers repeatedly refresh the portal because its status is not updated |
| Stakeholder input | Business priorities, constraints, consequences | Operations managers report that agents spend time answering routine status queries |
| Policy or compliance documents | Mandatory rules and risk | Customers must receive a confirmation before an appointment is changed |
Evidence should not be stretched beyond what it supports. For example:
- If contacts increased after a portal release, you can say there is an increase.
- You cannot say the release caused the increase unless the evidence rules out plausible alternatives.
- If three agents report confusion about ownership, it is a useful discovery signal, but it does not prove that every team has the same issue.
A reliable analysis note distinguishes facts, interpretations, and open questions.
| Category | Example |
|---|---|
| Evidence / fact | During May, of open service requests generated at least one status-enquiry contact. |
| Interpretation | Status visibility may be insufficient for customers with open requests. |
| Assumption to validate | Most of these customers would use self-service status updates if they were timely and reliable. |
| Question | Are contacts concentrated around appointment changes, technician delays, or initial confirmation? |
This distinction will make later requirements, risk analysis, and stakeholder discussions more credible. It is particularly important when multiple teams are involved: a business sponsor may see customer contacts, support sees workload, and an engineering team sees integration or data-quality constraints. All are relevant, but none alone tells the whole story.
{"type":"reading","par_intro":"Read this NNgroup article to see how research is condensed into a user need statement, how success measures are derived, and why solution-oriented wording limits discovery.","par_directions":"Start in the “Benefits” section with the discussion of aligning a team and establishing measurement. Focus on the instruction to turn the intended goal into a testable success measure. In the “Process” section, read from <span data-type=\"resource_reading_textrange\" data-resource-subitem-id=\"4be6bcfb\" data-range-start=\"Gather the research you will be using to fuel your understanding of the users and their needs.\" data-range-end=\"can drive deep insights about your users.\">gathering research</span> through the steps for generating, critiquing, and measuring a statement. Then read “User Need Statements vs. Development Tasks, Stories, and Epics,” especially <span data-type=\"resource_reading_textrange\" data-resource-subitem-id=\"6cce83c0\" data-range-start=\"The need statement gives us a specific user, something that the user needs to do, and a clear, empathetic insight into why Alieda has that need.\" data-range-end=\"and is not based on research.\">the comparison</span> between a genuine need statement and a solution-led development statement.","learning_duration":"10 minutes","url":"https://www.nngroup.com/articles/user-need-statements","title":"User Need Statements: The 'Define' Stage in Design Thinking","isV2":true,"blockId":"2b84265c-3b6f-4d2d-abf8-35b0a72eca82","lessonId":"1f19ef97-3f6e-4293-bcba-f4c87d6c9f3e"}
Make the success target specific and measurable
A measurable target turns a good intention into an outcome that can be evaluated. It also makes trade-offs visible. A sponsor may say “reduce support workload,” while support leadership may care about response time and customers may care about confidence and predictability. The analyst’s task is to specify what will be measured and whose outcome is being protected.
{"type":"image","url":"https://images.ctfassets.net/pdf29us7flmy/2TR1JdsNFYzuePZTGQFxPo/300dd5dd05e320ff971071c3dbd39a25/smart-goals.png?fm=jpg&q=100&w=720","caption":"The SMART framework shows five checks for a target: it must be Specific, Measurable, Achievable, Relevant, and Time-based. In problem framing, these checks prevent vague definitions of success such as “improve user experience.”","isV2":true,"blockId":"76faa117-260a-40c4-8db0-85377ee97abd","lessonId":"1f19ef97-3f6e-4293-bcba-f4c87d6c9f3e"}
Use SMART as a quality check rather than as a form-filling exercise:
- Specific: What exact condition will improve, for which users, and in what context?
- Measurable: What metric, data source, unit, and reporting period will be used?
- Achievable: Is the target feasible given the baseline, constraints, capacity, and likely solution options?
- Relevant: Does it connect to a real business or user outcome?
- Time-based: When will performance be assessed?
For an operational target, specify at least these elements:
| Element | Example |
|---|---|
| Metric name | Status-enquiry contact rate |
| Definition | Percentage of open service requests that generate at least one status-enquiry contact within seven days |
| Numerator | Open service requests with one or more status-enquiry contacts |
| Denominator | All service requests remaining open for at least hours during the measurement week |
| Baseline | , measured in May |
| Target | or lower |
| Time frame | Within eight weeks after release |
| Data source | CRM contact-reason data and service-request records |
| Owner | Customer-support operations manager |
| Guardrail | Missed-appointment rate must not increase from its baseline |
The guardrail matters. A team could reduce contacts simply by making support harder to reach, which is not a genuine improvement. A guardrail prevents success in one metric from hiding damage elsewhere.
Do not invent a target merely to make a statement look complete. If the business has not agreed a threshold, write a provisional target clearly:
Target to be agreed after baseline analysis and stakeholder review.
That is more professional than presenting an unsupported number as a commitment.
{
"type": "exercise",
"id": "c9a0bae1-8267-47be-a269-231512afcf28"
}
Worked example: reframing an automated-notification request
Assume the following discovery notes from a fictional home-services company. The request is deliberately cross-industry, so the analytical approach remains useful beyond automotive requirements work.
Request received
“Please add WhatsApp notifications for every service-request update. Customers keep calling for status.”
Discovery evidence collected
- In May, of service requests that remained open for at least hours generated at least one contact classified as “status enquiry.”
- This represents a status-enquiry contact rate of .
- Contact-centre agents report spending significant time confirming appointment dates and technician assignment status.
- In five customer interviews, customers said they were uncertain whether an appointment request had been accepted or rescheduled.
- The self-service portal shows a generic “in progress” status, but it does not show appointment confirmation or the reason for a delay.
- The product sponsor proposes WhatsApp because most customers use mobile phones. This is a solution preference, not yet validated as the only or best channel.
Weak version
We need WhatsApp notifications so customers do not call support.
This statement is weak because it:
- assumes WhatsApp is the solution;
- does not define the affected users precisely;
- gives no baseline or scope;
- does not explain what information is missing;
- provides no measurable definition of success.
User need statement
Customers with open home-service requests need to obtain reliable confirmation of their appointment and current request status without contacting support, in order to plan their time with confidence.
Notice the verbs: obtain, plan, and contact. The statement does not prescribe WhatsApp messages, a mobile-app screen, an SMS, or a portal redesign.
Evidence-based problem statement
The problem of customers being unable to confirm the current appointment and progress of an open home-service request affects customers awaiting service and contact-centre agents handling routine enquiries. During May, of eligible open requests generated at least one status-enquiry contact, contributing to avoidable agent workload and customer uncertainty. A successful change would provide customers with timely, reliable request-status information and reduce the status-enquiry contact rate from to or lower within eight weeks of release, without increasing the missed-appointment rate.
This is not yet a requirement. It leaves solution options open, such as:
- event-driven WhatsApp or SMS notifications;
- clearer portal status and appointment details;
- an authenticated status-check link;
- proactive notification only for delay or reschedule events;
- operational changes that improve data timeliness before customer-facing changes are made.
That flexibility is the point. A requirements discussion can now assess options against the defined outcome rather than treating the original request as automatically correct.
A repeatable reframing method
When a feature request arrives, use the following sequence in your notes or Confluence page.
1. Record the request exactly
Write the stakeholder’s words first. Do not “improve” them immediately.
Requested change: “Add a dashboard showing blocked approvals.”
This preserves traceability and prevents stakeholders from feeling that their request was ignored.
2. Ask what prompted the request
Look for a trigger, not just a desired feature:
- What happened that makes this urgent now?
- Who first raised the concern?
- What decision, task, or outcome is currently difficult?
- How often does it happen?
- What workaround do people use today?
- What is the consequence of doing nothing?
3. Identify affected users by role and context
Avoid broad labels such as “the user” or “the business.” Name a role and the moment in which the issue occurs.
Compare:
- Too broad: “Managers need better approval visibility.”
- Better: “Regional operations managers reviewing supplier exceptions during the weekly fulfilment review need to identify approvals blocked for more than two business days.”
Also include secondary users when the change affects their workload, decisions, or compliance responsibilities. A customer-facing issue may affect customers, support agents, operations managers, and engineering teams in different ways.
4. Capture the evidence and establish the baseline
Attach source references where possible: report name, date range, ticket category, interview date, or system query. A baseline is not simply “the current situation.” It is a quantified, time-bounded starting point.
5. State the impact in outcome terms
Impacts may include:
- customer effort or loss of confidence;
- operational delay, rework, or manual effort;
- revenue leakage or avoidable cost;
- poor decision-making because data is incomplete;
- compliance, safety, or security exposure;
- delivery risk caused by unclear ownership or dependencies.
Describe the impact that evidence supports. Do not assume every inconvenience is a revenue problem.
6. Define one primary success metric and any necessary guardrail
Pick the metric closest to the actual problem. If the issue is delayed approvals, the primary metric may be approval cycle time, not “number of dashboard views.”
7. Write, challenge, and validate the statement
Before treating the statement as agreed, review it with the people who supplied the evidence and with the accountable sponsor. Validation is not a formality; it is a chance to correct incorrect assumptions about users, causes, or success.
A practical working template is:
Request received: [feature or solution requested]
Evidence: [sources, baseline, period, observations]
Affected users: [primary role and context]; [secondary roles]
Problem statement: The problem of [condition] affects [users] during [context], causing [supported impact]. A successful change would [outcome], measured by [metric] from [baseline] to [target] by [date or release window], while maintaining [guardrail].
Still to validate: [assumptions, causation hypotheses, target feasibility, data gaps]
Quality checks before you move to requirements
A strong problem statement should pass these checks:
| Check | What “good” looks like |
|---|---|
| Solution-neutral | It does not require a named screen, channel, database, or technology. |
| User-specific | It identifies affected roles and their context, not a generic “user.” |
| Evidence-linked | Important claims can be traced to data, records, observation, or stakeholder research. |
| Impact-focused | It explains why the condition matters. |
| Measurable | It defines a meaningful metric, baseline, target, and time frame. |
| Bounded | It makes clear which journey, workflow, or period is under discussion. |
| Honest about uncertainty | Assumptions and unverified root-cause claims are labelled rather than disguised as facts. |
| Useful for decisions | It helps a team compare options and later determine whether the release succeeded. |
A final caution: do not confuse a target with a solution output.
- Output target: “Deliver a dashboard by 30 June.”
- Outcome target: “Reduce the average time to identify blocked approvals from two days to four hours by 30 June.”
The output may be necessary, but the outcome explains why it is worth delivering.
{
"type": "exercise",
"id": "206882e3-ef60-413c-9c7e-72ee8204bbe7"
}
Your working artifact
Create a one-page Feature Request Reframing Brief using a sanitized example from automotive requirements work, freelance work, or the fictional service-request scenario. Choose a request that originally named a solution: a status report, dashboard, integration, notification, field, workflow, or automation.
Include:
- The original request, quoted or paraphrased.
- The primary and secondary affected users.
- At least two pieces of evidence, with source and date or period.
- A user need statement in the form “ needs to in order to .”
- An evidence-based problem statement using the template in this lesson.
- One primary metric with baseline, target, and time frame.
- At least one assumption or open question that must be validated before solution selection.
Keep confidential details anonymous: replace client names, vehicle-program names, production volumes, and internal tool names with neutral labels. The analytical reasoning is what will later become portfolio evidence.
Key takeaways
A feature request is a proposed answer; it is not automatically the problem worth solving. Reframe it by identifying the current harmful condition, the specific people affected, the evidence for its impact, and a measurable definition of success.
Use a user need statement to retain the user’s goal and an evidence-based problem statement to align stakeholders around the condition to improve. A strong target specifies a metric, baseline, target level, time frame, and—where needed—a guardrail against unintended harm.
Next, you will build on this problem framing by creating a stakeholder-specific elicitation plan: deciding whom to involve, what each participant knows or controls, and which discovery technique best fits them.
Can't find a good explanation? Sign up and we'll make it for you