Discover and Prioritize Customer Use Cases
Use when a consultant or FDE owns discovery across multiple conversations and must turn a customer's broad problem into a small, agreed set of valuable and feasible use cases. This ends at a justified scope recommendation, not a detailed technical solution or PoC implementation. Do not use when requirements and success criteria are already signed off.
Don't just read it. Run it.
Start the work here, keep the important context together, and hand it off to people or AI.
Starting inputs
- customer *
Customer, department, or engagement identifier.
string
- constraints
Known scope, time, budget, security, or delivery constraints.
array
- businessGoal *
Business outcome the customer wants, in their terms.
string
- availableEvidence
Interview notes, process artifacts, product usage, metrics, data samples, or links available for discovery.
array
Steps
- 1
Frame the discovery questions and evidence standard
Translate the stated business goal into observable symptoms, impacted actors, current workarounds, economic impact, and decision-making constraints. Review available customer material; classify each statement as observed, reported, estimated, or assumed. Build a stakeholder interview plan including process owner, frontline user, technical/data owner, and economic sponsor as relevant. Prepare questions about examples, frequency, exceptions, measured baseline and the consequences of inaction. Gate: the discovery plan can test whether the problem is real, consequential, and solvable within the stated context.
V2 practical protocol:
Discovery framing worksheet: capture customer job, process trigger, current workaround, affected volume or user segment, pain frequency, estimated cost/risk, sponsor objective, available system/data and disqualifying constraints. For each hypothesis, state what observation would falsify it and which specific stakeholder or artifact can provide that observation. Interview a user and an economic/process owner when possible; they may define value differently. Prioritize questions that can change the shortlist; do not spend days on attractive but immaterial background research. Minimum evidence fields: claim, speaker/source, observed vs reported vs assumed, date and confidence.kind: discovery-plandescription: Problem hypotheses, interview map, evidence gaps, and questions. - 2
Conduct and synthesize discovery
Analyze supplied interview notes and, when authorized, follow-up discussions. Extract recurring jobs, failure modes, user segments, process boundaries, current tools, data availability and constraints; preserve counterexamples and stakeholder disagreement. Use exact customer quotations only when supported by the source. Avoid turning a feature request into a solution commitment. Write a problem statement for each major cluster with affected users, baseline, impact, evidence strength, and outstanding uncertainty. Gate: priority problems have traceable evidence and at least one falsifiable assumption.
V2 practical protocol:
Synthesis protocol: code interview observations into pain/event, user role, frequency, severity, current workaround, business impact and exceptions. Keep exact quotes only when transcripts support them. Seek contradictory cases and segment differences, rather than treating all mentions as demand. For each candidate problem use evidence grades: Strong = observed in workflow or triangulated with data and multiple independent participants; Moderate = specific and credible direct account but not independently corroborated; Weak = opinion or speculative request. These are qualitative, not invented survey statistics. Summarize unanswered questions as targeted follow-ups; never claim user consensus from one sponsor.kind: problem-inventorydescription: Evidence-backed problem statements and stakeholder differences. - 3
Generate and shape candidate use cases
For each high-signal problem propose bounded use cases with trigger, actor, current workflow, proposed intervention, expected outcome, required inputs, human approvals, and exclusion criteria. Include non-AI or process-only alternatives so automation is not assumed. Identify data protection concerns, operational dependencies, failure/exception paths and owners of the proposed business process. Refuse to claim feasibility without technical review. Gate: each candidate is concrete enough for a buyer and an implementer to evaluate independently.
V2 practical protocol:
Use-case card template: [trigger], [actor], [job to be done], [current workflow and baseline], [proposed change], [human decision/approval], [output], [exception or error path], [data and permissions], [expected business improvement], [non-AI/process-only alternative], [test of feasibility]. Provide a one-line value hypothesis: "If [segment] can [new job], then [measurable outcome] should improve because [mechanism]." Explicitly exclude highly sensitive or technically unapproved deployments from the initial recommendation. Cards must be comparable in scope and not mix an entire transformation with a single automation.kind: use-case-cardsdescription: Comparable use-case cards with actors, value hypotheses, dependencies and risks. - 4
Prioritize with explicit trade-offs
Score or rank candidates across business impact, urgency, user frequency, evidence confidence, data readiness, implementation effort, change burden and risk. Use a qualitative scale where quantification is unsupported. Show assumptions that could reverse the ranking, particularly security permissions, integration complexity and customer sponsorship. Review the ranking with the appropriate customer decision maker; document disagreements without smoothing them away. Gate: recommended use cases are prioritized by a transparent rationale rather than enthusiasm or novelty.
V2 practical protocol:
Priority rubric: rate Business impact (measured/credible magnitude), Repeatability (frequency across affected workflows), Evidence strength, Data/technical readiness, Implementation effort and Risk or reversibility. Use High/Medium/Low with clear evidence per dimension rather than fabricating numeric precision. If quantitative data is present and comparable, normalize impact to the same horizon and target population. Flag hard blockers such as missing legal permission, unavailable critical data or no process owner; do not average these into a positive overall score. Show at least one candidate that was not prioritized and explain the trade-off. Include what one missing fact could reverse the top choice.description: Ranked use cases, decision criteria, confidence and critical unknowns.kind: prioritization - 5
Secure agreement on a testable scope
Convert the top one or two candidates into a scope proposal: target users, in-scope workflow, exclusions, measurable baseline and success signal, prerequisites, key risks, and open decisions. Prepare a succinct playback for the customer and record approval status, including whether approval is proposed, verbal or formally documented. Do not infer acceptance from silence. If critical evidence is missing, recommend a small discovery test rather than a fictional launch plan. Gate: the result is an agreed scope or a precise, decision-ready set of unresolved questions.
V2 practical protocol:
Scope agreement format: top use case, intended users, measurable outcome (metric formula, baseline, target or learning threshold), bounded process, necessary data/systems and permissions, non-goals, sponsor and implementing owner, principal dependencies, open hypotheses and initial test design. Record whether the customer explicitly accepted, requested change or has not yet decided. If success criteria remain unknown, recommend a discovery experiment with a bounded decision rule rather than inventing a target. Avoid duplicative generic handoff documents.kind: scope-recommendationdescription: Prioritized use-case brief with measurable success criteria and explicit approval status.