v1 Published snapshot

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.

Back to playbook

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. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.