Business Problem Framing and Discovery
Domain 1 - Business Problem Framing and Discovery
This domain tests whether you can decide what to build before touching a platform: how to frame a business problem, quantify it and scope a citizen-development solution the business and IT can both live with. Expect questions on process discovery, value hypotheses, requirements elicitation and build/no-build decisions.
Start with the process, not the tool
- Map the current-state process end to end: steps, owners, handoffs, wait time, rework loops and exception paths.
- Separate symptom from cause. Late invoices may be an approval bottleneck, not a data-entry problem; use 5 Whys or a fishbone before proposing an app.
- Quantify a baseline: volume, cycle time, error rate, cost per transaction. Without a baseline you cannot prove value later.
Scope and requirements
- Write a one-sentence problem statement and a measurable outcome, such as reducing exception handling from 30 to 10 minutes.
- Define in-scope, out-of-scope and definition of done; agree acceptance criteria with the process owner.
- Confirm data feasibility early: does the data exist, who owns it, is it clean, may you legally use it?
- Identify sponsor, process owner, end users, IT partner and any compliance stakeholder.
Worked example
Accounts payable rekeys 40 exception invoices weekly at 6 minutes each - about 16 hours a month - with an 8% keying error rate. The proposed app captures the invoice, validates vendor and purchase order, and routes exceptions. The team explicitly excludes ERP write-back and instead requests read-only vendor data from IT. Benefit is quantified as hours saved plus reduced rework, and the scope fits a two-week thin slice.
Traps that cost marks
- Solution-first thinking instead of problem framing.
- Unquantified benefits and no baseline.
- Ignoring exception paths, which are usually where the real work sits.
- Skipping data feasibility or stakeholder sign-off, then discovering the data is unusable.