Recommended resources
The freely available resources this lesson will direct you to.
Hello! This course starts where effective analytics work starts: with a decision someone needs to make. Later modules will develop your SQL, Python, Power BI, statistical, and modeling work; this first module establishes how to aim that work at a useful outcome. Today you’ll learn to turn a request such as “Give me insights on delivery performance” into three connected statements: the decision, the analytical question, and the deliverable.
Find the decision behind the request
A stakeholder usually describes the thing they want to receive: a dashboard, a report, or a model. That is not necessarily the thing they need. “Build a delivery dashboard” might mean “We must decide whether to add a packing shift or address problems with a carrier.” A dashboard that charts everything except the evidence relevant to that choice could be technically correct and practically useless.
CRISP-DM calls this early work business understanding. Its useful distinction is between an objective expressed in business terms and an analytical goal expressed in terms of what the work will produce. The distinction applies whether you eventually write a SQL query, create a Power BI report, or build a predictive model.
Read the CRISP-DM guide's business-understanding sections to see why defining the customer's objective comes before choosing a technical solution.
In Chapter 1, “Business understanding,” read subsection 1.1, “Determine business objectives” (printed pp. 13–14). Begin where it says “The first objective of the data analyst is to thoroughly understand” and read the objective and outputs through the discussion of business success criteria. Then go to subsection 1.3, “Determine data mining goals” (printed p. 15). Starting with “A business goal states objectives in business terminology,” read the goal distinction through the description of intended outputs. Focus on the difference between what the organization hopes to accomplish and what the analysis can actually deliver.
To uncover the decision, ask what prompted the request, who will act on the result, when they must act, and what they might do differently depending on the answer. Listen before proposing a method. If the stakeholder cannot yet name a decision, that is useful information: the work may need to be a bounded exploration rather than an analysis promised to settle a particular choice.
Watch how an analyst probes beyond an initial request in this conversation. The example concerns sales and inventory, but pay particular attention to the questions about the stakeholder’s current process and how the findings would be used.
Deconstructing Data Science Questions with Stakeholders
Watch “Deconstructing Data Science Questions with Stakeholders” from Decisive Data for an example of discovering the operational need beneath an open-ended request.
Watch the initial discovery for the request and the questions about current work and available data. Then watch actions and next steps for the discussion of decisions the analysis could support. Notice that the proposed work becomes clearer as the analyst learns what the stakeholder does, not merely what data exists.
Write a question the analysis can answer
Once the decision is clear, translate it into a question about evidence. These statements play different roles:
- Decision: A choice the stakeholder can make, with a deadline.
- Analytical question: What the available evidence must help establish to inform that choice.
- Deliverable: The form in which the stakeholder will receive and use that evidence.
Suppose an operations director asks, “Can you make a dashboard about late deliveries?” A short conversation reveals a decision due next month: whether to trial an additional packing shift or prioritize a review of carrier arrangements. The director wants to know where time is being lost.
A useful initial analytical question might be:
For orders promised two-day delivery in the last eight completed weeks, how have late-delivery frequency and elapsed time before and after carrier handoff varied by fulfillment location and carrier?
This names a population, a period, and the comparisons relevant to the choice. “What is happening with deliveries?” names none of them. On the other hand, a question such as “Will a packing shift reduce late deliveries?” asks about the effect of a change that historical comparisons alone may not establish. The current analysis can locate a likely bottleneck and inform which option to investigate or pilot; it should not claim to prove which intervention will work.
Specificity does not require an elaborate formula at this stage. You do need enough precision to recognize an answer and spot a mismatch. If the stakeholder must choose between two operational responses, a company-wide monthly delivery total may conceal the distinction they need. Conversely, requesting every possible breakdown can turn a focused decision into an indefinite investigation.
A quick test is: If the question were answered, could the stakeholder explain how it would affect the choice? If the answer is no, revisit the decision or narrow the question.
Match the deliverable to its use
The deliverable is not an afterthought, but it should not dictate the question. A one-time decision next week may need a brief comparison and recommendation. A recurring weekly decision may justify a Power BI dashboard. An operational process that needs a prioritized list may eventually require predictions rather than charts. The same underlying data can support all three, at very different costs.
The following framework gives a practical way to agree on the output without assuming that the stakeholder’s first requested format is final.
Vague Stakeholder Requests: A Framework for Analytics
Read the “5-Step Translation Framework” for a compact approach to clarifying a request and agreeing on what will be delivered.
Under “5-Step Translation Framework,” read Steps 1–5, from “Step 1: Listen and Reflect” through “Step 5: Confirm in Writing.” Begin with “When you receive a vague request, resist the urge to immediately start scoping the work or pushing back” and read the five steps through the explanation of written confirmation. Focus especially on the questions in “Step 2: Clarify the Decision” and the choice of output in “Step 3: Define the Outputs.”
Return to the delivery example. If the director needs to choose a next investigation at a meeting, an appropriate deliverable could be a one-page briefing: a clear comparison of late deliveries and elapsed times, the most important data caveats, and a recommendation about which option merits a trial or further review. A live dashboard might be valuable later if the director needs to monitor the chosen response each week. It is not automatically the best first deliverable merely because the request used the word “dashboard.”
The same reasoning applies to data science requests. “Build a churn model” is a proposed method. If the underlying decision is which subscribers to contact within a limited outreach capacity, the analytical question must concern cancellation risk at the time a contact decision is made. The eventual deliverable must be usable by the outreach process, not simply a model score displayed in a notebook. That framing comes before selecting an algorithm.
Confirm the agreement in plain language
A short written confirmation makes the translation visible and gives the stakeholder a chance to correct it. For the delivery scenario, it might read:
Decision: At next month’s operations meeting, decide whether to trial an additional packing shift or prioritize a carrier review.
Analytical question: For two-day-delivery orders in the last eight completed weeks, where do late deliveries and extended elapsed times appear—before or after carrier handoff, and in which locations and carriers?
Deliverable: A one-page briefing for the operations director with the principal comparisons, limitations, and a recommendation for the next investigation or trial, delivered before the meeting.
To confirm: Are those the two options under consideration, and are promised-delivery and carrier-handoff timestamps reliable enough for this comparison?
The final line matters. You have proposed a frame, not discovered every requirement by intuition. If the director instead needs an ongoing weekly review, the deliverable should change. If handoff timestamps are unavailable, the question must change. Neither correction means the initial conversation failed; it means the work was clarified before substantial analysis began.
The three statements should fit together tightly. A decision without an analytical question leaves you guessing what to calculate. A question without a decision invites interesting but unfocused findings. A deliverable without either may look polished while answering the wrong need.
Key takeaways
Start by establishing who must choose what, and when. Form an analytical question whose answer could inform that choice, while respecting what the evidence can and cannot show. Then agree on an output suited to the audience and decision deadline, and confirm your interpretation in writing.
In the next lesson, you’ll distinguish descriptive, diagnostic, predictive, and causal questions—a sharper vocabulary for deciding what kind of answer a stakeholder is asking the data to provide.