Reading Subjective Stakeholder Statements¶

Glossary¶

Subjective Transformation Effect A change that occurs between what someone experienced and how they describe it. Speakers naturally omit details, generalize from limited experiences, and add interpretations or assumptions.

Deletion Leaving out information needed to understand or evaluate a statement.

Generalization Treating an experience, observation, or rule as if it applied more broadly than the available evidence supports.

Distortion Presenting an interpretation, assumption, causal relationship, or predicted outcome as if it were an established fact.

Perspective-Based Reading Reading the same notes several times, with each pass concentrating on one particular kind of information.

Candidate Need A preliminary description of something a stakeholder may need. It still has to be clarified and validated before it becomes an agreed requirement.

Stakeholder statements are valuable, but they are not direct recordings of reality. People describe situations through their own experiences, goals, knowledge, frustrations, and assumptions. They also compress information so that conversation remains manageable.

For example:

“Nobody uses the reporting page because it is too complicated. We need a dashboard.”

This statement may contain useful information, but it also contains several uncertain claims:

Who does “nobody” refer to?
What tasks are considered complicated?
What observations connect complexity to low usage?
Is a dashboard the need, or merely one proposed solution?

The statement should not be rejected because it is subjective. It should also not be copied directly into the requirements. It is a starting point for investigation.

Objective does not mean unquestionably true

Rewriting an opinion in formal language does not make it objective. A need becomes better grounded when its context, source, evidence, limitations, and competing interpretations are made explicit and validated.

Subjective Transformation Effects¶

Three common transformations appear frequently in interviews, meeting notes, support requests, and informal discussions.

Deletion¶

Deletion occurs when part of the speaker’s experience is missing from the statement.

“The process takes too long.”

The sentence does not specify:

which process;
who performs it;
how long it currently takes;
under which conditions;
what duration would be acceptable;
what consequence the delay causes.

Deletion is not necessarily careless. The details may seem obvious to the speaker because they already know the context.

Useful clarification questions include:

Who exactly is involved?
What specifically happens?
When and where does it happen?
How is the task currently performed?
Compared with what is it slow, difficult, or expensive?
What information would another person need to observe the same problem?

Generalization¶

Generalization occurs when a limited observation is presented as a broad rule.

“Users always forget to complete the final step.”

Words such as all, everyone, nobody, always, never, cannot, and users often indicate a generalization. Generalizations may also appear without such obvious words.

Useful clarification questions include:

Which users have experienced this?
Does it happen every time?
Are there users or situations where it does not happen?
How frequently has it been observed?
Is this based on measurements, support cases, personal experience, or an assumption?
Under what conditions is the statement true?

A generalization may hide important differences between user groups, environments, tasks, or exceptional situations.

Distortion¶

Distortion occurs when meaning or causality is added to an observation without sufficient evidence.

“People abandon the form because the design looks old.”

The abandonment may be real, but the proposed cause is still an interpretation. Other possible causes could include unclear questions, missing information, technical errors, time pressure, or a form that is unnecessary for some users.

Predicted solutions can contain distortion as well:

“Adding AI assistance will make customers trust the service.”

The proposed relationship between AI assistance and trust must be investigated rather than accepted as fact.

Useful clarification questions include:

What evidence connects these two things?
Could there be another explanation?
How do we know what the user thinks or feels?
What observation would support or contradict this interpretation?
What result is actually needed, independently of the proposed solution?
What could happen if the proposed solution were introduced?

Info

One statement can contain deletion, generalization, and distortion at the same time. The categories help generate questions; identifying the “correct label” is not the main goal.

Perspective-Based Reading¶

A long interview note contains several kinds of information mixed together. Reading it once encourages the reader to notice only the most obvious point or the first possible solution.

Perspective-based reading separates the analysis into focused passes. During each pass, ignore the other perspectives as much as possible and mark information related to only one question.

Actors and Involved Parties¶

Look for people, groups, organizations, and external systems.

Ask:

Who performs an action?
Who receives its result?
Who is affected without directly using the system?
Who provides information or makes decisions?
Are broad labels such as “users” hiding several different roles?

Do not assume that the speaker represents every affected party.

Goals and Motivations¶

Look for what each actor is trying to achieve and why it matters.

Ask:

What outcome does the actor want?
What responsibility are they trying to fulfil?
What benefit are they seeking?
What consequence are they trying to prevent?
Do different actors have compatible goals?

A requested feature is not necessarily the underlying goal. “We need notifications” may express the goal of noticing pending work before a deadline.

