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.
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.
- 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
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
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
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.
Content digest
sha256:sha256:d535f39d84a2ca499ecb5df24e47bf8351679070707077233e70fcc1ff21ed68{"category":"operations","description":"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.","inputSchema":{"additionalProperties":false,"properties":{"availableEvidence":{"description":"Interview notes, process artifacts, product usage, metrics, data samples, or links available for discovery.","items":{"type":"string"},"type":"array"},"businessGoal":{"description":"Business outcome the customer wants, in their terms.","minLength":1,"type":"string"},"constraints":{"description":"Known scope, time, budget, security, or delivery constraints.","items":{"type":"string"},"type":"array"},"customer":{"description":"Customer, department, or engagement identifier.","minLength":1,"type":"string"}},"required":["customer","businessGoal"],"type":"object"},"schemaVersion":1,"steps":[{"expectedOutputs":[{"description":"Problem hypotheses, interview map, evidence gaps, and questions.","kind":"discovery-plan"}],"id":"YPY2","instructions":"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.","resourceHints":[],"title":"Frame the discovery questions and evidence standard"},{"expectedOutputs":[{"description":"Evidence-backed problem statements and stakeholder differences.","kind":"problem-inventory"}],"id":"4BWV","instructions":"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.","resourceHints":[{"kind":"skill","ref":"github:suboss87/FDEOps","selector":"skills/fde"}],"title":"Conduct and synthesize discovery"},{"expectedOutputs":[{"description":"Comparable use-case cards with actors, value hypotheses, dependencies and risks.","kind":"use-case-cards"}],"id":"3GDM","instructions":"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.","resourceHints":[],"title":"Generate and shape candidate use cases"},{"expectedOutputs":[{"description":"Ranked use cases, decision criteria, confidence and critical unknowns.","kind":"prioritization"}],"id":"T38Z","instructions":"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.","resourceHints":[],"title":"Prioritize with explicit trade-offs"},{"expectedOutputs":[{"description":"Prioritized use-case brief with measurable success criteria and explicit approval status.","kind":"scope-recommendation"}],"id":"RSGH","instructions":"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.","resourceHints":[],"title":"Secure agreement on a testable scope"}],"title":"Discover and Prioritize Customer Use Cases"}