Core Content
Part 1 — Setting an AI Position
A position is a deliberate, defensible stance on how aggressively you adopt AI and where. Without one, every team negotiates its own posture and you discover your "strategy" only after the spend. Three postures:
- Aggressive adopter — AI is a primary competitive lever; you accept higher tooling cost, faster change, and more operational risk to move first. Justified where AI directly compounds your moat or where an AI-native rival is already moving.
- Fast follower — you adopt proven patterns quickly but let others absorb the cost of discovery. The default posture for most growth-stage operators in their core domain. Cheaper, lower-risk, and still fast if your procurement is agile.
- Risk-conservative — you constrain or delay AI where the downside (regulatory, reputational, safety) dominates the upside. Correct for anything touching regulated customer data, consequential decisions, or compliance-exposed workflows.
The mistake is choosing one posture for the whole company. The discipline is choosing by domain.
DOMAIN POSTURE WHY
──────────────────────────────────────────────────────────────────
Core product (the moat) Fast follower Proven patterns, protect reliability
Internal engineering velocity Aggressive adopter Compounds talent density, low blast radius
GTM / marketing content Aggressive adopter Cheap to test, fast feedback
Customer-facing decisions Risk-conservative Wrong output = trust + compliance hit
Regulated data handling Risk-conservative Downside dominates upside
──────────────────────────────────────────────────────────────────Do: State the posture per domain in one sentence each, and name the trigger that would change it (e.g., "we move core to aggressive adopter the moment an AI-native competitor ships feature parity").
Don't: Default the whole company to "aggressive adopter" because it sounds ambitious. Aggressive everywhere is risk-conservative nowhere — and that is how ungoverned spend and shadow AI grow.
I have watched a $40M SaaS company declare itself "AI-first" and then freeze for six months because nobody had said what "first" meant for the data-residency-constrained part of the product. A position differentiated by domain would have let three of four teams ship while the fourth got the scrutiny it needed.
Part 2 — Building a Competitive Thesis
A competitive thesis answers one question your board will eventually ask: does AI make us harder to beat, or easier? It has three parts.
1. Where AI widens the moat. AI compounds advantages you already have — proprietary data, distribution, workflow lock-in, switching costs. If you hold a unique data asset and product usage improves it, AI widens the moat: competitors can copy the model but not the data flywheel.
2. Where AI commoditizes the moat. AI erodes advantages built on scarcity that AI now makes abundant. If your edge was "we write better copy" or "our analysts produce faster reports," a frontier model just commoditized it. Be honest here — this is the section leaders skip and competitors exploit.
3. AI-native threats. Name the entrants who are building from scratch with AI as the architecture, not a feature. They carry no legacy cost structure and can price against your margin. Ask: if a well-funded team started today with AI at the center, what part of our business would they attack first?
WIDENS THE MOAT COMMODITIZES THE MOAT
┌──────────────────────┬──────────────────────────┐
PROPRIETARY │ Data flywheel │ Generic content/analysis │
vs GENERIC │ Workflow lock-in │ Tasks any LLM now does │
├──────────────────────┼──────────────────────────┤
THREAT │ AI-native entrant attacks the commoditized │
VECTOR │ quadrant first, then prices against your margin │
└───────────────────────────────────────────────────┘Worked example. A legaltech operator's moat was "fastest contract review." A frontier model commoditized raw review speed. But their thesis identified the real moat as the proprietary corpus of client-specific clause outcomes — which AI widens, because every reviewed contract improves retrieval quality competitors cannot replicate. The strategic move flipped: stop marketing speed, double down on the data flywheel, and treat the AI-native "instant review" startup as a threat to the commoditized layer, not the core.
"AI is a tailwind for everyone in our category." If it helps everyone equally, it is not a moat — it is table stakes, and your thesis must say so plainly. A thesis that finds only upside is a marketing line, not a strategy.
Part 3 — The Prioritized Initiative Portfolio
Leadership's job is not to run AI initiatives; it is to maintain a portfolio where every initiative is traceable to a business outcome, an owner, and a metric. If you cannot draw the line from an initiative to a P&L or competitive outcome, it is a science project and should be defunded or reframed.
Every initiative gets one row:
| Initiative | Business outcome | Owner | Metric (with cost) | Posture | Build/Buy | Status |
|---|---|---|---|---|---|---|
| AI code-assist rollout | Eng velocity ↑, cost/feature ↓ | VP Eng | PRs/eng + cost/feature, defect rate | Aggressive | Buy | Live |
| Support deflection bot | Cost/ticket ↓, CSAT held | Head of CS | Cost/ticket, deflection %, CSAT | Fast follower | Buy | Pilot |
| Proprietary-data RAG search | Retention ↑ (the moat) | CPO | Feature adoption, retention delta | Fast follower | Build | Proposed |
Pair every velocity or efficiency metric with a quality/security guardrail. "More code, faster" that quietly degrades reliability is negative ROI you booked as a win.
Naming the one initiative. Once the portfolio exists, leadership must name the single highest-impact 12-month initiative — the one that most changes competitive position. This is not the easiest or the cheapest; it is the one that, if a competitor did it first, would hurt most. This maps directly to Diagnostic Question 4: "Can you name the one AI initiative in the next 12 months that would most change your competitive position?" A leadership team that cannot name it does not have a strategy; it has a backlog.
PORTFOLIO PRESSURE TEST — every initiative must pass all four:
[ ] Traces to a named business outcome (not "innovation")
[ ] Has a single accountable owner (a name, not a committee)
[ ] Has a metric with usage/token cost in the denominator
[ ] Has a paired quality/security guardrail
→ If it fails any, defund, reframe, or assign before it consumes budget.The "one initiative" exercise is where workshops get tense, and that tension is the point. If naming it is easy, you probably named a feature. The right answer usually makes one executive uncomfortable because it concentrates resources away from their area.
Part 4 — Deliberate Build vs. Buy
At growth stage, build-vs-buy is the decision most often made by reflex — engineers want to build, finance wants to buy — and least often made deliberately. The evidence sets the default. MIT (2025) found buy/partner approaches succeed roughly 67% of the time versus roughly 33% for internal builds — about a 2× differential at this stage.
So buy or partner is the default. Build only when you can articulate a specific reason the default is wrong:
- Build when the capability is the moat (the proprietary data flywheel, the differentiating workflow), when no vendor can meet a hard regulatory/data-residency constraint, or when long-run unit economics at your scale clearly favor owning it.
- Buy/partner when the capability is undifferentiated infrastructure (transcription, generic chat, code assist, observability), when speed-to-value matters more than control, or when the vendor's data flywheel already beats anything you'd build alone.
BUILD-VS-BUY DECISION GATE
──────────────────────────────────────────────
Is this capability the moat? ──No──► BUY/PARTNER (default, ~67% success)
│ Yes
▼
Can a vendor meet the hard constraint? ──Yes──► BUY/PARTNER
│ No
▼
Do unit economics at our scale favor owning? ──No──► BUY/PARTNER
│ Yes
▼
BUILD (the ~33% — make sure you're the exception, on purpose)
──────────────────────────────────────────────Do: Treat "build" as the decision that must justify itself against a 2× lower success rate. Write the justification down in the portfolio row.
Don't: Build commodity infrastructure because the team finds it interesting, or because "we don't want vendor lock-in" without pricing what the build actually costs in opportunity and reliability.
The most expensive 2026 mistake leaders fund is an internal build of capability a vendor already does well — paid for twice: once in engineering opportunity cost, again in the reliability gap a 50-person team cannot close against a focused vendor. If you build, build the moat, not the plumbing.
Part 5 — Answering the Board and Investors
Leaders fail board AI conversations in predictable ways: they report activity ("we rolled out Copilot to 80% of engineers") instead of outcome, they cite vendor stats instead of their own evidence, and they cannot say who is accountable. Fix all three.
ROI — answer with the three-tier frame, cost in the denominator.
| Tier | What you report | Example evidence |
|---|---|---|
| 1 — Adoption | Active use, cert completion | 84% of eng using assist weekly; Module B logged 100% |
| 2 — Depth / efficiency | Time saved, AI code share, PRs | Cost/feature down 18%; AI code share ~22% |
| 3 — Financial impact | ROI with token/usage cost in denominator | Net ROI ~3.1× after $X token spend; margin held |
| Guardrail | Quality/security alongside every velocity claim | Defect rate flat, escaped vulns down — velocity is real |
Never report a velocity number without its paired quality guardrail. A board that has been trained (by your briefings) to ask "and what happened to defect rate?" is a board that will not be fooled by a vendor's slide — and that is the board MIT correlates with +10.9 points of ROE.
Governance — answer with structure, not assurance. The board does not want "we're being careful." It wants: who owns AI strategy accountability (a name — Diagnostic Q5), what AI is not allowed to decide without human review (Diagnostic Q3), what the escalation path is when AI produces a wrong output (Diagnostic Q2), and what tools are sanctioned and who approved them (Diagnostic Q1). Those four are the governance spine; Module H builds the artifacts behind them.
Run a recurring briefing, not a one-off. Board AI fluency is built by cadence. A quarterly 30-minute board AI brief — one strategic development, one regulatory development translated to a single sentence, the portfolio's one-initiative status, and the guardrail dashboard — does more than any single offsite. With 44% of companies now treating AI experience as a director qualification, the briefing is also how the board demonstrates its own fitness to oversee.
The strongest answer to "what's our AI ROI?" is not a number — it's a number with its cost in the denominator and its quality guardrail beside it, delivered by a named owner. That sentence is what separates the +10.9-ROE board from the one being sold to.