Ask about events before solutions
Ask users to replay a recent task and record inputs, decisions, handoffs and failures. Customer owners confirm value and scope; preserve disagreements, decisions, reasons and impact.
Learning module 02 / 06
Customer discovery and scoping
Turn ambiguous requests into event flows, data inventories, testable hypotheses and scope decisions.
Learning goal and artifact
A scoping pack: problem, data, permissions and an exit decision
Complete and self-check the connected workshop first, then attempt the extension with fictional or authorized material you select. Reading alone does not establish capability.
Concept summaries
Data availability is part of scope
Inventory sources, access paths, approvers, freshness and usage restrictions. A PoC validates hypotheses: keep it outside production, avoid premature promises and capture observable cases as evaluation seeds.
Complete small task · free study
Create a scoping pack with a defensible pause decision
Fictional client Qinghe Equipment: operators submit fault titles; dispatchers classify and confirm assignments. Lin approves scope, Chen approves data access, and Zhou owns operations. The pilot suggests categories to dispatchers without automatic assignment. Use synthetic tickets, with no client systems or external models.
Follow along: inputs, steps and reasoning
- Inputs: dispatchers want duplicate merging; Lin wants fewer wrong assignments; Chen prohibits sending raw tickets to external models; Zhou has no dedicated overnight ML support. Preserve these statements and check events, priorities, permissions and support separately.
- Ask for a replay: “Who noticed the last wrong assignment and how was it corrected?” Avoid “Do you want AI?”
- Inventory synthetic tickets, local rules, historical client tickets and duty logs. The first two are provided; access and approval for the latter two are unknown. Never assume permission.
- Exit: validate with synthetic data only; pause historical-data piloting until Chen approves. Success means explainable suggestions with human confirmation, without promising a reduction percentage.
Worked example
Source: historical tickets | access: read-only export pending Chen’s approval | freshness: unknown | restriction: no external model | decision: do not use yet. PoC: synthetic title → rule suggestion → human confirmation; no production, no raw client retention, no release-effect claim.
Try independently first
Independent task: a new request reads duty-group chat and automatically detects duplicates. Write one event question for each of three stakeholder groups, a four-row data table, one disagreement, PoC scope and proceed/pause gates. Save as 02-scope.md.
After answering, reveal reference and common errors
Pause chat access because it contains personal information and approval is unknown. Ask dispatchers how they identify duplicates; Lin decides priority and Chen approves data and processing location. Merging duplicates is a separate milestone from classification. Record unknown freshness as unknown, not real-time.
Extension exercise
Teaching exercise: a fictional retailer wants fewer replenishment stockouts. Define three interview groups and event-based questions, inventory access and permissions for at least four data sources, state PoC boundaries and decide whether to validate or pause. Mark unknowns rather than inventing customer facts.
Use fictional or authorized deidentified material. Keep reports, implementation and checks in your own project; this site accepts no exercise uploads and performs no online grading.
Review criteria
- Each source has an access path, approver, freshness and restrictions.
- Next-stage conditions are observable; permissions and commitments have named owners.
If criteria are unmet, record gaps and a correction plan, then review again with evidence. Confirm sharing permissions before instructor or peer review.
Complete lessons in this module
Study the full explanations, examples and exercises in these lessons, then integrate the artifacts using the connected workshop above.