Good analysis starts with the right question. Framing the question before analyzing data is a critical first step that shapes the entire research or analysis process. A lot of analytical work can go off track if the question is never clearly defined to support a useful answer.

A vague business question can show up in different ways. For example, one request might focus on improving customer satisfaction. Another may ask whether a promotion worked well. Another might start with complaint narratives and a question about what customers are saying. These all are different business contexts that pose the same analytical challenge. The initial question usually is not specific enough to function as an analysis plan.

Turning these kinds of requests into an analysis plan is the step that gives the rest of the work structure. In this post, rather than walking through a specific project, I break down how to frame the question in six steps. The goal is to provide a repeatable framework that can be applied across different types of analytical work.

Most business questions arrive half-formed

In practice, people rarely ask for analysis in precise terms. They usually bring a concern, a goal, or a general direction.

They might ask:

• How can we improve satisfaction?
• Did the promotion work?
• What are customers complaining about?

Each of these raises a real analytical issue, but none of them is specific enough to analyze on its own. The first step is recognizing that the initial request is not the finished question. Rather, it is the starting point. Before pulling data, writing code, or building visuals, the question usually needs to be defined enough to give the analysis real direction.

Essentially, this means shifting from a broad business question to one that is specific, measurable, and has a clear decision behind it.

Six steps to framing the question

The following steps are a repeatable framework for turning a vague business question into an analysis plan.

1. Capture the question as given

Start by writing the request exactly as it was asked without too much interpretation.

This matters for two reasons. It keeps you grounded in the original business concern and establishes a baseline. By the end of the process, you should be able to see how much the question has changed.

This change usually is a good sign because it means the work has shifted from a general topic to a more analytical focus.

Diagnostic question: What exactly did they ask for in their own words?

2. Identify the decision

A question becomes clearer when you know what someone plans to do with the answer.

Let’s say a stakeholder wants to improve customer satisfaction. This isn’t actually a question, it’s a goal. It has no analytical meaning until you break it down further. Step two exposes this immediately. What decision does someone make based on the answer? Are they trying to prioritize service improvements? Determine whether to change a product feature? Identify weaker touchpoints?

This step also helps reveal the real audience. The same broad question can lead to very different analysis plans depending on whether the audience is a product team, an operations team, or leadership.

If you can’t name a decision, then you probably don’t have an analysis question yet. You have a topic. Work backward from what action the stakeholder needs to take. The question should be framed to guide a specific decision, not just describe a situation.

Diagnostic question: What does someone do differently based on the answer?

3. Make the assumptions explicit

Every business question carries underlying assumptions. List them explicitly and challenge at least one before moving forward.

A question like “How can we improve customer satisfaction?” assumes there is meaningful room to improve, that the metric is stable enough to evaluate, and that the available data can point to useful interventions. Likewise, asking “What are customers complaining about?” assumes the complaints are numerous enough to analyze, that they can be meaningfully grouped into themes, and that the narratives reflect something worth acting on.

Skipping this step is a good way to execute well on the wrong question.

Diagnostic question: What does this question assume is already true?

4. Translate the business question into an analytical question

This is the core move. The business question is broad and strategic, while the analytical question is more operational, specific, and testable. Translating one into the other explicitly is where most framing breaks down in practice.

This step usually means clarifying:

• What exactly will be measured
• For whom
• Over what period
• Compared to what

This also is where vague language starts to become useful language. Terms like satisfaction, promotion success, or complaint themes can stay in the conversation, but they cannot stay undefined in the analysis plan.

A stronger analytical question will usually sound less natural than the original request, which is normal. It is a sign that the work is becoming more precise.

Diagnostic question: What exactly would I measure, for whom, over what period, and compared to what?

5. Define what a useful answer looks like

Decide what kind of answer would actually be useful before working with the data. Is the goal a comparison? A trend? A ranking? A segmentation? A set of themes? A recommendation?

This step matters because not every analysis needs the same kind of output. A technically correct answer still can miss the point if it does not support the decision from step two. A useful answer is not just one that is accurate. It also needs to be sufficient for the purpose of the work.

Diagnostic question: What would a useful answer look like, and how will I know when the analysis is sufficient?

6. Constrain the scope

Once the target answer is clear, set the boundaries. An unconstrained question leads to unfocused analysis.

This is where you decide what population is being analyzed, which time period matters, which data sources will be used, and what will be excluded. Without this step, the analysis can keep expanding until it becomes too broad to produce a useful answer.

Diagnostic question: What is explicitly included and excluded for the analysis?

What this looks like in practice

The framework becomes more useful when applied to a real question. Here are two examples.

