In the previous lesson, you learned to transform vague requests into sharp decision questions. But having a clear question is only the beginning. The next challenge is partnering with analysts and data scientists to actually get the analysis done. This partnership often breaks down: managers hand off poorly scoped requests, analysts disappear into complex methodologies, and weeks later everyone wonders why the output doesn't match what was needed.

Throughout this unit, you'll learn how to brief data experts with the business context they need, how to ask smart questions about their work without pretending to be a statistician, and how to co-create project scopes that stay realistic and aligned with your timeline. When you master these skills, your analytics projects will be faster, more focused, and far more likely to drive the decisions you care about.

Analysts and data scientists can only do great work if they understand the why behind your request. When you approach a data expert with "Can you analyze our retention data?" and nothing else, you're asking them to guess what matters. They might spend days building something sophisticated that completely misses the point. The solution is to provide a proper brief that includes business context and your initial hypotheses.

Start with the decision you're trying to make, which you already defined in the framing stage. Then add the business context: what's happening in your area, why this question matters now, and what you already know or suspect.

Your hypotheses are particularly valuable. A hypothesis is simply your best guess about what's going on, stated in a way that can be tested. These hypotheses don't need to be right. In fact, they might be completely wrong, but they give the analyst something concrete to investigate. Without hypotheses, analysts often resort to exploratory fishing expeditions that take longer and produce less actionable results.

Here's an example of how a People Manager might brief an analyst effectively:

• Ryan: Thanks for meeting with me. I need help understanding why we're seeing higher turnover on the customer success team.
• Jessica: Sure, what's the decision you're trying to make with this analysis?
• Ryan: We're deciding whether to redesign the onboarding program or focus on improving manager check-ins for the first 90 days. Turnover among employees with less than a year of tenure jumped 15% last quarter.
• Jessica: That's helpful context. Do you have any initial hunches about what's driving it?
• Ryan: I suspect that new hires who don't get paired with a mentor in their first week are more likely to leave early, but I could be wrong—that's where I need your help.
• Jessica: That's a testable hypothesis. Let me see what data we have on mentor assignments and early departures, and I'll come back with what's feasible by Thursday.

Notice how Ryan provided the specific decision on the table, shared relevant business context about the 15% turnover increase, and offered a testable hypothesis about mentor pairing. This gives Jessica everything she needs to scope the work appropriately and deliver something actionable.

Think of a brief as a one-page document, or even a focused conversation, that answers four essential questions:

Once an analyst starts working on your request, your job isn't to disappear until they deliver a finished product. Your job is to stay engaged, but in a way that adds value rather than micromanaging technical decisions. The key is asking good questions about data, methods, and limitations without pretending to understand every statistical nuance.

You don't need to know how a regression model works to ask something like: "What data are we using, and does it cover the customer segments I care about?" Phrasing questions in plain-language helps you understand what the analysis can and cannot tell you, and they signal to the analyst that you're a thoughtful partner who cares about quality.

Consider building a small toolkit of questions worth asking throughout any project. On the data side, you might explore where the information comes from and whether there are any gaps or known issues, as well as whether the data represents all your customers or just a particular subset. When it comes to methods, asking the analyst to walk you through the approach in simple terms can be illuminating. You might also inquire about the main alternatives they considered and why they chose this particular path. For understanding limitations, questions about what could make the results misleading and how confident you should be in the numbers help you interpret findings appropriately.

Some managers worry that asking basic questions will make them look ignorant. In reality, the opposite is true. Analysts respect partners who engage thoughtfully and admit what they don't know. What frustrates them is managers who either ignore the work entirely or challenge conclusions without understanding the underlying logic.

One of the most common partnership failures happens when scope expectations diverge. You might imagine a quick analysis ready by Friday; the analyst might envision a comprehensive study taking six weeks. Neither is necessarily wrong, but if you don't align upfront, someone will be disappointed. The solution is to co-create the scope together, treating it as a negotiation rather than a handoff.

Start by sharing your ideal timeline and what precision you actually need. There's a big difference between "I need directional guidance by Thursday to inform a conversation" and "I need statistically rigorous findings for a board presentation next month." Be honest about the stakes and the deadline, and ask the analyst what's feasible given those constraints. You might hear something like "I can give you preliminary numbers by Thursday, but the full segmented analysis would take two more weeks." That's useful information. Now you can decide whether preliminary is good enough or whether you need to push out your decision timeline.

The scope conversation should also address what's out of scope. Analysts often see opportunities to expand a project, suggesting they could also look at pricing sensitivity or build a predictive model while they're working with the data. Sometimes those additions are valuable; often they're scope creep that delays the core deliverable. Practice saying something like: "That sounds interesting for a future phase—let's stay focused on the original question for now." This keeps projects tight and ensures you get what you actually need when you need it.

Finally, document the agreed scope in writing, even if it's just a short email or shared note. This documentation should capture the decision question, the hypotheses being tested, the data sources, the timeline, and any explicit exclusions. Having this record protects both parties and makes it easy to get back on track if the project starts drifting.

In the upcoming roleplay session, you'll practice these skills by meeting with a data scientist to request help on a business problem. Instead of handing off a vague request, you'll explain the decision, share your initial hypotheses, and negotiate a focused, time-bound scope that sets both of you up for success.