Defining Business Problems
What this domain tests
This domain tests whether you can turn a vague business concern into a scoped, testable analytics problem with agreed success criteria, data requirements, and constraints before any modeling starts. The exam favors candidates who begin with the decision the analysis will inform, not with an algorithm.
Core rules
- Name the decision. State what action, policy, or investment the analysis should change and who owns it.
- Write a problem statement with five parts: population, outcome, time horizon, decision or intervention, and success metric.
- Separate three questions: the business question (“How do we reduce churn?”), the analytic question (“Which subscribers are likely to cancel in 90 days?”), and the data question (“Do we have 24 months of billing and usage history?”).
- Define the primary metric and guardrails. Tie the primary metric to value; add guardrails for cost, customer experience, fairness, or risk.
- Establish a baseline. Compare against current practice, a holdout, or a simple rule.
- Check feasibility early: data availability, quality, legal basis, ethics, latency, budget, and deployment constraints.
- Get stakeholder sign-off on scope, metric definitions, and what is out of scope.
Worked example
A subscription retailer says, “We need to reduce churn.” A weak translation is “build a churn model.” A stronger one is: decision = send a retention offer to at-risk subscribers; population = active monthly subscribers; outcome = cancellation within the next 90 days; analytic framing = binary classification; label = churned in the 90-day window; features must be available at scoring time; primary success = incremental retained revenue versus a holdout; guardrail = offer cost per saved customer; baseline = current rule-based campaign. This forces agreement on the label window, prevents post-cancellation data from leaking into features, and makes the deployment latency requirement explicit.
Traps that cost marks
- Accepting “improve customer experience” as a problem statement with no measurable outcome.
- Confusing the business goal with the model metric.
- Defining the label after inspecting the data, which invites leakage.
- Ignoring the decision threshold and cost of errors.
- Allowing scope creep without revising the metric or timeline.
- Skipping the baseline, so later results cannot be judged as useful.