How to Separate Facts, Requests, and Constraints in Stakeholder Notes

Stakeholder notes often look decisive before they are ready to guide work. A single page can mix verified observations, preferred solutions, fixed boundaries, and guesses. If every sentence is copied into a requirements list, the team may treat an opinion as evidence, a request as a commitment, or a flexible preference as a hard constraint.

A safer first step is classification. Separate what is known, what someone is asking for, and what the project must work within. Keep ambiguous statements in a question queue until the right person confirms them.

What counts as a fact, request, or constraint?

Use practical definitions that make the next action obvious:

• Fact: a statement supported by an observable source, such as analytics, a signed decision, a published policy, a test result, or a dated customer-research record.
• Request: something a stakeholder wants changed, created, removed, or prioritized. A request expresses preference or desired action; it is not automatically an approved requirement.
• Constraint: a verified boundary that limits available choices, such as a deadline, budget ceiling, required platform, accessibility standard, contract term, or dependency.
• Open question: a statement that cannot yet be classified without evidence or clarification.

The extra question lane matters. Forcing every sentence into one of the first three categories creates false certainty.

A four-column pass through the notes

Start with the exact wording from the permitted meeting notes. Do not improve the sentence yet. Add a source, an owner who can verify it, and the next check.

This example is fictional. Its purpose is to show the method, not to describe a real Recolx project or customer.

Step 1: preserve the original statement

Keep the speaker’s words beside any cleaned-up version. Paraphrasing too early can remove uncertainty, soften a warning, or turn “could” into “must.” Record the meeting, date, speaker or role, and the relevant time marker when permission allows.

The original statement is evidence of what was said. It is not proof that the statement itself is true.

Step 2: test facts against a source

A useful fact row answers three questions:

1. What exactly can be observed?
2. Where is the supporting record?
3. When was it last checked?

“People are confused” is too broad. “Eight of 22 support tickets tagged plan-selection in the last 30 days asked how the plans differ” is testable, but only after the ticket count and date range are verified. If the source is unavailable, label the statement unverified rather than filling the gap with confidence.

Step 3: translate requests into needs and outcomes

A request often arrives as a solution: add a banner, redesign a page, build a dashboard, send an email. Keep the request, then ask what problem it is meant to solve and how the team would recognize improvement.

The GOV.UK Service Manual recommends grounding user needs in evidence and focusing on the user’s problem rather than a proposed solution. Applied to stakeholder notes, that means separating “put the comparison on the homepage” from the underlying need: “help a visitor understand which option fits their situation before they leave the page.” The team can then compare several ways to meet that need.

Add four fields to each request:

• requester;
• affected user or workflow;
• desired outcome;
• decision status: proposed, approved, declined, or needs evidence.

This prevents a strongly worded suggestion from becoming an invisible commitment.

Step 4: verify whether a constraint is truly hard

Constraints define the space in which the team can act. Asana groups common project constraints around scope, cost, time, quality, risk, and resources. The categories are useful prompts, but the team still needs to verify each boundary in its own project.

Ask:

• Who owns this boundary?
• What source establishes it?
• Is it hard, negotiable, or assumed?
• What changes if the boundary moves?
• When should it be checked again?

For example, “launch by November 2” may be a hard commitment tied to a public event, or it may be a preferred internal target. The work plan changes depending on the answer.

Step 5: use an open-question queue

Some notes contain two categories at once. “We must keep the current CMS because migration is too expensive” combines a proposed constraint with an unverified cost claim. Split it into separate checks:

• Is use of the current CMS a confirmed decision?
• What migration option was estimated?
• What cost range and time horizon were used?
• Who can approve a different platform if evidence supports it?

Assign one owner and a due date to each question. When the answer arrives, promote the item into the fact, request, or constraint register without erasing the original wording.

A finished classification record

For the fictional website-planning example, a resolved record might look like this:

Quality checks before the record guides work

• Every fact has a source and freshness date.
• Every request names the requester, intended outcome, and approval state.
• Every constraint has an owner and is marked hard, negotiable, or assumed.
• Ambiguous statements stay in the question queue.
• Corrections preserve history instead of silently replacing earlier notes.
• No confidential or restricted material is copied into a shared register.

A reusable template

Copy this structure into a document or spreadsheet:

Original statement:
Meeting and time marker:
Tentative label: fact / request / constraint / question
Source or authority:
Owner:
Freshness date:
Decision status:
Next check:
Resolved wording:
Change history:

Classify six statements from one permitted meeting before translating any of them into a requirement. That small pause can prevent a week of work from being built on the wrong kind of sentence.

For related workflows, see how to build an open-question log and how to build an assumption log from meeting notes.

Sources

• GOV.UK Service Manual: Learning about users and their needs
• Asana: Project constraints