---
name: business-problem-to-research-question
description: >
  Turns a vague business problem into a rigorous, answerable research question set.
  Use when someone says "we need research into X", "what should we be asking?",
  "help me write the research questions", "the client wants to understand why
  customers are leaving", "turn this brief into objectives", or when a request for
  research has arrived with no decision attached to it. Separates the business
  question from the research question, derives objectives, information needs,
  hypotheses, population and outputs, and kills questions that do not earn their place.
category: 01 Research Strategy and Design
ref: 01.02
tier: 0
inherits: [K2, K3, K4, K5]
---

# Business Problem to Research Question

## 1. One-line description
Converts a business problem into a defensible research question set: the decision, the business question, the research question, its sub-questions, the information needs, the population, any warranted hypotheses, and the outputs that answer it.

## 2. What this skill is used for

**The research problem it solves.** Most research that fails does not fail in the field or in the analysis. It fails where nobody separated the question the business faces from the question the study can answer. The two get written as one sentence, the study is designed against that sentence, and six weeks later the report answers something adjacent to the decision. The symptoms are all downstream: a questionnaire in stakeholder order, findings nobody can act on, a debrief where someone asks "so what do we do?" and the honest answer is that the study was never built to say. This skill forces the separation before any method is chosen, and makes each question defend its place.

**Where it sits in the research lifecycle.** Immediately after the brief has been interrogated (01.01) and before any method, sample or instrument decision. It is the last point at which a project can be redirected cheaply.

**Typical use cases.**
- A stakeholder request arrives as a topic ("we need to understand our lapsed customers") with no decision named.
- A brief carries eleven objectives and a budget that supports three.
- A tracking study is being rebuilt and nobody can say what the questions were for.
- A team disagrees about scope and needs the disagreement made explicit.
- An internal client wants research to support a decision that has already been taken.
- A grant, tender or ethics application requires stated research questions and objectives.

**Who uses it.** Client-side insight managers, agency and consultancy researchers, UX and service designers, policy and evaluation analysts, and postgraduate researchers writing a proposal. Scaffolding for a beginner, and for a research director a structured way to reject work.

## 3. When to use it

- A request for research has arrived and you cannot state, in one sentence, the decision it serves.
- The brief names a topic rather than a question ("brand health", "the customer journey", "Gen Z").
- More questions are on the table than the budget, timeline or respondent attention can carry.
- Stakeholders each have a question and no one has ranked them.
- The question as written contains a causal claim, a forecast, or a hypothetical, and nobody has checked whether it can be answered.
- You are about to choose a method. Do this first, always.
- A study is being repeated and you want to test whether its questions still earn their place.
- Two teams are commissioning overlapping studies and the overlap needs to be made visible.

## 4. When NOT to use it

- **When the decision is already made and research is being commissioned to ratify it.** This skill will surface that, and the correct output is not a question set. It is a short statement naming the decision, the evidence already relied on, and the fact that no answer the study could produce would change the course. Producing a polished question set here launders a foregone conclusion, which is worse than declining.
- **When the real problem is a strategy problem, not an evidence problem.** "Should we enter this market?" is a choice about risk appetite, capability and capital, informed by evidence but not settled by it. Research can size a market, describe unmet needs and test a proposition. It cannot supply the appetite. Say so, and offer the decomposition: which parts of the choice are empirical, and which are the organisation's to make.
- **When the honest answer is that no research is needed.** The answer is already in the organisation's own data, the question has been answered by a study eighteen months old that nobody read, the cost of the research exceeds the value of the decision, or the decision must be made before fieldwork could report. Say this plainly and name which of the four applies.
- **When no brief has been interrogated yet.** If you do not know who asked, why now, what has already been tried and what the constraints are, use **01.01 Research Brief Interrogation** first. This skill takes a clarified problem as input and will produce confident nonsense from an unclarified one.
- **When the question set already exists and is sound**, and what is actually needed is a method. Go to **01.04 Research Method Selection**.
- **When the task is to state and structure hypotheses** for a question set that is already settled. Use **01.03 Hypothesis Development**. This skill produces hypotheses only where the evidence and the decision warrant them, and it does not develop them in depth.
- **When the work is exploratory by design and a fixed question set would be actively harmful.** Early discovery, ethnographic scoping and problem-finding work needs a stated area of enquiry and a stopping rule, not a decomposed question tree. Forcing premature specificity here is a real methodological error, not a discipline. Produce the decision context and the boundary, and stop before decomposition.
- **When the request is for a number the organisation must report** (a regulatory return, an audited metric, a contractual KPI). That is measurement specification, not research question design.

