# D2 · Strategy and Roadmap Connecting AI to stated business priorities, sequencing prove-scale-embed, choosing platform vs point solutions, deciding build-buy-partner, funding models, and what an initial AI strategy draft contains. import { Accordions, AccordionItem, Tabs, TabItem } from '@prosefly/astro-components'; This domain carries **18%** of the mock — roughly **9 of 50 items**. It tests whether you can turn a pile of opportunities into a coherent, sequenced plan that a board recognises as *strategy* rather than a list of pilots. The Academy **AI Leadership** course names "create an initial AI strategy draft" as an explicit objective, so this domain is where the course's headline deliverable lives. The skills are connecting AI to *stated* priorities, sequencing prove → scale → embed, choosing between platform and point solutions, deciding build-buy-partner, and picking a funding model that survives contact with finance. ## What you need to know A strategy is not a technology plan; it is a statement of how AI advances priorities the business already agreed. Start from the stated priorities (growth, cost, risk, experience) and trace each AI initiative back to one of them — anything that traces to nothing gets cut. Sequence the portfolio through three phases: **prove** (a few high-signal pilots with baselines), **scale** (the winners, industrialised with governance and support), and **embed** (AI becomes the default way the work is done). Decide platform vs point solutions and build-buy-partner deliberately rather than by accident of who sold first. Choose a funding model — central fund, chargeback, or blended — that matches your operating model. The output is an *initial AI strategy draft*: short, specific, and owned. ## Learning objectives By the end of this page you should be able to: 1. **Trace** every AI initiative to a stated business priority and cut those that trace to none. 2. **Sequence** a portfolio through prove → scale → embed with the right gate at each transition. 3. **Choose** between a platform approach and point solutions for a given estate. 4. **Decide** build vs buy vs partner using capability, differentiation and time-to-value. 5. **Select** a funding model (central, chargeback, blended) that fits the operating model. 6. **Draft** the sections of an initial AI strategy a steering group can approve. --- ## 2.1 Strategy starts from stated priorities The fastest way to lose a board is to present AI as its own goal. AI is a means; the ends are the priorities the organisation already published — usually a small set like *grow revenue, reduce cost, manage risk, improve experience*. Every initiative must trace to one, in one line. | Stated priority | AI initiative that serves it | Trace line | | --- | --- | --- | | Reduce cost-to-serve | Support draft-reply assist | Cuts handle time on 60% of tickets | | Grow mid-market revenue | Proposal personalisation | Shortens cycle, lifts win rate | | Manage regulatory risk | First-pass policy review | Catches gaps before filing, human signs off | | Improve employee experience | Internal knowledge assistant | Cuts time-to-answer for staff | An initiative with no trace line is not strategic — it is a hobby. Cutting it is the strategy working. :::tip[Assessment signal] Stems mentioning **"align to business priorities", "the board asked how this ties to growth/cost", "why are we doing this"** are testing traceability. The correct answer connects the initiative to a stated priority; distractors justify it by technology, competitor fear or sunk cost. ::: ## 2.2 The prove → scale → embed sequence A roadmap has phases, and each phase has a different job, a different risk and a different gate. Confusing them — scaling before proving, or piloting forever — is the most common roadmap failure. ```text PROVE ───────────► SCALE ───────────► EMBED (weeks–months) (quarters) (ongoing) few pilots winners only default way of working strong baselines governance + measured, owned by the clear kill gates support + change business, not the AI team learn fast industrialise AI team moves to next wave gate: proven gate: repeatable gate: adoption + value benefit, safe at cost, adopted sustained without heroics ``` Two disciplines matter most. At the **prove → scale** gate, you scale only what showed a real, baselined benefit and a safe operating design — not what was merely popular. At the **scale → embed** transition, ownership moves from the central AI team to the business, or the value evaporates when the team's attention moves on. ## 2.3 Platform vs point solutions A **point solution** solves one problem well and is bought or built for that problem. A **platform** provides shared capability (models, controls, connectors, identity) that many use cases sit on. Most organisations end up with both; the decision is what to standardise. | Dimension | Point solution | Platform approach | | --- | --- | --- | | Time-to-first-value | Fast | Slower to stand up | | Governance | Fragmented, per-tool | Centralised (SSO, RBAC, logging once) | | Cost at scale | Rises with tool sprawl | Amortised across use cases | | Best for | A single high-value niche need | Many overlapping needs, enterprise controls | | Risk | Shadow-tool sprawl, duplicate spend | Over-building before demand is proven | The pragmatic pattern for a larger enterprise is a **thin platform, thick use cases**: standardise identity, controls and a governed model surface (for example ChatGPT Business/Enterprise with SSO, SCIM and compliance logging — see [D3](/openai/leadership/domains/d3-governance-and-risk/)), then let functions build point value on top rather than each buying a walled tool. ## 2.4 Build vs buy vs partner For each capability, decide who provides it. The axes that decide it are **differentiation** (does this make us distinct?), **capability** (can we build and run it?) and **time-to-value**. | Option | Choose when | Watch out for | | --- | --- | --- | | **Buy** (SaaS/product) | Commodity capability, fast value, no edge from owning it | Lock-in, data egress, integration limits | | **Build** | It is genuinely differentiating and you can run it | Under-estimating run and maintenance cost | | **Partner** | You need capability and skills you lack, on a shared bet | Unclear IP ownership, dependency risk | The default for most generative-AI value is **buy the foundation, build the thin differentiating layer**: use a governed model provider and product surface, and invest engineering only where a workflow, dataset or integration is genuinely yours. Building your own model is almost never the differentiator; building your own *use of it against your data and process* often is. :::tip[Assessment signal] When a stem asks whether to build a custom model or a bespoke platform to "own our AI", the discriminator is **differentiation**: own what is distinctive, buy the commodity. "Own our AI" as a slogan is a distractor. ::: ## 2.5 Funding models How you fund shapes behaviour. Three common models, each with a bias. | Model | How it works | Encourages | Risk | | --- | --- | --- | --- | | **Central fund** | A programme budget pays for pilots and platform | Experimentation, fast start | Weak business ownership; "free money" | | **Chargeback** | Consuming function pays per seat/token | Discipline, real demand signal | Chills early experimentation | | **Blended** | Central funds prove; functions fund scale/embed | Prove cheaply, then commit | Needs a clear hand-off at the scale gate | The blended model usually maps best onto prove → scale → embed: the centre absorbs the cost and risk of proving, and the business picks up cost as it scales — which also forces the ownership transfer at the scale gate. ## 2.6 What an initial AI strategy draft contains The Academy objective is a *draft*, not a 60-page tome. A steering group can approve or reject a good draft in one meeting. It contains, in order: ```text 1. Priorities the stated business priorities AI will serve 2. Where AI plays the value-chain map and the chosen portfolio 3. Roadmap prove → scale → embed with named initiatives + gates 4. Operating model platform choice, ownership, decision rights 5. Governance risk posture, controls, review path (ref D3) 6. People capability plan, roles, enablement (ref D5) 7. Funding & economics model, budget ask, unit-economics assumptions 8. Measurement baselines, leading + lagging indicators (ref D6) ``` - Every initiative traces to a priority in one line. - Every phase has a gate and a kill condition. - Numbers carry assumptions and ranges, not hero figures. - Governance and people are *in* the strategy, not bolted on later. - It fits the reader: a decision, the ask, the risks, on a few pages. The draft is a living artefact: it is revised at each gate as pilots prove or fail. A strategy that never changes after month one was not a strategy, it was a wish. ## Decision framework ### The T-R-A-C-K roadmap test Before a strategy draft goes to a steering group, run it through five questions. A "no" on any is a rewrite, not a debate in the room. | Letter | Question | Failure mode it catches | | --- | --- | --- | | **T**raceable | Does every initiative map to a stated priority? | Technology-led hobby projects | | **R**ight-sequenced | Is each item in prove, scale or embed with a gate? | Scaling the unproven; piloting forever | | **A**ffordable | Do unit economics and the funding model hold? | Free-pilot illusions, runaway spend | | **C**ontrolled | Are governance and data handling addressed up front? | Compliance discovered after launch | | **K**illable | Does each phase have a written kill condition? | Sunk-cost zombies | ## Common mistakes | Mistake | Why it happens | What to do instead | | --- | --- | --- | | Presenting AI as its own goal | It is exciting; the tech dazzles | Trace every initiative to a stated priority in one line | | Scaling a popular but unproven pilot | Enthusiasm outruns evidence | Gate scale on baselined benefit and a safe design | | Piloting forever | Proving feels safe; scaling is scary | Set a time box and a scale-or-kill gate on every pilot | | Buying a point tool per team | Each team solves its own problem | Standardise a thin platform (identity, controls) first | | Building a custom model to "own our AI" | Slogan-driven strategy | Buy the commodity; build only the differentiating layer | | Central fund with no hand-off | Easy to start, nobody owns it | Use blended funding; transfer cost and ownership at scale | | Governance and people bolted on late | They slow the exciting part | Include them as strategy sections from the first draft | | A 60-page strategy nobody reads | Effort mistaken for rigour | Deliver a short, decision-shaped draft revised at each gate | ## Scenario challenge **Scenario.** You are the newly appointed AI programme director at a global logistics firm. The CEO's three stated priorities this year are: cut cost-to-serve, protect margin against a new low-cost competitor, and improve on-time delivery. In your first month you inherit: a stalled "build our own logistics LLM" project (18 months in, no production use), four functions each trialling a different AI point tool bought on their own cards, and a board expectation of an AI strategy draft in six weeks. The CIO wants a single enterprise platform; the CFO wants proof before spend; two function heads are attached to their point tools. **Expert reasoning trace.** 1. **Anchor to the stated priorities first.** Cost-to-serve, margin defence and on-time delivery are the only justifications that will survive the boardroom. I will trace every proposed initiative to one of these, and I already suspect the "build our own LLM" project traces to none of them — it is a technology ambition, not a priority. 2. **Kill or repurpose the LLM build.** Eighteen months, no production use, and no trace line — under the K in T-R-A-C-K it is a zombie. Building a foundation model is not our differentiation; our differentiation is our routing data and process. I recommend stopping the model build and redirecting the team to a *thin differentiating layer* (routing optimisation on our data) on top of a bought foundation. 3. **Rationalise the point-tool sprawl without a turf war.** Four uncoordinated tools mean fragmented governance and duplicate spend. Rather than banning them outright (which loses the function heads), I propose a thin platform — governed identity, controls and a model surface — and let the functions keep the *use cases* that prove value on top of it, migrating off tools that duplicate the platform. This satisfies the CIO's platform instinct and the function heads' ownership. 4. **Sequence the roadmap.** Prove: two or three baselined pilots aimed squarely at cost-to-serve and on-time delivery (the priorities with the cleanest measures). Scale: whichever proves benefit at acceptable unit cost. Embed: hand ownership to operations. Margin defence is a longer revenue/risk bet — I frame it as an exploratory prove-phase item, not a headline promise. 5. **Pick funding to force ownership.** Blended: the central programme funds the prove phase (satisfying the CFO's "prove before spend" by keeping the bet small), functions fund scale — which also forces the ownership hand-off. 6. **Deliver a short draft.** Eight sections, each initiative traced in a line, each phase gated and killable, numbers with ranges. It fits the six-week ask because it is a *draft*, not an encyclopedia. **Board-ready outcome:** the unproven model build is stopped and its team redirected; a thin platform absorbs the sprawl while functions keep their use cases; two or three priority-aligned pilots enter a gated prove phase; blended funding forces ownership at scale; the six-week deliverable is a short, traceable, killable strategy draft the board can approve or amend. ## Assessment traps | Trap | Why it is tempting | The discriminator | | --- | --- | --- | | Keep the 18-month model build because of sunk cost | Nobody likes writing off spend | No trace line + no production use → kill; own differentiation, buy commodity | | Ban all point tools and mandate one platform overnight | Feels decisive and tidy | Standardise a thin platform, keep proven use cases; avoid turf wars and shadow IT | | Scale the most popular pilot immediately | Momentum feels like success | Scale gate requires baselined benefit and a safe design, not popularity | | Fund everything centrally to move fast | Removes friction early | Blended funding forces business ownership at the scale gate | | Write a 60-page strategy to look rigorous | Length signals effort | A short, decision-shaped, revisable draft is the objective | | Justify an initiative by "competitors are doing it" | Fear is persuasive | Justification must trace to a stated internal priority | ## Practice questions Each item states how many responses to select. Commit before revealing. A. Fund it anyway; AI initiatives are inherently valuable. B. Cut it from the strategy; an initiative that traces to no stated priority is not strategic. C. Rename it to sound aligned. D. Move it to the embed phase. **Answer: B.** Traceability to a stated priority is the test of a strategic initiative; one that traces to none should be cut. Funding regardless (A) is technology-led; renaming (C) is dishonest; moving to embed (D) skips proving and ignores the real problem. A. It is the most popular pilot among staff. B. It has shown a baselined benefit and a safe, repeatable operating design. C. A competitor has scaled something similar. D. The central fund still has budget. **Answer: B.** The prove-to-scale gate is baselined benefit plus a safe, repeatable design. Popularity (A), competitor moves (C) and available budget (D) are not evidence of value or safety. A. Ban all of them immediately. B. Standardise a thin platform (identity, controls, model surface) and keep the use cases that prove value, migrating off duplicates. C. Buy a fifth, larger tool to replace them all at once. D. Leave the sprawl; competition between tools is healthy. **Answer: B.** A thin platform centralises governance while preserving proven use cases and business ownership. An outright ban (A) loses goodwill and creates shadow IT; a big-bang replacement (C) is high-risk; leaving sprawl (D) fragments governance and duplicates spend. A. The capability is genuinely differentiating for your business. B. You have the skills to build and, crucially, to run and maintain it. C. The capability is a commodity available from several vendors. D. A slogan says you should 'own your AI'. E. You want the fastest possible time-to-value. **Answer: A and B.** Build when it differentiates and you can sustain it. Commodities (C) should be bought; slogans (D) are not a criterion; fastest value (E) favours buying. A. Continue; the sunk cost must be recovered. B. Stop it, and redirect the team to a differentiating layer on a bought foundation. C. Move it to the scale phase to force progress. D. Double the budget to finish faster. **Answer: B.** Sunk cost is not a reason to continue an untraceable, unproven build; own the differentiating layer, buy the commodity foundation. Continuing (A) and doubling down (D) throw good money after bad; scaling (C) an unproven project is worse. A. Full chargeback from day one. B. Blended: the centre funds a small prove phase, functions fund scale and embed. C. No funding until the strategy is fully signed off. D. Central funding for the entire lifecycle. **Answer: B.** Blended funding keeps the prove bet small and central (satisfying 'prove before spend') and shifts cost to functions as they scale. Day-one chargeback (A) chills experimentation; waiting for full sign-off (C) stalls learning; lifelong central funding (D) removes business ownership. A. Governance and risk posture. B. Measurement with baselines and indicators. C. A complete vendor contract with signed terms. D. The full source code of every planned tool. E. A detailed multi-year hiring plan for the whole company. **Answer: A and B.** Governance and measurement are core strategy sections, present from the first draft. A signed contract (C) and source code (D) are downstream artefacts; a company-wide multi-year hiring plan (E) is beyond an initial AI strategy draft's scope. A. Extend the pilot another year to be sure. B. Impose a time-boxed scale-or-kill gate with a baselined benefit test. C. Quietly cancel it to save face. D. Scale it immediately on the strength of feedback. **Answer: B.** Endless piloting is a roadmap failure; a time-boxed scale-or-kill gate with an evidence test forces a decision. Extending (A) continues the failure; quiet cancellation (C) wastes the learning; scaling on feedback alone (D) skips the benefit test. A. 'It uses the most advanced model available.' B. 'It shortens the sales cycle and lifts win rate, which serves the stated growth priority — here is the traced number.' C. 'Every competitor is investing in AI.' D. 'We have already spent budget on it.' **Answer: B.** A strong answer traces the initiative to the stated priority with a driver-based number. Model sophistication (A), competitor fear (C) and sunk cost (D) are all non-strategic justifications. A. A separate point tool for each need. B. A platform approach that centralises identity, controls and logging, with use cases built on top. C. No AI until every need has its own bespoke build. D. A single custom model for everything. **Answer: B.** Overlapping needs plus strict compliance favour a platform that centralises governance once. Point tools per need (A) fragment control; blocking everything (C) forgoes value; one custom model (D) is neither a governance nor a fit solution. A. The model must be upgraded to the newest version. B. Ownership must move from the central AI team to the business that runs the work. C. The initiative must be re-piloted from scratch. D. The funding must return to the central fund. **Answer: B.** Embedding means the business owns and sustains the change; without the ownership transfer, value evaporates when the central team's attention moves. A model upgrade (A) is unrelated; re-piloting (C) undoes progress; returning to central funding (D) prevents ownership. A. Add explicit assumptions and a confidence range to each number. B. Add a kill condition and gate to each roadmap phase. C. Increase every number by 20% to look ambitious. D. Remove the measurement section to keep it short. E. Replace the numbers with vendor testimonials. **Answer: A and B.** Credible numbers carry assumptions and ranges, and a real roadmap has gates and kill conditions. Inflating figures (C), dropping measurement (D) and substituting testimonials (E) all reduce rigour and credibility. ## Key takeaways - Strategy starts from **stated priorities**; every initiative traces to one in a single line, or it is cut. - Sequence the portfolio **prove → scale → embed**, with a gate and a kill condition at each transition. - Scale on **baselined benefit and a safe design**, not on popularity; do not pilot forever. - Prefer a **thin platform, thick use cases**: centralise identity, controls and the model surface once. - **Build only the differentiating layer**; buy the commodity foundation. "Own our AI" is a slogan, not a strategy. - Use **blended funding** to prove cheaply and force business ownership at the scale gate. - The deliverable is a **short, traceable, killable strategy draft** revised at each gate — the Academy course's headline objective. - Run **T-R-A-C-K** before the steering group: traceable, right-sequenced, affordable, controlled, killable.