From Feature Request to Evidence-Based Problem Statement

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:

1. What is happening now?
2. Who experiences the difficulty?
3. What outcome is harmed?
4. What evidence shows the scale or seriousness of the issue?
5. 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.

---

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 $28\%$ to $15\%$ 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.

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	$336$ status-enquiry contacts in one month
System records	Error rates, workflow states, completion time	$22\%$ 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, $336$ of $1,200$ 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.

---

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.

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 $24$ hours during the measurement week
Baseline	$28\%$, measured in May
Target	$15\%$ 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.

---

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, $336$ of $1,200$ service requests that remained open for at least $24$ hours generated at least one contact classified as “status enquiry.”
• This represents a status-enquiry contact rate of $28\%$.
• 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, $28\%$ 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 $28\%$ to $15\%$ 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.

---

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:

1. The original request, quoted or paraphrased.
2. The primary and secondary affected users.
3. At least two pieces of evidence, with source and date or period.
4. A user need statement in the form “$user$ needs to $action$ in order to $goal$.”
5. An evidence-based problem statement using the template in this lesson.
6. One primary metric with baseline, target, and time frame.
7. 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.