## 5. Required inputs

**Required.**
- **The original request, in the requester's own words.** Not a summary. The wording carries the assumptions.
- **The decision it is meant to serve**, or explicit access to the person who owns that decision. If neither is available, stop and ask. Proceeding without a decision produces a question set that cannot be prioritised, because priority is defined by decision relevance and by nothing else.
- **The constraints that bound scope**: timing, budget order of magnitude, and the date by which an answer is useful. Without these, scoping is guesswork. If unavailable, state the assumed constraint at the point it bites and mark it unverified.

**Optional, and what each one adds.**
- **Previous research on the topic.** Lets you remove questions already answered, which is the fastest way to buy scope back. Without it, you will re-ask something.
- **The organisation's own behavioural or operational data.** Determines which information needs are already met internally, so the study can spend its length on what only respondents can supply.
- **The stakeholder list with what each wants to know.** Lets the kill list be explicit and negotiated rather than silent, which is what makes it survive.
- **The decision timetable.** Converts "urgent" into a testable feasibility constraint.
- **Any commitment already made about the output** (a board paper, a specific deck, a dashboard). Lets outputs be specified backwards from use.
- **Known population definitions in use elsewhere in the business.** Prevents a study defining "customer" differently from the way finance defines it, which is a common and expensive incompatibility.

## 6. Questions to ask before starting

1. **What decision does this research serve, who owns it, and when is it made?**
   Why it matters: it sets priority, scope and deadline simultaneously. Default if unanswered: treat the work as exploratory, say so explicitly in the output, and do not present a prioritised question set as though it were decision-led.

2. **What will you do differently depending on what we find?**
   Why it matters: this is the single test that separates a live question from an interesting one. Default if unanswered: ask it per question rather than for the study as a whole, and mark every question that fails it.

3. **Is any part of this decision already taken?**
   Why it matters: determines whether the exercise is design or ratification. Default: assume open, but check the request's wording for a preferred answer and note it as stakeholder information rather than evidence (K4 §4.2).

4. **Who is the population, and how do you define membership?**
   Why it matters: population definition determines feasibility, cost and what the findings will be permitted to say. Default: adopt the narrowest defensible definition and flag it, because narrowing later is cheap and widening later is not.

5. **What already exists that bears on this?**
   Why it matters: every question already answered elsewhere is length bought back. Default: assume nothing exists, and flag the risk of duplication explicitly.

6. **What does the answer have to fit inside?** Length of interview, number of interviews, budget order, reporting date.
   Why it matters: scope is a physical constraint, not a preference. Default: assume a single conventional study and state that the question set has not been scoped against real capacity.

7. **What would make this research a waste of money?**
   Why it matters: it surfaces the failure the stakeholder actually fears, which is usually more informative than what they say they want. Default: skip; it is a bonus question, not a blocking one.

## 7. Step-by-step methodology

**Step 1. Locate the decision.**
Read the request and write, in one sentence, the decision it serves, in this form: *By [date], [role] must decide whether to [option A] or [option B or C], with [what is at stake].* If you cannot fill every slot from what you were given, you do not yet have a decision. Ask. A correct result is a sentence a stakeholder would recognise and endorse, containing at least two named options and a date. Three failure cases have their own handling. If options are absent, this is a monitoring or curiosity request: legitimate for trackers and horizon work, but say so, because it changes how the set is prioritised (by coverage, not decision relevance). If nobody owns the decision, stop: research with no owner has no consumer. If the decision is already taken, apply Section 4 and do not proceed.

**Step 2. Run the decision-sensitivity test.**
Build a small table before anything else. Rows are the plausible answers to the emerging question. Columns are: what the organisation would do, and what it would cost or save. Fill it out with the decision owner if you can, and alone if you cannot.

| If the answer is... | The organisation would... | Which is different from the other rows because... |

