The Demo Is the Stakeholder Strategy

Every data programme I am asked to shape begins with the same artefact: a map of everything that could be done, filed by function and printed on one page so nobody's idea is missing. The map is the easy part. What follows it is the whole job, and almost nobody writes down the rule they use.

A proposal I co-signed for a European food and consumer goods manufacturer writes it down in the first paragraph, before any method appears. Explore the challenges, understand the bigger picture, and choose one to three areas where an initial breakthrough case with concrete results can be delivered in a relatively short time frame. Then the reason, in the same letter: real-life examples based on concrete cases are an important instrument to show what is possible and to create enthusiasm with stakeholders.

Read quickly, that is scoping advice. Read as written, it is a claim about how organisations behave. The first thing you build is not a technical milestone on the way to a platform. It is the object that has to survive the first budget conversation, and the letter says so out loud.

The map was never meant to be the plan

The opportunity page is well built. Fourteen numbered candidates arranged against four groups of executive owner: the commercial and finance seats, operations, IT, and marketing. The axis is the useful part, because filing an idea under the executive whose numbers it moves forces the question of whose result changes before the question of what gets built.

Underneath the whole panel sits a footnote in small type: illustrative, subject to change after the workshop discussions.

That footnote is honest and it is usually ignored. A map like this is a conversation opener. Its job is to get every function to see its own name on the page and then agree to stop looking at the page. If it survives into delivery as a portfolio, the programme has already lost, because fourteen half-cases produce fourteen partial answers and no single result anybody outside the team can repeat.

What the first build is for

The letter is unusually direct about this. Concrete examples are an instrument, used to show what is possible and to create enthusiasm with stakeholders. Not to validate an architecture. Not to benchmark a model. To move people.

I have watched enough first pilots to think that is the correct reading of the physics. A steering group cannot evaluate a model. It can evaluate whether the number on the screen is one it argues about every month, whether that number came off its own data, and whether the presenter had to work through a string of caveats before reaching it. That evaluation decides the next budget line.

So the criteria that produce a good demonstration are not the criteria that produce a good engineering pilot. An engineering shortlist ranks candidates by data availability, label quality, tractability, and how cleanly the result would deploy. A stakeholder shortlist ranks them by whether one named executive owns the outcome, whether that executive can clear the access the work needs, and whether the result is legible to somebody who was not in the room.

Those two lists rarely agree. The most tractable case in an estate is frequently owned by nobody senior, which is exactly why its data was never contested and therefore never messy.

The shape of a case that persuades

The worked example carried through the proposal is instructive in its shape rather than its subject. It starts from one business question about allocating spend across online marketing channels, then names three themes: search, social, and mobile. Each theme carries exactly one falsifiable statement, of the form that investing in search generates higher conversion, or that social engagement produces higher loyalty. Those statements run against a customer funnel the marketing organisation already used.

Four properties are worth copying. One question, not a capability. Few enough themes that the answer has structure. One statement per theme that can come back false, which makes the result an argument rather than a display. And an outcome expressed in a measure the audience already tracked before anyone arrived. Teams skip the last one, and a result reported in a metric invented for the pilot compares to nothing, so it moves no budget however good the modelling was.

The four to six weeks nobody can see

The delivery band is printed as one week, then four to six weeks, then one week. Framing at the front, the data and analysis grind in the middle, the benefit conversation at the end. Six to eight weeks in total, against a footnote that typical cases run four to eight weeks for established data analytics environments, with the conditional carrying more weight than the range.

Look at that shape from the sponsor's chair rather than the delivery lead's. Week one is visible: workshops, hypotheses, people in a room. The final week is visible: a result and a conversation about what it is worth. The weeks between produce nothing anybody outside the team can inspect, while data gets located, cleaned, joined and argued with, and hypotheses get rewritten because the first versions were untestable.

That gap is where sponsorship goes quiet, and quiet sponsorship is how a first case arrives to an audience that has stopped expecting anything. The proposal names absent senior sponsorship as a failure mode of the earliest stage, which I read as the same observation from the other end. If the demonstration is the stakeholder strategy, the middle weeks need a plan of their own: a standing checkpoint that shows working rather than results, and an owner on the client side whose job is to keep the room warm while nothing is presentable. On RealAI's Consult engagements that checkpoint goes on the calendar before the data work starts rather than when the room goes quiet, because a sponsor who has watched one messy week of joining and arguing will sit through three more, and one who has only had a delivery date confirmed will not.

A first build a technical reviewer admires and a budget holder cannot repeat in one sentence has failed at the only job the document ever gave it.

The price is part of the argument

The commercial page says the same thing in another language. A scoping session at 5,000 euros one time, excluding travel and stay, waived in full if the client goes on to a paid option. Then one working case, quoted on 1.3 full-time equivalents at 10,000 euros a week over roughly eight weeks. Then the same case with a supplier-provided analytics environment attached, at 2.1 full-time equivalents and 12,500 euros a week, platform and licensing free for the initial trial. All of it an offer rather than a record of what was delivered.

Two things there are about stakeholders rather than economics. Pricing the front door and then waiving it turns a giveaway into a visible concession, a different conversation inside a procurement review. And the rungs are sized so the first commitment clears one budget holder without a board paper, on a fractional team rather than a squad, because a demonstration built by a squad implies a squad forever and the executive doing that arithmetic during the readout knows it.

14

Candidates on the map, marked illustrative

1 to 3

Areas the letter asks the client to narrow to

1 wk / 4-6 wk / 1 wk

Framing, the invisible middle, the readout

5,000 euros

Scoping session, waived if a paid option follows

A different shortlist comes out

Put the two tests side by side on your own backlog and the overlap is thin.

The tractability test asks where the data is clean, where the labels exist, where a pipeline would deploy without a platform argument. The survival test asks five other things. Does one named executive own the number this moves. Can that executive clear the platform decision and the security approvals, both of which the proposal assigns overwhelmingly to the client side. Is the result expressed in a measure that already appears in a monthly pack. Would the case clear a bar of roughly five times the effort it consumes, counting the client's effort honestly. And can it finish inside eight weeks, because a demonstration landing after the planning cycle it was meant to influence is one nobody needed.

The document supplies a sixth by accident. In the effort table, the row covering engagement with stakeholders to define insights and make key issues visible carries a split that does not add up to a hundred. I flag that rather than repair it, because the row that fails to balance is the stakeholder row, and that is the work most often assumed to belong to somebody else.

What I would carry forward

The modelling end has never been cheaper. Pipelines are assembly work, deployment is close to routine in most stacks, and the careful language model pilots crossing my desk stand up in days rather than quarters. What has not moved is the number of first cases that die between a working result and a second release, and the reason sits upstream of all of it. The case was chosen by people weighing technical odds, then handed to a room weighing whether anything changes on its own scorecard.

Narrow the map twice. Choose the one case on the survival test, run the tractability test second as a veto rather than a ranking, and plan the invisible weeks as carefully as the visible ones. The build is not the point of the build.

Drawn from a data innovation proposal I co-signed for a European food and consumer goods manufacturer: its cover letter, opportunity map, worked example, example effort plan and priced options. It is a pre-sales document, so the durations, splits and prices in it are an offer rather than a record of delivered results. Reading the first case as a stakeholder instrument rather than a technical milestone is mine.