Example 1: Improving customer satisfaction

Start with the vague version:

How can we improve customer satisfaction?

This is a real business question, but it leaves too much open. Improve what, exactly? The average score? Top-box satisfaction? Consistency across segments? A specific part of the experience?

Now, let’s walk it through the framework.

1. Capture the question as given

The request is: “How can we improve customer satisfaction?”

2. Identify the decision

The likely decision is where to focus improvement efforts. That could mean prioritizing touchpoints, customer segments, or experience dimensions that offer the clearest opportunity.

3. Make the assumptions explicit

This question assumes:

• Satisfaction is already being measured consistently
• There is room to improve
• The data can help identify where improvements matter most
• “Improve” means something more specific than simply raising an overall average

4. Translate it into an analytical question

A stronger version might be:

Which experience dimensions most distinguish highly satisfied respondents from moderately satisfied respondents over the last four quarters?

This version is better because it defines a comparison and narrows the problem. Instead of talking vaguely about improvement, it asks what separates stronger outcomes from weaker ones.

5. Define what a useful answer looks like

A useful answer might look like:

• A ranked set of experience dimensions that best separate highly satisfied from moderately satisfied respondents
• A view of which customer segments lag despite healthy overall satisfaction
• A short list of likely improvement priorities

6. Constrain the scope

Now set the boundaries:

• Respondents from the last four quarters
• One survey instrument, not every available feedback source
• Key experience dimensions
• Incomplete responses excluded
• Segments outside the target audience excluded

At this point, the question is no longer “How can we improve customer satisfaction?” Instead, it has become an analysis plan with a defined comparison, a defined period, and a clearer idea of what the answer should deliver.

Example 2: Identifying customer complaints

Now, let’s take a different kind of question:

What are customers complaining about?

This sounds straightforward, but it is still broad. Which customers? Which complaints? Across what period? Are we trying to summarize the most common issues, compare themes across categories, or track how complaints changed over time?

Now work it through the same steps.

1. Capture the question as given

The original request is: “What are customers complaining about?”

2. Identify the decision

The decision might be where to investigate further, which issues deserve attention first, or whether certain complaint types are becoming more prominent over time.

3. Make the assumptions explicit

This question assumes:

• Complaint narratives contain patterns that can be grouped meaningfully
• The complaint set is relevant to the decision
• The goal is not just to collect examples, but to produce a structured view
• Frequency alone is not the only thing that matters

4. Translate it into an analytical question

A stronger version might be:

Which complaint themes appear most often in credit card complaint narratives, and how do those themes differ by issue type over time?

This is much more usable because it defines the corpus, introduces comparison, and makes the objective clearer. The goal is more than simply describing complaints in general. Rather, it is to identify themes within a defined set and compare how they vary.

5. Define what a useful answer looks like

A useful answer might include:

• The main complaint themes
• How theme frequency differs by issue type
• Whether certain themes are rising or falling over time
• A short list of themes worth deeper review

6. Constrain the scope

Now define the boundaries:

• Credit card complaint narratives only
• A specific date range
• Narratives with usable text
• Issue-type categories selected for comparison
• Records outside the target product or period excluded

The point here is not that the original question was bad, but that it was too broad to guide work without being translated first.

I should also note that the framework is presented linearly, but in practice the process usually is not. It often requires looping back, especially between steps three and four. Once you try to translate a business question into an analytical question, you’re forced to get specific about what you will actually measure. That level of specificity almost always reveals assumptions you didn’t catch before.

Why this matters

The rest of the analysis usually gets easier once the question is more focused. The data pull becomes more targeted because you know what fields, population, and time period matter. Validation becomes more relevant because you know which assumptions need to be true. Visuals get better because they are built around actual comparison instead of a generic summary. The final answer becomes easier to defend because the logic was clarified before the numbers showed up.

This is precisely why framing the question should sit inside the analysis process. Because it shapes what gets measured, how it gets measured, and what kind of conclusion the work can support.

A simple test

A rough test is to see whether simple follow-up questions expose major ambiguity. If so, the analysis plan probably needs more work.

These questions speak to the core of the analysis:

• What exactly are we measuring?
• Why this definition?
• Why this period?
• Compared to what?
• What is included?
• What is excluded?
• What decision does this support?

If the answers are still unclear, then the business question likely isn’t framed will enough to begin the analysis.

From question to plan

Turning a vague business question into an analysis plan is an essential part of analytical work. It is the process of moving from a topic to something measurable, from an initial request to a defined structure, and from a general concern to a question the data can actually answer. This is where the analysis starts to become practical.