A correct result is a table where at least two rows produce genuinely different actions. If every row leads to the same action, the question is dead, whatever its intellectual interest, and it goes on the kill list at Step 9. This is the test the whole skill turns on, and it is applied again to every sub-question later. Note the common near-miss: rows that differ only in tone ("we would feel more confident") are the same row.

**Step 3. Write the business question.**
One sentence, in the language of the organisation, phrased as the choice: *Should we withdraw, restructure or retain X?* The business question contains the options. It is not answerable by research alone, and that is not a defect. It exists so that everything downstream can be checked against it.

**Step 4. Write the research question.**
This is the separation that the whole skill exists to enforce. The research question is what the study must establish so that the decision owner can choose. It is phrased in the language of evidence, not of action, and it contains no verbs of decision. Test it against three criteria: it is answerable by observing, measuring or listening to somebody; it does not presuppose its own answer; and it would be recognisably answered or not answered by a finished report. Two named things separate it from the business question. Business: *Should we withdraw the scheme?* Research: *Who uses the scheme, what do they use it instead of, and what do they do when it is not available to them?* If your research question still contains "should", it is a business question wearing a coat.

**Step 5. Decompose into sub-questions.**
Break the research question into the smallest set of sub-questions that, answered together, answer it. Aim for three to six. Apply two tests in both directions. Downward sufficiency: if I had complete answers to all of these, could I answer the parent, or is something missing? Upward necessity: if I deleted this one, would the parent still be answerable? Anything failing upward necessity is decoration. A correct result is a set that does not overlap materially, sits at one level of generality, and is phrased as questions rather than topics. "Pricing" is a topic. "At what price does the scheme stop being chosen over the alternatives available to this group?" is a sub-question.

**Step 6. Test every sub-question for answerability, and convert or kill.**
Four classes of question cannot be answered as posed, and they arrive in almost every brief. Screen every sub-question against all four.

*Questions about the future.* "How many will leave next year?" Research measures the present and the recalled past. Convert to a present-tense proxy and state the inferential gap: current stated intention, current behaviour at comparable price points, current substitution behaviour. Never let a forecast question survive unconverted, and never let the converted version be reported as a forecast (K4 §3.3).

*Counterfactual questions.* "What would have happened if we had not launched it?" This requires a comparison that does not exist. Either construct one within the design (a group not exposed, a market not launched in, a period before) and say what it can and cannot license, or convert to a descriptive question and accept the loss.

*Questions about what people would do.* "Would you buy this at this price?" Stated intention is a weak and systematically biased predictor of behaviour, inflated for socially approved actions and for novelty. It is legitimate evidence treated as what it is: a comparative signal between options, not an absolute rate. Convert absolute-rate questions into relative or trade-off forms, or into observation where the design allows, and record the conversion.

*Causal questions with no comparison group.* "Why did satisfaction fall?" and "did the change cause the drop?" require variation to compare against. If the design cannot supply a comparison, the question is answerable only as an account of what people say caused it, which is a different and weaker thing. Rewrite it as such so the report cannot later be read as causal (K4 §3.2).

A correct result is a short table of every converted question, its original wording, its converted wording, and what was lost. That table is a required output, not working notes, because the loss is what stakeholders need to see and agree to.

**Step 7. Derive the information needs.**
For each surviving sub-question, list the specific things that must be measured, observed or understood in order to answer it. This is the layer researchers most often skip, and skipping it is what produces questionnaires that miss the obvious. An information need is concrete enough to argue about: not "attitudes to price" but "the price at which each user's chosen alternative becomes preferable, by user type". For each, name the source that could supply it: respondents, the organisation's own records, published data, or observation. A correct result reveals two useful things immediately. First, information needs that no available source can supply, which sends the sub-question back to Step 6. Second, information needs already met by internal data, which come out of the study and reduce its length.

**Step 8. Define the population and the unit of analysis.**
State who the findings must be about, with inclusion and exclusion rules explicit, and the unit of analysis named (a person, a household, a visit, a claim, a session, a transaction). Then state the coverage risk: who is in the population of interest but hard to reach, and what their absence would do to the answer. Where a sub-question concerns a subgroup, that subgroup's own base becomes a design constraint now, not a discovery at analysis (K3 §3.2). Where the decision depends on comparing two groups, both belong in the population definition. This is where most lapsed-customer studies go wrong, by sampling only lapsed customers and then attempting to say what makes them different.

