Chapter 1.2 · Business Problem Solving
A good analysis does not begin with a chart. It begins when someone asks a business question worth answering. The apparent problem may be simple—“sales are down”—yet the underlying decision can be surprisingly complex. Before opening a spreadsheet, an analyst must discover what decision the business needs to make, which evidence will be relevant and what successful work would look like.
Imagine that Meridian Retail's commercial director requests “a dashboard showing why online sales are falling.” The request already assumes that a dashboard is the right solution and that the cause is visible in existing data. A skilled analyst treats it as the starting point for a conversation, not as an approved project specification.
- Formulate clear problem statements
- Identify stakeholders and their needs
- Conduct effective discovery interviews
- Convert business concerns into SMART objectives and measurable success criteria
- Document scope, assumptions, constraints and requirements
1.2.1 From a symptom to a problem statement
A symptom is an observed condition, such as lower revenue or more customer complaints. A problem statement describes the condition, its context, the affected population and the business consequence without presuming an unverified cause. This distinction matters because jumping directly to a solution can result in expensive analysis of the wrong issue.
“Improve our sales dashboard” is a solution request. “Determine why online revenue decreased between August and September 2026, identify the business segments contributing most to the decline and recommend tests the commercial team can carry out” is an analytical problem statement. The second wording points toward evidence and an actionable decision.
1.2.2 Stakeholders and discovery interviews
A stakeholder is a person or group affected by the analysis, responsible for supplying information, or empowered to act on its findings. For a retail sales question, stakeholders might include the commercial director, e-commerce manager, finance analyst, store operations lead and data engineering team. Each sees the problem through a different lens.
The commercial director may want to understand revenue risk; finance may require reconciled revenue definitions; e-commerce may know about a recent checkout redesign; and engineering may explain gaps in tracking events. Successful discovery combines these perspectives instead of treating one opinion as conclusive.
| Stakeholder | Why involve them? | Discovery question |
|---|---|---|
| Commercial director | Owns the business decision | What decision will this analysis inform? |
| Finance | Validates revenue definitions | Are cancelled and refunded orders excluded? |
| E-commerce manager | Explains customer journey | Did traffic, pricing or checkout change? |
| Data engineering | Confirms source reliability | How are visitors and orders tracked? |
Useful interviews follow a disciplined sequence: ask for the decision and deadline; agree on definitions; identify available systems; probe important assumptions; and clarify who will approve the result. Questions should be neutral. “Did the new checkout cause the decline?” risks leading the respondent, whereas “What material changes occurred during the period?” invites a more reliable answer.
1.2.3 SMART objectives and success criteria
A business objective is not the same thing as a deliverable. “Create a spreadsheet” is an output. “Identify the channels explaining at least 90% of the observed revenue movement by the end of the week” is a measurable analytical objective. The familiar SMART framework checks whether an objective is specific, measurable, achievable, relevant and time-bound.
A suitable project objective could be: “By Friday, produce a finance-reconciled comparison of August and September net revenue by channel and product category, explain the three largest movements, and propose two testable actions for review by the commercial director.” It is specific enough to guide work and restrained enough not to promise causal certainty.
Success criteria define how the stakeholder will judge completion: totals reconcile to approved finance numbers; definitions are documented; missing records are disclosed; the report identifies material movements; and each proposed action has an owner and measurement plan.
1.2.4 Requirements, assumptions, scope and constraints
Business requirements describe what the solution must enable, such as comparing revenue by channel and period. Data requirements specify the fields and granularity needed, such as order date, channel, order ID, net revenue and status. A requirement should be verifiable; phrases such as “make the report insightful” are too subjective without an agreed definition.
Scope states what is included and excluded. An initial investigation might cover two months, two channels and completed orders only; inventory forecasting might be outside scope. An assumption is something treated as true provisionally, such as the availability of reliable web visitor counts. A constraint limits the work, such as a five-day deadline or unavailable customer identifiers.
1.2.5 Worked case: Meridian Retail requirements brief
Meridian's August revenue is ₹10,00,000; September revenue is ₹8,00,000. Online accounts for ₹1,60,000 of the total ₹2,00,000 decrease. These observations establish a useful focus, but cannot yet explain causation. A short requirements brief records the decision and the evidence that will be used.
| Element | Example |
|---|---|
| Decision | Where should the commercial team investigate first? |
| Period | 1 August–30 September 2026 |
| Population | Completed Meridian Retail orders; web traffic where available |
| Primary KPIs | Net revenue, order count, average order value, online conversion |
| Acceptance criteria | Reconciled totals, explicit caveats, two prioritized tests |
| Out of scope | Claims about checkout causality without supporting evidence |
Before analysis, the team should agree whether revenue is gross or net of discounts, how returns are treated and whether orders with missing channel labels are excluded or flagged. These details appear mundane, yet they determine whether business leaders can trust the findings.
1.2.6 From discovery to an analysis plan
The analyst now writes a small work plan: obtain relevant exports, reconcile revenue, perform channel and product comparisons, check order and traffic trends, validate anomalies with owners, and prepare a concise recommendation. Each step needs an output and a review point. The plan is deliberately iterative: a surprising finding may require additional stakeholder interviews or a revised definition.
A useful final check is to ask the sponsor: “If the analysis is accurate, what decision will you make differently?” If no decision can be named, revisit the objective rather than adding charts.
1.2.7 Chapter summary
Business problem solving means defining the decision before exploring data. Separate symptoms from causes, speak to stakeholders with different responsibilities, write SMART objectives, specify measurable success criteria and document requirements, scope, assumptions and constraints. An effective analyst does not promise to answer every question; the analyst promises to make a clearly framed decision better informed.