Why this page exists
What if Ben hadn't answered?
He did answer. He named what worried him, and when I pushed, he turned it into something we could check. That's the version in Chapter 1, and it's the version you'd want.
Plenty of rooms don't go that way. You ask the question and nothing comes back. Somebody studies the table, somebody else says it's a good question, and the silence gets long. Then the CEO says the team should get started and work it out as they go.
That's the meeting this page is for. It's the fallback: what to prepare, what to bring, and how to hold your position when the room can't do the thing you've just asked it to do.
What an artifact is here
Two things at once. It's what the team produced — the drivers, the vision, the acceptance criteria — and it's the facilitation that produced it: the questions asked, the move that unstuck the room, the prompt used when nothing came.
The first half is interesting. The second half is what you can use on Monday. That's why every artifact page carries both, and why all of it is yours to copy.
Why this one comes first
You've just read Chapter 1. This is the preparation for the meeting in it, and that meeting matters more than any other in the project.
Drivers are the platform everything else stands on. The vision has to serve them. The goal has to be a chunk of that vision. Capability areas, Epics, stories and criteria each answer the question above them, all the way down to finished code. Get the drivers wrong and every stage below inherits the error, politely, for about eighteen months.
It's also the one stage where the answer can't come from you. A vision can be drafted and corrected. A backlog can be reordered. But a driver the room never said out loud isn't a driver. It's your opinion with a number attached.
And something else is at stake in that room.
It's usually the first time the people paying for this watch you do anything. What they decide about you in that hour is roughly what they'll think for the rest of the project.
Run it as a note-taker and you become the person who books the meetings. Run it as somebody who turns a vague pressure into an outcome an executive will put their name to, and something else happens. They start bringing you in before decisions, not after.
That's the difference between a Scrum Master and a meeting organiser, and it gets decided early.
What's on this page
Everything you need to walk in prepared. The homework to do first. A research prompt for understanding how the client got here. The driver discovery prompt. What a qualifying question has to do to be worth asking. And how to run the session, with a worked example showing what the prompt produces for Beauty Spot and what the room would have done with it.
This is stage one of seven. There's an artifact like this for each of the others.
Ask first. Always ask first.
This is a fallback. It is not an opening move, and using it as one is the most common way to get this wrong.
Ask the open question. Ask the Product Owner beforehand what he already knows — he has usually been in rooms you haven't. Ask what the board has been worrying about, what the last strategy day produced, what keeps coming up in leadership meetings.
Then sit in the silence and let it be uncomfortable. Sometimes the answer arrives at second forty.
You don't know what a stakeholder has until you ask, and most have more than they can get out in the first thirty seconds. Open with a generated list and you'll never find out what they had — you'll have anchored them to somebody else's thinking, and they'll edit rather than originate.
Only when it's clear the room genuinely cannot produce drivers — not that it's slow, that it can't — do you open the folder.
A side effect worth knowing about.
Having the list prepared makes you a calmer facilitator. A Scrum Master with no fallback fills the silence at about twenty seconds, because it's unbearable and he'd rather be seen doing something. A Scrum Master with a prepared list can wait a full minute without panicking — and in that extra forty seconds, the room quite often answers on its own.
The list frequently does its job without ever leaving the folder.
Before any of this: do the homework
This is the part that separates a Scrum Master who facilitates a driver session from one who understands what he is hearing. It takes an evening, and it pays for itself in the first ten minutes of the first workshop.
Two kinds of homework, and you want both.
One — the industry, local and global
Where is this sector going, and how fast? What is happening globally that hasn't reached this market yet, and what is happening locally that the global picture would miss? Trade association reports, analyst notes, published figures from listed competitors, the trade press nobody outside the industry reads.
You are looking for trajectory, not facts. A sector that grew four per cent for a decade and then fell twice in eighteen months is telling you something no stakeholder in that room will say out loud, because they are inside it.
Two — this client's last five years
How did they arrive at the state they are in? Not the strategy deck — the actual path. Three lenses:
- Market — share won or lost, segments entered or quietly exited, price positioning that moved.
- Business — mergers, acquisitions, divestments, a product line discontinued, a partnership that ended.
- Organisation — restructures, a leadership change, a function brought in-house or outsourced, headcount that moved in one direction for three years.
Annual reports if they are public. Trade press if they are not. Press releases, which tell you what they wanted people to think. And the shape of their leadership team over time, which tells you what actually happened.
Why this matters more than it sounds.
It lets you read between the lines — of a model's output, and of what people say in the room.
When a CFO goes quiet at the mention of a new channel, and you know they acquired a competitor in 2022 and wrote it down eighteen months later, you are hearing something different from a colleague who thinks she is being obstructive. When a CMO insists on speed, and you know the market leader launched an app two years ago, his urgency stops being a personality trait and becomes information.
Stakeholder behaviour is almost always rational once you know the history. Most of the time nobody has told you the history, and nobody will, because to them it is simply the water they swim in.
The research prompt
This is what fills the external evidence field in the driver prompt below. Run it first.
I am the Scrum Master on a new product engagement and I am preparing for a business driver session. I need to understand the ground before I walk into the room. THE CLIENT Organisation: [name, or a description if you would rather not name them] Sector: [be specific — not "retail" but "specialist beauty retail, physical-first"] Markets: [local and any international presence] Size: [headcount, sites, turnover if known] PART ONE — THE SECTOR Where is this sector going, and how fast? Cover both: LOCAL — what is happening in their specific market that a global view would miss. Regulation, consumer behaviour, channel shifts, a dominant local player. GLOBAL — what is happening elsewhere that has not reached this market yet. Say roughly how far behind or ahead this market is, and on what evidence. For each trend, state: the direction and rough rate of change what it means for a business of this size and shape what a business in this sector typically gets wrong about it Distinguish clearly between trends that are well evidenced and trends that are widely asserted but thinly supported. Say which is which. PART TWO — HOW THIS CLIENT ARRIVED HERE Their last five years, through three lenses: MARKET — share won or lost, segments entered or exited, price positioning that moved. BUSINESS — mergers, acquisitions, divestments, product lines discontinued, partnerships started or ended. ORGANISATION — restructures, leadership changes, functions brought in-house or outsourced, sustained headcount movement. Where you do not know, say so plainly and tell me where I would look — an annual report, a specific trade publication, a registry. Do not fill gaps with plausible invention. PART THREE — WHAT THIS TELLS ME ABOUT THE ROOM This is what I actually need. Given the above, what pressures are the people in that room most likely carrying that they will not state? For each, name: which role is most likely to feel it what it would sound like when they raise it obliquely what would make them defensive about it I am not trying to manipulate anybody. I am trying to understand why a reasonable person might react in a way that looks unreasonable to somebody who does not know the history. CONSTRAINTS Cite what is checkable. Flag what is inference. Do not speculate about named individuals. If the honest answer to any section is "I do not have reliable information", say that instead of guessing.
One thing to be careful with.
None of this makes you the expert in the room. You will be sitting with people who have spent twenty years in that industry, and a briefing does not change that.
What it buys you is the ability to ask a better second question, and to hear what is underneath the first answer. Use it for that. A Scrum Master who arrives quoting sector statistics at a CEO has misunderstood the job rather thoroughly.
Why a wrong list beats a blank page
Most stakeholders have a strategy. Few have ever been asked to state it as an outcome you could check a year later. They know the pressures. Turning a pressure into “we'll know this worked when e-commerce turnover rises fifteen per cent” is a translation exercise, and almost nobody performs it for the first time in front of an audience.
So you arrive with candidates, deliberately imperfect, and let the room correct them. People are far better at correcting a wrong list than producing a right one from nothing. “No, that's not it, ours is more about —” takes four seconds. “What are your business drivers?” can take ten minutes of silence.
The trap, and it's a real one.
A stakeholder handed a plausible list will sometimes just take it. Now you've got five professional-sounding drivers that belong to nobody, which is worse than having none. They look finished. Nobody will question them for a year.
The generated list isn't an answer. It's bait.
And if you do have to show the list — get it said out loud.
Reading a candidate to the room is not the same as the room agreeing to it. Put it up, then wait for somebody to restate it in their own words, and for at least one other person to push back or add to it. Only then is it theirs.
Because if it stays in your wording, you will be quoted as the author of it — and the first time it is questioned, everyone will look at you rather than at the person accountable for the outcome. That is a bad place for a Scrum Master to be standing, and it is entirely avoidable.
The prompt
Paste it into any capable model and fill the bracketed fields. The amber parts are the ones you replace.
I am the Scrum Master, preparing a business driver discovery session. I am NOT looking for the answer — the answer has to come from the room, in their words, or they will not own it. Give me candidates for them to argue with. CONTEXT Industry: [e.g. specialist beauty retail, ~40 stores, Nordics] Business model: [e.g. physical retail plus small e-commerce] What the room said: [the pressures they named, in their words] Who is in the room: [e.g. CEO, CMO, Head of Retail Operations] EXTERNAL EVIDENCE [Paste or summarise sector reports, trade association data, analyst notes, published figures from listed competitors. This is the most important field. Without it you will only get back a tidier version of what the room already told you.] PRODUCE Six candidate business drivers for this organisation. Six, not five — the list should be slightly too long, so the room has to reject at least one. For each candidate: 1. DRIVER — one line, an outcome the business wants, not a feature and not an activity. 2. SUCCESS OUTCOME — how they would know in twelve months that it moved. Something observable. Include a plausible figure so the room has something concrete to disagree with. 3. QUALIFYING QUESTIONS — exactly three, and they must meet every one of these rules: - Not answerable yes or no. - Not answerable from memory in the room. Each one should require looking something up, asking a colleague, or checking a number nobody has to hand. - Each must force a choice or a comparison, not a description. - At least one must be capable of DISQUALIFYING the driver. If every question can only confirm it, the set is worthless. 4. WHY THIS MIGHT NOT BE THEIRS — one sentence naming the kind of organisation this driver would be wrong for. Give the room permission to reject it. SEPARATELY, PRODUCE A SECOND LIST Any pressure named by the room, or visible in the evidence, that is a BLOCKER rather than a driver. A driver is a long-term outcome worth investing in. It survives a change of quarter. A blocker is something in the way right now — a broken process, a contract, a system nobody can replace this year, a team that cannot hire. Real, painful, and almost never fixed by building software. For each blocker, say in one line what kind of intervention it actually needs, and be willing to say "not a software problem". Also flag, explicitly: any pressure the room named that the external evidence suggests is a SYMPTOM of something structural they have not mentioned. Name the structural thing. This is the most valuable output of this prompt and the one the room is least able to produce, because they are inside it. CONSTRAINTS Do not rank the candidates. Do not recommend one. Do not use the word "leverage". The people reading these will be sceptical executives who resent anything that sounds like a template. Write for them.
What it produced for Beauty Spot
Ben answered the open question, so this never left the folder. But if he hadn't — this is what I'd have put on the table.
What the room would have done with it. Five of those are close to what Ben produced on his own. That is not a triumph — a model trained on retail will land near the obvious drivers for retail, which is exactly why the list is bait and not an answer.
The sixth is the useful one. Reduce cost of store operations is a real pressure at Beauty Spot and it is a blocker, not a driver — no app fixes it, and treating it as a driver would have sent a team building a staff scheduling tool nobody asked for. Rejecting it out loud is what tells you the room can tell the difference.
And note what none of these have: the specific thing. Ben's actual driver was sharper than any of them, because he knew which competitor, in which segment, since when.
What a good qualifying question looks like
The questions matter more than the drivers. The drivers get rewritten in the room; the questions are what send somebody away to find something out.
Take a candidate driver: enhance competitive positioning and market share.
Is market share important to you?— yes, and it costs nothing.
How would you describe your position?— a description, not a choice.
Which competitor took business from you last year, and what did they offer that you didn't?
If you could take back one segment of customers you have lost, which one — and what makes that segment worth more than the others?
Is your problem that customers choose a competitor, or that they stop buying the category altogether? What in your data tells you which?
None of the strong ones can be answered from a chair. Each forces a choice between two things the stakeholder cares about. And the third can disqualify the driver entirely — if the answer is category decline, this is not a market share problem.
That disqualifying capability is the part people leave out. A set of questions that can only confirm a driver is a set of questions that proves nothing.
Running the session
Before
Ask the Product Owner what he already knows. Ask whether there was a strategy day, a board paper, an away-day output. Often there is something, and it's better than anything you'd generate.
Then, and only as insurance, generate the candidates. Read them yourself and delete any you'd be embarrassed to defend. Bring six at most, in a folder you don't open unless you need to.
In the room
Ask the open question. Wait. Wait longer than is comfortable.
If drivers come, put this away and never mention it. That's the good outcome, and it's more common than you'd expect.
If they don't: present the candidates as a first draft that is probably wrong, and say so plainly. Nothing kills this faster than presenting a generated list as research. Expect to reject at least one and rewrite at least two. If the room accepts all six unchanged, stop — that's the trap closing, and it means they're being polite rather than engaged.
After
The qualifying questions go home with the stakeholders. Give them a deadline and a next session.
This is the part that does the work. A CMO who spends two days establishing that acquisition cost is the real pressure — and that market share was a symptom of it — owns that driver in a way no workshop agreement can manufacture.
Then throw the generated list away. Keep only what the room wrote.
Limits
Three or four questions per driver. No more. More becomes homework, homework gets delegated to somebody junior, and then you have drivers owned by an analyst instead of an executive. Which is where you started, with an extra week gone.
A model knows what drivers usually look like in an industry. It knows nothing about this business — not the acquisition that went badly, not the board member who blocks anything touching pricing, not the fact that the CEO already tried this in 2019.
Everything that makes a driver true is in the room. This exists to get the room talking, and that is all it is for.
The same pattern elsewhere
Wrong-list-first works anywhere a group has to produce something from a blank page. There are companion tools for vision, Product Goal, capability areas and Epic slicing.
The rule is the same every time. Generate to provoke, never to decide, and attach questions somebody has to leave the room to answer.