Ex25 — Stakeholder Map and User Stories

Turn evidence about people and their work into a small testable product scope.

Start with your task

A stakeholder is someone affected by or able to affect the work. The user, buyer and payer may differ. Begin with a recent observed problem and describe the outcome that matters before specifying features.

For help supplying readable interview or workflow notes, see Give AI Text or a File to Work From. Remove private details the task does not need.

You need: Interview/observation notes or existing workflow evidence, product context, and known constraints. Hypotheses may start the work but do not become evidence.

Build

Copy this into your assistant, replace the bracketed inputs, and provide the relevant material. Approve the approach before acting.

New to using or adapting a prompt? Ask for What You Want shows how.

Copy this prompt

Help me map stakeholders and write a few useful user stories for [product/problem]. Evidence: [notes, source/date where available]. Known constraints: [facts]. First distinguish observations, interpretation and unknowns. Identify relevant users, buyers, payers, operators and decision makers only when evidence supports them; label proposed roles as hypotheses.

Ask the smallest clarifying question that could change scope, then propose the approach for my approval. Show goals, current behavior, influence and conflicting needs without inventing agreement. Draft only the few stories needed for a bounded useful outcome, in plain language or As a [role], I want [behavior], so that [outcome].

Tie each story to evidence or a named hypothesis. Add observable acceptance checks including a relevant failure/edge case, not just interface steps. Identify excluded scope and how to learn about the most consequential unknown. Let me choose the scope before producing a final set.

Before I approve the approach, challenge it briefly: are roles grounded in evidence, might user/buyer/payer differ, and will the proposed checks detect a failed outcome rather than merely a visible interface? Let me choose corrections before drafting the map and stories.

Check the result

Paste this review prompt into the same chat with the actual result and evidence. In a new chat, include your task, source material, result and observed checks. Choose the corrections before requesting a replacement artifact.

Use the evidence from your work with this review prompt.

Copy this prompt

Review this map and stories against the source notes: [map, stories, checks and notes]. Have user, buyer and payer been conflated? Are invented motives or consensus presented as evidence? Does each story describe a useful need rather than prescribe an unsupported feature? Can its acceptance checks distinguish a working result from a plausible screen?

Look for conflicting needs, excessive scope and missing failure cases. Recommend focused corrections or customer questions, let me decide, then recheck changed stories and checks. Do not rewrite, supply replacement code or artifacts, or apply changes yet. Explain the supported corrections and wait for my choice.

Distinguish demonstrated failures from inferred causes; do not invent test history.

Choose, revise, and use

Check one story with someone who knows the actual workflow, or identify that check as still needed. Walk through a real or clearly labeled sample case and its failure condition. Use the bounded set as input to Roadmap Builder; do not treat generated stories as customer approval.

Carry it forward

Take a different stakeholder’s recent problem. Preserve differences instead of folding everyone into one average user.

This is alpha material. Report unclear instructions or errors through a public issue or email help@bigleverinstitute.org. Share only redacted or fictional material.