**Step 9. Kill the questions that do not earn their place.**
Take every question still standing, including the ones stakeholders are attached to, and score each on three things: does it pass the decision-sensitivity test at Step 2; is it answerable after Step 6; and is it already answered elsewhere. Anything failing any of the three goes on a visible kill list, with the reason and the name of whoever asked for it. The kill list is part of the deliverable, because silent removal is why killed questions come back at the debrief. Then scope what remains against real capacity: a survey has a length, a discussion guide has a duration, an analyst has hours. Rank the survivors as **must answer** (the decision cannot be made without it), **should answer** (materially improves the decision), and **could answer** (worth having if it is free). Cut from the bottom until the set fits. A correct result is a set where you can say what was cut and why, and where the must-answer questions alone would still support the decision.

**Step 10. Assemble, state objectives and outputs, and trace upward.**
Write the objectives as the study's commitments, one per surviving sub-question, phrased as what the study will deliver rather than what it will explore. Specify outputs backwards from use: for each objective, the artefact that carries the answer (a sized segmentation, a ranked list of barriers with prevalence, a price sensitivity range with its assumptions). Add hypotheses only where prior evidence or theory makes a directional statement worth testing, phrased so a result could refute them; where there is no prior basis, state none and hand the set to **01.03**. Finally, run the trace in reverse: every output serves an objective, every objective answers a sub-question, every sub-question is necessary to the research question, and the research question serves the decision. Anything that cannot be traced upward is removed. That reverse trace is the quality gate for the whole skill.

## 8. Analytical framework

