Case studies rarely fail because of bad ideas. They fail because the problem was never clearly defined. Prompts are often incomplete on purpose, mixing goals, symptoms, and assumptions into a single request. The challenge is not to rush toward answers, but to slow down and separate what is known from what is assumed.
Strong product thinking starts with framing. A clear problem statement anchors decisions, keeps teams aligned, and prevents solution-first thinking. It forces focus on who is affected, what is actually happening, and why it matters now. Without this clarity, teams risk fixing surface issues while deeper causes remain untouched.
Ambiguity is not an obstacle but a signal. It shows where questions are missing, where data is unclear, and where priorities are not yet agreed on. Handling this well means identifying symptoms versus root causes, clarifying goals versus constraints, and asking questions that move the case forward instead of stalling it. This lesson builds the foundation for all later case work by sharpening how problems are defined before solutions are proposed.
Finding the case study real problem
Case prompts appear when product teams are asked to respond to a situation without full context. This happens in PM interviews, internal product reviews, leadership requests, and early discovery work. A prompt usually comes as a brief description of a concern, such as declining usage, slower growth, or an increase in complaints. It gives just enough information to start a discussion, but not enough to explain what is actually going wrong.
These prompts often describe outcomes or signals rather than problems. A metric moving in the wrong direction shows that something has changed, but it does not explain what users are struggling with or why the change is happening. Treating the signal itself as the problem leads teams to focus on visible effects while the underlying issue remains unsolved.
A real problem describes a specific difficulty people experience in a clear context. It focuses on the situation users are in and the impact that situation creates. It avoids naming solutions, features, or internal goals. When the problem is well defined, teams can consider multiple ways to address it without losing focus.
To identify the real problem, restate the prompt without metrics, tools, or desired outcomes. Ask what users cannot do, find confusing, or repeatedly work around. If the statement could reasonably be said by someone experiencing the issue, it is closer to the actual problem.[1]
Pro Tip! If the problem sounds like a dashboard alert, it is probably still a signal.
Problems vs solutions in a case study
Many case prompts include a solution disguised as a problem. Phrases like “we need to add,” “we should build,” or “the product lacks” point to actions, not to user pain. Starting from these statements narrows thinking before the problem is fully understood.
A problem exists even if no product or feature is named. It describes a gap between the current situation and the desired outcome from the user’s point of view. A solution is only one possible response to that gap. When teams confuse the two, they lock themselves into a single path and risk solving the wrong thing very well.
Translate solution-focused statements into neutral descriptions of what is difficult, slow, confusing, or risky for people. Remove references to tools, interfaces, or implementations. What remains should explain the struggle clearly enough that multiple solutions could reasonably address it.[2]
Pro Tip! If your statement becomes invalid when the feature changes, it was a solution, not a problem.
Clarifying vague prompts in case studies
In case studies, vague prompts define the starting point of the work. A prompt like “improve onboarding” or “increase engagement” is not incomplete by accident. It leaves space for PMs to show how they shape an unclear request into a workable problem.
Clarifying the prompt is a required step in a case study. Before comparing options or making trade-offs, PMs are expected to narrow the prompt into a concrete situation. This means choosing a specific group, moment, or difficulty that explains what is not working.
A vague prompt becomes usable when it is reframed as a problem that can be discussed consistently. For example, “improve onboarding” turns into a case problem when reframed as “new users abandon setup because the required steps are unclear.” The case now has a defined focus without implying a solution.
In case studies, clarification is successful when the rest of the analysis can proceed without revisiting what the problem actually is. If the discussion keeps circling back to interpretation, the prompt has not been clarified enough.[3]
Pro Tip! If you cannot explain the problem in one stable sentence, the case is not ready for solutions.
Goals, constraints, and symptoms in case studies
In case studies, prompts often bundle different types of information into one short description. Goals describe what success should look like, such as growth, retention, or efficiency. Constraints describe the boundaries of the case, like limited time, budget, or technical scope. Symptoms are visible signals, such as churn, low adoption, or complaints. None of these explains the problem on its own. They only set the scene.
Problem framing in a case study means identifying what sits underneath these elements.
The problem sits underneath goals, constraints, and symptoms. It explains what is actually causing the visible issue within the limits of the case. If a goal like “increase retention” is treated as the problem, the case turns into chasing numbers. If a symptom like churn is treated as the problem, the analysis stops at what is visible instead of why it happens.
For example, a case may mention rising churn and a goal to grow active users. The problem is neither churn nor growth. The problem might be that new users do not understand the product’s value during their first week, which leads them to leave.
A well-framed case problem remains valid even if goals change or constraints loosen. It captures a real difficulty people face, not just what the business wants to improve.[4]
Pro Tip! If removing the metric removes the problem, you were looking at a symptom, not the problem.
Checking causes through reasoning in a case study
In case studies, root causes are not checked through experiments or data collection. They are checked through reasoning. This applies whether the case appears in an interview, an internal product review, a leadership request, or early discovery work. At this stage, the goal is to show that the proposed cause explains the situation better than other possible explanations.
This step happens after the problem has been framed and before solutions are discussed. PMs should pause to ask whether the cause they identified truly accounts for the symptom described in the case. The question is not whether the cause can be proven right now, but whether it logically fits the context, constraints, and known user behavior.
For example, a case may describe low engagement with a key feature. Saying “users are not aware of it” is a possible explanation, but it needs to hold up under reasoning. If the feature is already visible during onboarding or promoted in multiple places, awareness alone is unlikely to explain the behavior. A stronger cause might be that the feature appears at the wrong moment or does not help users complete their main task.
Strong case analysis treats causes as explanations that must stay consistent when questioned. PMs demonstrate this by showing how the cause leads to the symptom within the limits of the case. If the explanation falls apart when assumptions are challenged, it is probably not the right cause.
Working with missing information in case studies
Case studies almost never give the full picture. Some details are missing, unclear, or only hinted at. This is not a mistake. Case studies mirror real product situations where PMs must move forward without having all the answers.
In a case study, missing information is something to work with, not something to wait out. PMs are expected to notice what is unknown and decide how to handle it. Some gaps need to be acknowledged. Others can be filled with reasonable assumptions so the case does not stay stuck.
The key is choosing assumptions that feel realistic and grounded in the prompt. If a case does not mention a target group, narrowing the problem to a likely audience helps make the discussion concrete. If constraints are unclear, PMs may assume typical limits and explain why those limits make sense. What matters is not the assumption itself, but how clearly it is explained.[5]
Asking useful, clarifying questions when presenting case studies
In case studies, clarifying questions help shape the problem before any analysis begins. They are useful when the prompt leaves room for different interpretations. Without question, it is easy to move forward with assumptions that later turn out to be wrong.
When deciding what to ask, focus on questions that would change how the problem is defined. For example, understanding whether a goal is short-term or long-term can affect which users matter most. Clarifying who the case is really about can narrow the scope and prevent the discussion from staying abstract.
It is not necessary to ask about every unknown detail. Too many questions can slow the case down or shift attention away from the core issue. A good approach is to ask a small set of questions that clarify intent, priorities, or constraints, and then continue working with the available information.
If an answer is unlikely to affect the problem framing, it is usually better to make a reasonable assumption and state it clearly. This keeps the case moving while showing structured thinking.[6]
Checking problem importance in case studies
In case studies, not every problem described is equally important. Prompts may mention several issues at once, but the task is to understand which one truly matters right now. Without this step, case analysis can drift toward problems that are easy to discuss but not worth solving.
Checking problem importance means asking whether the problem has enough impact to justify attention. This includes how often it occurs, how strongly it affects people, and what happens if it stays unsolved. A problem that causes mild inconvenience once in a while is very different from one that blocks progress or creates repeated frustration.
In a case study, importance is judged through reasoning, not data validation. PMs explain why this problem deserves focus compared to other possible issues in the same context. For example, if users complain about a missing feature but still complete their main task, that problem may be less important than a smaller issue that stops them from finishing key actions.
A well-chosen case problem creates a strong foundation for later decisions.
Connecting case study problems to user and business context
In case studies, a well-framed problem needs to make sense from two sides at once. It should reflect a real difficulty people face and explain why the business should care. Focusing on only one side makes the case feel incomplete or biased.
Connecting the problem to users means describing who is affected and in what situation. Connecting it to the business means explaining how this difficulty influences outcomes like growth, retention, cost, or risk. In a case study, this connection is usually made through reasoning rather than numbers. The goal is to show how user pain and business impact are linked, not to calculate exact metrics.
For example, a case may describe users abandoning a flow. From the user side, this could mean confusion or extra effort. From the business side, it could mean lost conversions or lower retention. Stating both sides helps justify why this problem deserves attention now.
A strong case problem does not treat user needs and business goals as competing forces. Instead, it shows how solving a real user difficulty supports what the business is trying to achieve.
Pro Tip! If you can explain the problem without mentioning users or the business, it is probably too abstract.