Contexts and Conditions¶

Look for when, where, and under which circumstances a statement applies.

Ask:

In which situation does this happen?
Is it part of normal work or an exceptional case?
Does device, location, workload, experience, or timing matter?
Is the statement always true or conditional?
What must already be true before the situation occurs?

Context can turn an apparent universal requirement into a narrower and more useful need.

Issues and Pain Points¶

Look for obstacles, undesirable outcomes, delays, risks, errors, and unnecessary effort.

Ask:

What observable problem occurs?
Who experiences the consequence?
How does it interfere with a goal?
Is the speaker describing the problem itself, a suspected cause, or a proposed solution?
What would improve if the problem were resolved?

Avoid treating emotional language as noise. Frustration may indicate an important problem, but it does not by itself establish its cause or scale.

External Events and Triggers¶

Look for events to which people or the system may need to react.

Examples include:

a request being submitted;
a deadline approaching;
a payment failing;
new data arriving;
a user losing access;
an external service becoming unavailable.

Ask:

What starts the situation?
Who or what detects the event?
Is a response always required?
How quickly is a response needed?
What happens when the event is missed or repeated?

Events often reveal system boundaries and exceptional situations that are easy to overlook in a general discussion.

Mark What Is Known¶

During every reading pass, distinguish three kinds of information:

Explicit: directly stated in the source.
Inferred: a plausible interpretation that was not directly stated.
Unknown: information needed before the interpretation can be accepted.

This distinction prevents the analyst’s own assumptions from silently becoming part of the stakeholder’s statement.

Example

Source statement: “Customers keep calling because they cannot see what happened to their request.”

**Explicit:** Some customers call about the state of their requests.  
**Inferred:** Customers may lack sufficiently visible status information.  
**Unknown:** How many customers call, which requests are affected, what status information currently exists, and whether visibility is the main cause.

Worked Example¶

Consider the following interview note:

“The approval page is confusing, so everyone submits requests late. We need automatic reminders.”

Transformation Effects¶

Deletion

Which part of the approval page is confusing?
Which people submit or approve requests?
What counts as late?
In which situations does the problem occur?

Generalization

Does “everyone” mean every requester?
Are all request types affected?
Are there teams or situations where requests are submitted on time?

Distortion

The statement assumes that the page causes late submissions.
It also assumes that automatic reminders would resolve the problem.

Perspective-Based Reading¶

Perspective	Information found
Actors	Requesters and possibly approvers
Goals	Submit and process requests before the relevant deadline
Context	A request workflow involving an approval page and a deadline
Problems	Requests are sometimes submitted late; some users experience confusion
Events	A request is created, a deadline approaches, or a request remains pending

A preliminary candidate need could be:

Requesters and approvers need sufficient awareness of pending work and relevant deadlines to act before a request becomes late.

This is deliberately not yet a feature or requirement. It preserves the possible need without assuming that reminders are the correct solution.

Further investigation should establish:

how frequently late submissions occur;
which roles and request types are affected;
whether confusion, missing information, workload, or another factor causes the delay;
what information users currently receive;
whether reminders, clearer status information, workflow changes, or another intervention would help.

From Notes to Candidate Needs¶

Use the following procedure when analysing interview notes:

Preserve the original statement and its source.
Mark possible deletions, generalizations, and distortions.
Read the notes separately for actors, goals, contexts, problems, and events.
Distinguish explicit information from inference and unknown information.
Write a solution-neutral candidate need.
Turn missing or uncertain information into follow-up questions.
Validate the candidate need with relevant stakeholders and other available evidence.
Only then describe it using an appropriate feature, requirement, use case, or user-story format.

Danger

Do not convert a stakeholder quotation into a requirement merely by replacing “I want” with “the system shall.” Formal wording can hide uncertainty just as easily as informal wording.

Review Questions¶

Before accepting the result of the analysis, check:

Is the original source still traceable?
Are observations separated from interpretations?
Have broad claims been limited to the contexts supported by evidence?
Have assumed causal relationships been identified?
Have all relevant actors, goals, contexts, problems, and events been considered?
Have missing details become explicit questions rather than silent assumptions?
Is the candidate need independent of the stakeholder’s preferred solution?
Has the interpretation been validated by someone with relevant knowledge?

The purpose of this analysis is not to remove subjectivity completely. That is rarely possible. The purpose is to make perspectives, assumptions, and missing information visible so that the team can investigate them consciously.