The structure is a ladder, and every rung must connect to the ones above and below it.

    Decision
      → Business question        (the choice, in the organisation's language)
        → Research question      (what the study must establish)
          → Sub-questions        (the smallest set that answers it)
            → Information needs  (the specific things to be measured or understood)
              → Population and unit of analysis
                → Hypotheses     (only where a prior basis exists)
                  → Outputs      (the artefacts that carry the answers)

Two tests run across the ladder in opposite directions, and both must pass.

**Downward sufficiency.** Read from any rung to the one below and ask: if I had all of this, could I answer the rung above? If not, something is missing at the lower level and the ladder has a gap.

**Upward necessity.** Read from any element upward and ask: what does this serve? If an element cannot name the rung above that it feeds, it is decoration and it is removed at Step 9.

Applying it in practice: build the ladder downward, then walk it upward before presenting it. The downward pass is where the thinking happens. The upward pass is where the scope is won back, because it is the pass that finds the questions that arrived from a stakeholder and attached to nothing.

## 9. Output format

The deliverable is a **Question Architecture** document, in this order.

**1. Decision statement.** One sentence in the Step 1 form, with the decision owner named and the date. Where the decision could not be established, this section says so explicitly and the document is labelled *exploratory, not decision-led* on its first page.

**2. Business question.** One sentence, containing the options.

**3. Research question.** One sentence, in evidence language.

**4. Sub-question table.**

| # | Sub-question | Why the decision needs it | Priority (must / should / could) | Answerable as posed? |

**5. Conversion log.** Every question that was rewritten to make it answerable.

| Original wording | Class (future / counterfactual / hypothetical / causal without comparison) | Converted wording | What was lost |

**6. Information needs table.**

| Sub-question | Information need | Source (respondent / internal data / published / observation) | Already available? |

**7. Population and unit of analysis.** Inclusion rules, exclusion rules, unit, required subgroups with the base each would need, and the coverage risk.

**8. Hypotheses, where warranted.** Statement, prior basis, and what result would refute it. Where none is warranted, the section reads *No hypotheses stated: no prior basis exists for a directional expectation* rather than being filled.

**9. Kill list.** Question, who raised it, and the reason it was cut (fails decision sensitivity / unanswerable / already answered / does not fit capacity).

**10. Objectives and outputs.**

| Objective | Sub-question served | Output artefact | Form the answer will take |

**11. What this study will not answer.** Explicit, and phrased so a reader cannot mistake the study for a broader one.

**When the evidence is thin.** If the decision cannot be established, do not infer one to fill the slot: write *not established* and list what would establish it. If a sub-question has no viable source, it stays in the document marked *no source identified* rather than being quietly dropped, because a stakeholder needs to see that their question has no answer available. Empty sections are stated as empty. Format is not evidence (K4 §1).

## 10. Quality checks

Run before presenting.

1. Can the decision be stated in one sentence with at least two options and a date, or is it explicitly marked as not established?
2. Does the research question contain any decision verb ("should", "must", "ought")? If so it has not been separated from the business question.
3. Does the research question presuppose its answer? Check for embedded causal claims and for loaded nouns ("the barriers to adoption" assumes barriers).
4. Has every sub-question been through all four answerability classes, not just the obvious one?
5. Does every converted question appear in the conversion log with its loss stated?
6. Does every sub-question pass the decision-sensitivity test individually, not just the study as a whole?
7. Could a competent colleague delete any sub-question without the parent question becoming unanswerable? If yes, it should have been cut.
8. Does every information need name a source that actually exists for this project?
9. Does the population definition include every group the decision requires comparing?
10. Does any subgroup question require a base the study cannot deliver? If so it is a design constraint now, not a surprise later.
11. Is the kill list visible, with names and reasons?
12. Does every output trace upward to an objective, a sub-question, the research question and the decision?
13. Is there anything in the document that exists because the format has a slot for it?
14. Does the "what this study will not answer" section actually contain the things stakeholders are most likely to assume it answers?

## 11. Common failure modes

| Failure | How to recognise it | How to prevent it |
|---|---|---|
| **The merged question** | One sentence trying to be both the business question and the research question, usually containing "should" and "why" | Force the two-line split at Steps 3 and 4 before anything else |
| **Topic masquerading as question** | The objective is a noun phrase: "brand health", "the customer journey" | Every item must end in a question mark and be answerable true or false or with a magnitude |
| **The stakeholder wish list** | Eleven objectives, none ranked, all "essential" | Run Step 2 per question and publish the kill list with names attached |
| **The unanswerable survivor** | A forecast or counterfactual question that nobody screened, discovered mid-fieldwork | Step 6 is applied to every sub-question without exception |
| **Presupposition** | "Why do customers find the process difficult?" before difficulty is established | Split into an existence question and an explanation question, and run the second only if the first holds |
| **The missing comparison group** | A study of leavers designed to explain why they left | Step 8: if the decision requires a difference, both groups are in the population |
| **Scope creep by kindness** | Every stakeholder question added because refusing was awkward | The kill list is a deliverable, so the refusal is documented rather than personal |
| **Ratification research** | The requester describes the expected finding before the design exists | Treat the expectation as information about the stakeholder (K4 §4.2), and apply Section 4 |
| **AI: plausible decision invention** | A neat decision statement appears that no stakeholder ever said | The decision comes from a person or it is marked *not established*. Never inferred |
| **AI: over-decomposition** | Fourteen tidy, symmetrical, MECE-looking sub-questions that no study could carry | Cap at six, apply upward necessity, and cut against real capacity at Step 9 |
| **AI: fluent unanswerability** | A well-phrased research question that no method could answer, because fluency was optimised over feasibility | Every sub-question must reach Step 7 with at least one real source named |
| **AI: hypothesis filling** | Hypotheses generated for every sub-question because the template has a section | Hypotheses require a prior basis. The absence of one is stated, not filled |
| **The unstated population** | Findings reported about "customers" when the sample was one segment | Population and unit are written before the method is chosen, not after |

## 12. AI guardrails

Skill-specific. The universal prohibitions in K4 apply in full and are not repeated here.

1. **Never invent a decision.** If no decision owner has stated one, the output says *decision not established* and lists what would establish it. A confident, plausible decision statement that nobody said is the highest-damage failure available in this skill, because everything downstream is then optimised for a fiction.
2. **Never convert a question and hide the conversion.** Any rewrite of an unanswerable question appears in the conversion log with what was lost. See K2 §7 on acts that break the chain.
3. **Never present a converted forecast, counterfactual or intention question as though it retained its original meaning.** The converted question answers something narrower, and the output says what.
4. **Never let a question survive because a stakeholder is senior.** Seniority is not decision relevance. If it fails Step 2 it goes on the kill list with the name attached, and the decision to reinstate it belongs to a human.
5. **Never state a hypothesis without naming its prior basis.** A directional expectation with no evidence or theory behind it is a guess, and at this stage it will bias the instrument that follows.
6. **Never write a population definition to fit an assumed sample source.** Define who the findings must be about, then let feasibility be tested against it openly. Feasibility-led population definitions produce studies that answer for whoever was easy to reach.
7. **Never promise answerability without a source.** A sub-question with no identified source is marked as such, not carried forward on the assumption that the method stage will solve it.
8. **Never suppress the finding that no research is needed.** If the answer already exists internally, or the decision date precedes any possible fieldwork, that is the output. Producing a question set anyway is the research equivalent of manufacturing evidence.

**Human review points** (see K5 §2 for the classes):
- **Researcher decision required** on the kill list before any design work proceeds. Class 2.1, business relevance and materiality: whether a question is worth the study's capacity depends on organisational knowledge the AI does not have.
- **Researcher decision required** where the decision cannot be established and the choice is between proceeding as exploratory and stopping. Class 2.7.
- **Researcher sign-off required** on the population definition, because it fixes what the study will be permitted to claim about whom. Class 2.3.

## 13. Best-practice principles

1. **The decision comes first, and everything is priced against it.** Question priority has exactly one basis: how much the decision changes depending on the answer. Interest, novelty and stakeholder enthusiasm are not bases.
2. **"Why" questions are the most expensive sentences in research.** They are cheap to write, they presuppose the thing exists, and they usually require a comparison the design does not have. Always split: does it happen, to whom, how much, and only then why.
3. **A question set is a budget.** Every question added takes length, attention and analysis time from another. Treat additions as trades, and say what is being traded.
4. **Kill visibly.** A question removed silently returns at the debrief with more force than it had originally. The kill list, with names and reasons, is what makes scope hold under pressure.
5. **Write the population before the method.** Method-first thinking quietly redefines the population as whoever the method can reach, and the redefinition is invisible in the final report.
6. **Where the decision is comparative, the design must be comparative.** If the question is what makes leavers different, stayers are in the sample. This single principle prevents a large share of unusable studies.
7. **Stated intention is a comparative instrument, not an absolute one.** It ranks options usefully and predicts rates badly. Design questions to exploit the first property and never rely on the second.
8. **The best scope reduction is somebody else's data.** Before adding a question, check whether the organisation already knows the answer operationally. This buys more length than any wording economy.
9. **Ambiguity at this stage is cheap, and at every later stage it is expensive.** An hour spent on the difference between "awareness" and "consideration" here saves a rebuild of the questionnaire and an argument at the debrief.
10. **Name what the study will not answer, in writing, at the start.** A study is judged against what the audience assumed it would cover. Setting that expectation is a design act, not an act of modesty.
11. **Do not require a hypothesis where none is warranted.** Hypotheses are valuable where prior evidence gives a direction, and harmful where they encode a stakeholder's hunch into an instrument.
12. **If the exercise reveals the research is unnecessary, that is a successful use of the skill.** The most valuable output this skill can produce is a short document saying the money should not be spent, and why.

## 14. Worked example

Fictional scenario, public sector. All figures are illustrative and belong to the scenario.

    INPUT
    A request from the commercial team at a city transport authority:
    "We need research into why people are abandoning the discounted
    monthly travel card. Everyone has a theory. Can we get a survey out?"

**Process.**

*Step 1, locate the decision.* The request has no decision in it. Asking who would act on the answer produced one: the finance committee must decide, before the March budget, whether to retain the discounted card unchanged, restructure it (change the discount level or eligibility) or withdraw it. The illustrative subsidy at stake is stated by the authority as a fixed annual sum. Written in form: *By March, the finance committee must decide whether to retain, restructure or withdraw the discounted monthly card, with the annual subsidy at stake.* Two options and a date, so the exercise proceeds.

*Step 2, decision sensitivity.* If most card users would keep travelling at the same frequency without the discount, the subsidy is buying little and withdrawal becomes live. If a substantial group would reduce or stop travelling, restructuring around that group becomes live. If the card is mainly held by people who would travel anyway but is also the authority's main channel for reaching a low-income group, withdrawal has a distributional cost that changes the choice. Three rows, three different actions. The question is live.

*Steps 3 and 4, the separation.* Business question: *Should the authority retain, restructure or withdraw the discounted card?* Research question: *Who holds the card, what does it displace in their travel choices, and what do they do when the discount is not available to them?* Note what fell away: "why are people abandoning it" presupposed abandonment as the phenomenon, and the request never established it. Abandonment became a sub-question rather than the frame.

*Step 6, answerability, and the judgement call.* Six sub-questions survived decomposition. Two failed screening. "How many will leave if we raise the price 15%?" is a forecast: converted to current behaviour at existing price tiers plus a trade-off exercise between the card and its real alternatives, with the inferential gap stated. "Why did card holdings fall last year?" is causal with no comparison: the administrative record showed the fall coincided with an eligibility change and a fare rise, and nothing in a survey of holders could separate them. The judgement call was whether to drop it or build the comparison. Resolved by widening the population: the study would include people who dropped the card, people who kept it, and eligible non-holders, which makes a comparison possible on the eligibility change specifically, though not on the fare rise. What that cannot license was written into the conversion log.

*Step 9, killing.* Three stakeholder questions were cut and listed with names: satisfaction with station cleanliness (fails decision sensitivity, nothing in the March decision turns on it), awareness of the card among the general public (already answered by a study eleven months old), and preferred payment method (already in the authority's own transaction data).

    OUTPUT
    A Question Architecture document: one decision statement, one business
    question, one research question, four sub-questions ranked must/should/could,
    a two-row conversion log with the losses stated, an information needs table
    naming respondent and internal-data sources, a population covering three
    groups with the base each subgroup would require, no hypotheses (no prior
    basis for a direction), a three-item kill list, and a section stating that
    the study will not establish the effect of the fare rise.

## 15. Advanced usage

**Multi-decision briefs.** Where a request serves two decisions with different owners and different dates, do not merge them. Build the ladder twice and compare the two information-need tables. The overlap is what one study can carry; the remainder is a second study or a deferred one. Merging produces a study that is late for one decision and thin for the other.

**Tracking studies.** The decision-sensitivity test applies awkwardly to trackers, because their value is partly in continuity. Apply a modified test: what change in this measure would trigger an action, and by whom? Any tracked measure with no trigger and no owner is a candidate for removal, and trackers accumulate these steadily. Running this skill over an inherited tracker typically recovers a third of its length.

**Reverse-engineering an existing study.** Take a finished questionnaire or discussion guide and rebuild the ladder upward from it. Every item that cannot name a sub-question is unexplained, and the pattern of unexplained items tells you how the instrument was assembled. This is the fastest available diagnostic on an inherited study.

**When the stakeholder will not name a decision.** Sometimes because none exists, sometimes because naming it is politically costly. Distinguish them by asking what happens if the research is delayed six months. Genuine decisions have consequences for delay. If the answer is that nothing much happens, the work is exploratory and should be resourced and framed as such.

**Combining with 01.07.** Draft the analysis plan against the question set before fieldwork. Questions whose analysis cannot be specified in advance are usually questions that were never properly formed, and the analysis plan is where that surfaces.

## 16. Skill chain

**Recommended previous skills**
- **01.01 Research Brief Interrogation.** Hands over the clarified problem, the stakeholder map, the unstated assumptions and the scope boundary. Without it, this skill is working from the request's own framing.

**Recommended next skills**
- **01.03 Hypothesis Development.** Receives the sub-questions and the information needs, and develops testable hypotheses where a prior basis exists.
- **01.04 Research Method Selection.** Receives the question set, the population and the information needs, and selects the design capable of delivering them. The question set is its required input, which is why it runs second.

**Runs well alongside**
- **01.06 Sampling Strategy**, which inherits the population definition and the subgroup base requirements set at Step 8.
- **01.07 Analysis Plan Development**, which tests whether each question can actually be analysed as specified.
- **13.01 Research Quality Review**, run against the finished question architecture before design begins.

---
A Yazi Supplied Skill and resource.