Problem shaping and reframing is technique 3.15 of the IIBA Guide to Business Data Analytics. Shaping refines a problem until a solution process can be applied. Reframing restates it in a different context [1]. For the CBDA exam it sits in Identify the Research Questions, 20% of the 75 questions [2]. The guide gives it about two pages. I think it carries more weight than that, because a wrong problem makes every later domain wrong too.
Problem shaping and reframing at a glance
The technique is a thinking discipline, not a tool or a model. The facts:
| Item | Value |
|---|---|
| Guide section | 3.15, chapter 3 (Techniques) [1] |
| Purpose | Creative use of problem analysis techniques that gives an alternative formulation of the problem [1] |
| Listed in | 2.1.7, Select Techniques for Identify the Research Questions, as "Problem Reframing and Shaping" (no BABOK reference) (Guide, 2.1.7) |
| Elements | Problem Frame and Context; Problem Statement [1] |
| Main output | A documented original, reshaped or reframed problem statement [1] |
| Exam | 75 multiple-choice, scenario-based questions in 2 hours, online with remote proctoring; Domain 1 is 20% [2] |
Last verified: November 2026 (exam facts on iiba.org; guide text checked section by section).
What the guide says the technique is
The guide defines two moves that work together [1]:
- Problem shaping refines the problem "to a state where a solution process can be applied".
- Problem reframing restates the problem in a different context.
The guide calls them interdependent. Both should lead to "simpler or more creative solutions" [1].
The description starts with a warning. Analytics teams may jump to the available data without enough attention to the problem. The process can be scientific and technically advanced and still not check whether the right business problem is being solved [1]. Domain 1 says the same in task language: urgency pushes teams to a solution focus, which can lead to a "misdiagnosis of the business problem" (Guide, 2.1.1).
The guide also puts root cause analysis in its place. 5 Whys and Fishbone (Ishikawa) are "reductive in nature" [1]. They help to narrow the problem down. But a completely different framing "may enable better or easier solutions" [1]. So shaping usually narrows, and reframing changes the angle.
The guide's own example is a health insurer that sets the premium for its products. The reframe moves from the insurer's view to the customer's view: lifestyle, demographics, medical history [1].
Where problem shaping and reframing is used in the CBDA domains
Section 3.15 has no domain-by-domain subsection. The links come from chapter 2:
| Domain, task or section | What the guide says |
|---|---|
| 2.1.1, Define Business Problem or Opportunity | Teams tend to "jump into a solution focus"; the business problem is usually a higher-level description than a research question (Guide, 2.1.1) |
| 2.1.3, Assess Current State | A bicycle maker wants a better forecast. Current state analysis can turn the question from "improve the forecasting model" into local suppliers and assembly, or into seasonal patterns: "re-framed research problems" (Guide, 2.1.3) |
| 2.1.5, Formulate Research Questions | Business needs may or may not need analytics; good questions do not use technical language (Guide, 2.1.5) |
| 2.1.7, Select Techniques | Thinking about a problem "from multiple perspectives such as stakeholder, market, or customer" (Guide, 2.1.7) |
| 2.1.8, Case study | The analyst uses 5 Whys "as referenced in 3.15" and re-frames the business problem (Guide, 2.1.8) |
The 2.1.7 row has the example I would remember. A team must find high-value customers for a campaign. First it has to decide what "high value" means: lifetime value, highest spending, or interest in high-value purchases (Guide, 2.1.7). Three definitions give three different research questions and three different data sets.
For the whole domain, see Identify the Research Questions, Domain 1.
The two elements of the technique
The guide describes two elements: the frame and context, and the problem statement [1].
Problem frame and context
Context is "the circumstances" that influence the problem or the solution, are influenced by it, or explain it [1]. The guide lists industry, perceptions, assumptions, best practices, processes, goals and regulations [1].
The two moves treat context differently [1]:
| Shaping | Reframing | |
|---|---|---|
| What happens to context | Analysed, with extra focus on symptoms, root causes, constraints and risks | Consciously challenged |
| Typical result | A narrower, solvable problem or concrete sub-problems | Restated assumptions, perceptions and business goals |
| Typical tools (my mapping) | 5 Whys, Fishbone, which the guide calls reductive [1] | A different viewpoint: stakeholder, market or customer (Guide, 2.1.7) |
Problem statement
The original, reshaped or reframed problem is clearly stated and documented [1]. A good statement removes ambiguity in how stakeholders see the problem and gives ownership to the stakeholders it affects [1]. The guide suggests four parts [1]:
- Problem statement: key statements that describe the problem or opportunity.
- Impacted stakeholders: who is affected or influenced.
- High-level solution or key needs: for analytics, the approach, the required data and the problem type (descriptive, predictive or prescriptive).
- Comparison to an alternative formulation of the problem.
Part 4 is the one I would never skip. Without it, a reframe looks like the analyst's opinion. With it, stakeholders see two versions side by side and choose.
A worked example: a returns dashboard request
This example is invented, and so are the numbers. An online furniture retailer sees returns grow. The head of e-commerce asks for a dashboard of return rates by category.
- Original request. "Build a return-rate dashboard by category." It is a solution, not a problem.
- Shape it. Symptoms: the return rate went from 8% to 11% on about 120,000 orders a quarter. That is 9,600 returns before and 13,200 now, so 3,600 extra returns. A 5 Whys pass on return reason codes shows that "looks different from the photo" and "wrong size" grew from 30% to 45% of returns. That is 2,880 returns before and 5,940 now. These two reasons explain 3,060 of the 3,600 extra returns, about 85%.
- Shaped problem. "Which product groups and reasons drive the 3-point rise in returns since Q2?" This is a diagnostic question with a clear data set.
- Reframe it. Look from the customer's side, like the guide's insurer example [1]. The customer does not want to return a sofa. The customer wants to know before buying that it fits the room. New frame: "How can we help customers choose the right size and look before they order?"
- What the reframe opens. New data sources: size guide usage, photo zoom, room planner sessions. And a non-analytics option: add real dimensions and a person next to the sofa on product photos. The guide lists both as strengths of the technique [1].
- Write the statement. Problem: returns for size and look reasons grew by about 3,060 a quarter. Stakeholders: e-commerce, category managers, customer service, logistics. Key needs: diagnostic analysis now, maybe a predictive "fit risk" score later; order, return-reason and product-page data. Alternative formulation: the original dashboard request, with the reason it was set aside.
The dashboard may still be built. But now it answers a question that someone will act on.
Strengths and limitations
The guide lists four strengths and three limitations [1]:
| Strengths [1] | Limitations [1] |
|---|---|
| Robust analysis of the problem context, so the analytics work is aligned to business objectives | Can conflict with how stakeholders see the problem; buy-in from key stakeholders is crucial |
| An outsider view that attracts fresh solution approaches | Limited to individual creativity and knowledge; the fix is a group exercise, such as brainstorming or stakeholder workshops |
| Can uncover new data sources | May ignore data cues from earlier analysis or bring in the personal bias of an influential stakeholder |
| Can uncover non-analytics solutions that are simpler or more feasible |
My take on the last strength: it is the most testable line. My guess is that some scenarios reward the analyst who finds out that the business need does not need a model at all. The guide supports this in 2.1.5, where business needs "may or may not involve analytics initiatives" (Guide, 2.1.5).
What data and practitioners say
The research says that wrong problems are common and expensive. In surveys of 106 C-suite executives from 91 private and public-sector companies in 17 countries, 85% agreed or strongly agreed that their organizations were bad at problem diagnosis, and 87% said this carried significant costs [3]. A 2024 study based on interviews with 65 data scientists and engineers names misunderstood or miscommunicated problems as the first root cause of AI project failure [5]. An open-innovation platform CEO argued in 2012 that most organizations cannot state their problems clearly and concisely [4]. He ran an open-innovation platform at the time, so I read this as a view, not as data.
Practitioners describe the same pattern, request first and problem later:
- The dashboard nobody opened. An analytics leader recalls a regional performance dashboard for a consumer goods client. The stakeholder opened it once. Her real concern was the gap between forecast and actuals, so the team replaced the dashboard with a one-page scorecard [6].
- Not a dashboard at all. A performance analyst on a public health screening service was asked for a dashboard. The real need was "a single, easily accessible view" [7]. For a pilot, a one-off analysis told the story better [7].
- Messages vs capacity. A product manager with 15 years of experience got a request for drivers to message their arrival time. Repeated "why" showed the real need was warehouse capacity planning, which was solved without a new messaging app [8].
- One question that saved two weeks. A hotel analytics practitioner asks leaders what would change their mind. A vague pricing request turned into a focused gap analysis: two analysts, one week [9]. Early in that career, an open-ended request had become two weeks of "whack-a-mole" [9].
- Wrong churn. A data science consultant describes a churn model framed as monthly churn, while customers signed two- to three-year contracts. The right question was whether a client would renew or extend [10].
- Wrong target. A customer insight consultant who led a churn model team reframes churn from "who will leave" to "which action pays off for which customer" [11]. In his example, a 5% discount that cuts churn from 10% to 2% lifts retained revenue from 90% to 93.1%. If churn only falls to 9%, retained revenue drops to 86.45% [11].
- Risk is not uplift. An applied ML teacher tested this on a public data set of 64,000 customers. At a 10% budget, targeting by uplift gave 73 extra visits per 1,000 customers e-mailed, risk-based targeting gave 49, and random selection 45 [12]. It is an experiment on public data, not a client story.
- "Encrypted" data. A business analyst got a report that customer emails were "encrypted". Looking at the email showed raw XML on the page, fixed with one parameter change [13].
- Reports nobody reads. In a community thread about analytics frustrations, one analyst says only about 10% of people look at the reports they asked for. Another says requesters "refine or redefine their requests over and over again" [14].
From the exam side, a data analyst with more than ten years of experience said that many CBDA questions "had two confusing answers" [23]. Domain 1 questions often look like that: one option jumps to the data, the other first restates the problem.
Where experts disagree
Practitioners agree that the stated request is often not the real problem. They do not agree on how much time to spend on it, how hard to push, or which tool to trust.
1. Always reframe first. Executive surveys [3], the 2024 AI failure study [5] and the 2012 article [4] all argue that problem definition decides much of the outcome. In a later interview, the author of [3] suggests winning over colleagues who favour quick action by proposing to look at the issue for 15 minutes first [22].
2. Long discovery is a disease. A product discovery consultant argues that a team should spend no more than a typical two-week sprint on discovery: "If it takes longer, something is wrong." [15]. I think the guide would agree with the time box, not with skipping the step.
3. Do not interrogate the requester. An analytics consultant warns that asking "what will you do with that?" can make the analyst look "adversarial" [16]. His alternative is to assume a real need, write it down yourself and play back hypotheses [16]. A business analysis consultant offers a softer question about the core outcomes the stakeholder wants [21]. My view: the guide's problem statement does this work. You write the reframe and the alternative side by side and let the stakeholder choose.
4. 5 Whys is too narrow. A patient safety researcher argues that 5 Whys forces users down "a single analytical pathway" and should be abandoned as a root cause analysis tool, especially in patient safety [17]. A Lean author answers that there is "no magic about the number five" and that solving the problem is what matters [18]. The guide takes a middle line: 5 Whys is reductive, useful to narrow, and reframing is the counterweight [1].
5. Data first or problem first. A biostatistician argues that much of the work is "figuring out a better question", and that exploration can give better questions [19]. A decision scientist describes analysts whose job is to say what is in the data, while decision-makers pick the problems worth deep work [20]. The guide warns against reviewing data without enough attention to the problem [1], but it also lists Exploratory Data Analysis for Domain 1 (Guide, 2.1.7). I read this as: explore, but write the problem down first.
How it differs from similar techniques
Problem shaping and reframing sits next to several Domain 1 techniques:
| Compared with | Difference in the guide |
|---|---|
| Root Cause Analysis (BABOK 10.40) | Systematically examines probable causes (Guide, 2.1.7); 5 Whys and Fishbone are reductive, reframing changes the frame [1] |
| Hypothesis Formulation and Testing (3.12) | Develops a premise from a stakeholder's or SME's opinion and tests it with data (Guide, 2.1.7) |
| Exploratory Data Analysis (3.11) | Builds intuition from readily available data (Guide, 2.1.7) |
| Stakeholder List, Map, or Personas (3.16) | Analyses stakeholders and how they generate and consume data (Guide, 2.1.7) |
| Scope Modelling (BABOK 10.41) | Sets the scope and boundaries of the engagement (Guide, 2.1.7) |
The closest neighbour is Hypothesis Formulation and Testing: reframing decides what to ask, a hypothesis decides what to test. Exploratory Data Analysis is the other side of the debate above.
Exam traps for problem shaping and reframing
| Scenario | Tempting answer | Guide reading |
|---|---|---|
| Which domain lists the technique? | Analyze Data | Identify the Research Questions, 2.1.7 (Guide, 2.1.7) |
| A sponsor asks for a model on day one | Start collecting data | Define the problem first; teams tend to jump to a solution focus (Guide, 2.1.1) |
| Refine the problem until a solution process fits | Reframing | Shaping [1] |
| Restate the problem from the customer's view | Root cause analysis | Reframing [1] |
| The reframe shows no model is needed | Build the model anyway | Non-analytics solutions are a strength of the technique [1] |
| One analyst reframes alone and the result is narrow | Hire a better analyst | Run a group exercise: brainstorming or stakeholder workshops [1] |
| A senior stakeholder pushes his own framing | Accept it, he owns the budget | The guide warns about the personal bias of an influential stakeholder [1] |
| What does the problem statement include? | A project schedule | Statement, impacted stakeholders, key needs, comparison to an alternative [1] |
The day-one model trap has its own breakdown: the COO wants a churn model on day one. For more Domain 1 scenarios, use the CBDA research questions drill.
Check yourself: CBDA practice questions
1. An analytics team restates a premium-pricing problem from the customer's perspective, including lifestyle and medical history. What is this? A) Problem shaping. B) Problem reframing. C) Root cause analysis. D) Data mapping.
Answer: B. Reframing restates the problem in a different context; the guide's insurer example moves from the insurer's view to the customer's [1].
2. Which element is part of a reframed problem statement in the guide? A) A comparison to an alternative formulation of the problem. B) The final model accuracy. C) A sprint plan. D) The data warehouse schema.
Answer: A. The four parts are the statement, impacted stakeholders, key needs, and a comparison to an alternative formulation [1].
3. An analyst reframes a problem alone and worries the result reflects only her own view. What does the guide suggest? A) Skip reframing. B) Ask the sponsor to decide. C) A group exercise, such as brainstorming or a stakeholder workshop. D) Run a hypothesis test.
Answer: C. The limitation is individual creativity and knowledge; the guide's fix is a group exercise [1].
Conclusion: the gap between the guide and real requests
The guide's two moves match what practitioners describe, but in real work the reframe often has to beat a request that is already a solution.
| Area | Guide | Reality | Delta |
|---|---|---|---|
| Starting point | A business problem or opportunity (Guide, 2.1.1) | A request for a dashboard, report or model [6, 7, 14] | Reduced to a solution request |
| Diagnosis | Shaping with symptoms, root causes, constraints [1] | 85% of executives say their organizations are bad at it [3] | Under-used |
| Root cause tools | 5 Whys and Fishbone, reductive [1] | Some researchers reject 5 Whys, others defend it [17, 18] | No gap |
| Time spent | Not set by the guide | Practitioners time-box discovery or start with a short look [15, 22] | Added by practitioners |
| Non-analytics outcome | A strength [1] | Real cases end with a scorecard or a one-off analysis [6, 7] | No gap |
So, for the exam, learn the two moves and the four-part statement. For real work, I would add one habit: every time a request names a solution, write the problem it is supposed to solve next to it, and show both.
Related topics
- CBDA exam simulator with full mock exams.
FAQ
What is problem shaping and reframing in the CBDA guide?
It is technique 3.15 of the IIBA Guide to Business Data Analytics. Shaping refines a problem until a solution process can be applied. Reframing restates the problem in a different context. Together they help the team find the real business problem before analysis starts.
What is the difference between problem shaping and problem reframing?
Shaping analyses the context with focus on symptoms, root causes, constraints and risks, and usually narrows the problem. Reframing consciously challenges the context, so assumptions, perceptions and business goals may be restated. The guide calls the two interdependent.
Which CBDA domain uses problem shaping and reframing?
The guide lists it in section 2.1.7, Select Techniques for Identify the Research Questions. This is Domain 1, which makes up 20% of the CBDA exam.
What goes into a reframed problem statement?
The guide suggests four parts: the problem statement, the impacted stakeholders, a high-level description of the solution or key needs (approach, data and type of analytics), and a comparison to an alternative formulation of the problem.
Is 5 Whys the same as reframing?
No. The guide calls 5 Whys and Fishbone reductive techniques that help narrow a problem down. Reframing looks at the problem from a different context, which may lead to better or easier solutions.
Sources
- IIBA: Guide to Business Data Analytics, 3.15 Problem Shaping and Reframing
- IIBA: Certification in Business Data Analytics (CBDA)
- Are you solving the right problems? Harvard Business Review (2017), PDF copy
- Are you solving the right problem? Harvard Business Review (2012), PDF copy
- RAND: The root causes of failure for artificial intelligence projects (2024)
- The customer is always right? (2025)
- Maybe you don't need a dashboard (2025)
- Product management: defining the problem (2022)
- The question that separates analysts
- Problem framing for data scientists (2021)
- Why your churn model isn't working (2022)
- Why churn prediction models fail at customer retention (2026)
- What problem are you trying to solve?
- Reddit r/analytics: What are your biggest frustrations in analytics?
- The discovery illness (2024)
- What will you do with that? (2017)
- BMJ Quality & Safety: The problem with "5 whys" (2016)
- Rethinking the five whys (2015)
- Tukey, design thinking, and better questions (2019)
- What great data analysts do, and why every organization needs them (HBR 2018, republished)
- But I already know what I want: helping stakeholders think beyond one solution
- Re-framing problems can lead to a better range of solutions (2021)
- CBDA certification journey of a data analyst (2024)