Every analytics project that fails quietly usually failed at the very start: the team answered a question nobody actually needed answered. The IIBA Guide to Business Data Analytics puts the cure right at the front of its competency model. Identify the Research Questions — the first domain — is the discipline of turning a vague business complaint into a structured, testable question with measurable success criteria, before a single row of data is touched. This guide walks through why that matters for the CBDA exam, the seven tasks that make up the domain, a worked example of formulating real research questions, and a checklist for validating them.
Identify the Research Questions is roughly 20% of the CBDA exam — tied for the largest single domain in the blueprint. That weighting is not an accident. The IIBA frames the analyst here as a facilitator, not a solo problem-solver: your job is to convene the right people, surface competing views, and shape a shared question, not to retreat to a desk and "figure it out." Get this domain right and everything downstream — sourcing data, analysing it, reporting, and influencing decisions — has a clear target. Get it wrong and you produce a technically flawless answer to the wrong question, which is the most expensive kind of analytics waste.
The "jump to solution" anti-pattern
The single most tested failure mode in this domain is the urge to jump straight to a solution. A stakeholder says "we need a churn-prediction model" or "build me a dashboard," and an inexperienced analyst starts building. The Guide is explicit (§2.1.1): you must invest time in problem definition with the right stakeholders before any analytics work begins. The requested tool is a hypothesis about the solution, not a statement of the problem. Skipping straight to it risks solving a misdiagnosed problem with confidence. If you take one idea into the exam, take this: the analyst's first move is to define the problem, not to deliver the solution.
The seven tasks of Identify the Research Questions
The Guide decomposes "Identify the Research Questions" into seven sequential-but-iterative tasks. Each builds the context needed to write a good question.
2.1.1 Define Business Problem or Opportunity. State the problem (or the opportunity) clearly, with the stakeholders who own it. Avoid the jump-to-solution trap. The output is a defined problem that may spawn one or more research questions. Discovery and framing techniques such as Story Mapping are useful here to see the whole landscape before zooming in on a question.
2.1.2 Identify and Understand the Stakeholders. Map who has authority, knowledge, or impact. Stakeholder mapping deliberately surfaces competing views so the eventual question reflects a real consensus rather than the loudest voice in the room.
2.1.3 Assess Current State. Build a baseline: the current process, the data that already exists, and the KPIs in use today. Without a baseline you literally cannot measure improvement — "better" is meaningless without a "from."
2.1.4 Define Future State. Articulate the desired, measurable outcome — what success looks like in numbers, tied to KPIs and success criteria. This is where you set the target the research question will eventually be judged against. Thinking in terms of a desired end state connects naturally to product vision and strategy work, where the future state is framed before tactics.
2.1.5 Formulate Research Questions. The central task — covered in depth below. Questions are derived from business needs, written in plain language, and mapped to analytics types.
2.1.6 Plan Business Data Analytics Approach. Define scope, sequencing, deliverables, and roles. The plan is iterative, not a fixed waterfall — expect to revisit it as questions sharpen.
2.1.7 Select Techniques. Pick the tools that fit. The Guide recommends a specific toolkit for Identify the Research Questions: Business Model Canvas, Concept Modelling, Decision Modelling, Document Analysis, Interviews/Workshops, KPIs, Organisational Modelling, Prioritisation, Process Modelling, and Stakeholder List/Map/Personas. Concept Modelling is especially worth knowing — it organises shared business vocabulary (Customer, Order, Subscription, Plan) so a churn question means the same thing to the CRM and billing teams.
A worked case study (2.1.8) ties these tasks together end-to-end and is a good revision anchor.
Task 2.1.5 in depth: formulating research questions
This is the beating heart of Identify the Research Questions, so it deserves a concrete example. The key move is mapping each question to one of the four analytics types defined in the Guide:
- Descriptive — what happened?
- Diagnostic — why did it happen?
- Predictive — what will happen?
- Prescriptive — what should we do?
A single business need typically fans out into several research questions across these types. The Guide's own pattern: one customer-experience need can spawn about four research questions spanning multiple analytics types.
Worked example: rising customer churn
Suppose the stated business problem (2.1.1) is: "Monthly subscriber churn has climbed from 3% to 5% over two quarters, and leadership wants it back under control." That is a problem statement, not yet a research question. Note what it is not: it is not "build a churn model" — that would be jumping to a solution. After assessing current state (baseline churn, existing retention KPIs) and defining future state (return churn to ≤3% within two quarters), you facilitate the stakeholders toward a set of well-formed questions:
- Descriptive — "Which customer segments, plans, and tenure bands account for the largest share of churned subscribers over the last six months?" (What happened — establishes where churn concentrates.)
- Diagnostic — "Which factors — support-ticket volume, delivery delays, price changes, or feature usage — are most strongly associated with the rise in churn?" (Why it happened — moves from where to why.)
- Predictive — "Given current behaviour, which active subscribers are most likely to churn in the next 60 days?" (What will happen — forward-looking risk.)
- Prescriptive — "Which retention intervention (discount, proactive outreach, plan downgrade offer) would most cost-effectively reduce churn for the highest-risk segment?" (What should we do — the action.)
Notice how each question is specific, points at obtainable data, and carries an implied success measure. The four together form a coherent arc from understanding to action — and only the last one comes anywhere near "build something." The same structure works for declining checkout conversion, falling NPS, or slowing pipeline velocity: state the problem, baseline it, define the target, then fan it into descriptive → diagnostic → predictive → prescriptive questions.
How to validate a research question
A research question is only "done" when it passes validation. Per the Guide, run each candidate question against this checklist:
- Specific — it targets a defined segment, metric, and timeframe, not a vague "why are sales bad?"
- Measurable — the answer can be expressed against a metric or success standard, so you'll know when it's answered.
- Tied to a business need — it traces directly back to the stated problem or opportunity from 2.1.1, not to analyst curiosity.
- Agreed by stakeholders (consensus) — the people with authority and impact have signed off that this is the right question. This is what makes the analyst a facilitator.
- Answerable with available or obtainable data — the data needed either exists or can realistically be sourced. A perfect question with no possible data is a dead end.
If a question fails any line, reshape it — split it into smaller questions, change the unit of analysis, or tighten the metric — until it passes. This reframing loop is itself an expected part of the work, not a sign of failure.
Exam tips and common traps
A few patterns recur on CBDA Identify the Research Questions items:
- Problem vs. solution. When a question stem hands you a requested tool ("management wants a predictive model"), the correct first action is almost always to define the problem with stakeholders, not to build the tool.
- Analyst as facilitator. Answers that have the analyst unilaterally deciding the question or the success criteria are usually wrong. The right answer involves convening, eliciting, and reaching consensus.
- Map questions to analytics types. Be fluent in the four canonical phrasings — what happened / why / what will happen / what should we do — and able to classify a given question instantly.
- Baseline before target. Assess Current State (2.1.3) precedes Define Future State (2.1.4); you cannot quantify improvement without a "from" and a "to."
- Technique fit. Know that Concept Modelling, Stakeholder Map, and KPIs sit in this domain's toolkit — and don't confuse them with downstream techniques like ETL or hypothesis testing, which belong to later domains.
You can pressure-test all of this with scenario-style practice questions on certificate.tips, which is the fastest way to internalise the problem-versus-solution reflex.
Key takeaways
- Identify the Research Questions is ~20% of the exam and sets the target for everything downstream — treat it as the most leverage-rich part of your prep.
- The analyst is a facilitator: define the problem with the right stakeholders before reaching for any solution.
- Walk the seven tasks in order — problem, stakeholders, current state, future state, formulate questions, plan, techniques.
- A good research question is specific, measurable, tied to a business need, consensus-driven, and answerable with data.
- One business need fans into multiple questions across descriptive, diagnostic, predictive, and prescriptive analytics.
Identify the Research Questions rewards discipline over cleverness: the analysts who pass are the ones who resist the jump to solution and frame the right question first. If you're building a study plan around exams like this, certificate.tips has companion prep guides — see How to Pass PSPO I in 30 Days for a structured sibling approach, Story Mapping: The Big Picture Planning for discovery and framing, and Product Vision, Horizons & Strategy for defining a measurable future state.