AI Strategy for Executives

Course Page

Promise: After this course, you can identify where AI genuinely creates value in your organization, interrogate vendor claims without a technical translator, budget with realistic ROI thinking, stand up basic governance, move a pilot to production deliberately, and lead an adoption your people trust.

Outcome: After this, the learner can classify AI use cases by value type, apply a vendor-claims checklist, build a simple cost model, draft a five-row risk register, define pilot go/no-go gates, and outline a no-surprises rollout plan.

Context: Executives are caught between two bad narratives: "AI changes everything, move now or die" and "it's all hype, wait it out." Both are lazy. The truth is operational: AI creates measurable value in specific, identifiable places — and creates expensive messes when adopted by press release. This course is the operating discipline, not the narrative.

Who this is for: CEOs, COOs, owners, GMs, and department heads at organizations from ~25 to several hundred people. Also useful for board members who want sharper questions.

Prerequisites: None technical. You should know your own cost structure and org chart.

Modules:

1. Where AI creates value — and where it doesn't
2. Reading vendor claims critically
3. Budgeting and ROI thinking
4. Governance and the risk register
5. Pilot to production
6. Leading human-first adoption

Time estimate: 2.5–3 hours. Lessons are 25–30 minutes each and build on a single running example.

Completion criteria: All six activities done, producing: a classified use-case list, a completed vendor checklist, a cost model for one use case, a five-row risk register, written go/no-go gates, and a rollout communications outline.

Running example, used throughout: Meridian Property Group — a fictional 140-person regional property management company (CEO Dana Okafor, COO Marcus Webb): thousands of tenants, a call center of nine, maintenance dispatch, leasing, and accounting. All figures fictional and illustrative.

Lesson 1 — Where AI Creates Value (and Where It Doesn't)

Objective: Classify at least five candidate use cases from your organization into the four value categories or the no-go list, with one sentence of reasoning each.

Explanation

AI value in operating businesses shows up in four places. If a proposal doesn't map cleanly to one of them, be suspicious.

1. Time on repetitive knowledge work — drafting, summarizing, data entry, categorizing, first-pass review. Value = hours × loaded cost, discounted for the human review that remains.
2. Response speed and coverage — answering at 2 a.m., in minute one instead of hour four, or during demand spikes without overtime. Value = captured revenue and retention you currently lose to slowness.
3. Consistency and quality — every intake asked the same questions, every document containing the required clauses, fewer reworks. Value = error and rework cost avoided.
4. *Decision support** — surfacing patterns, flagging anomalies, assembling briefings so your people decide faster with better information. Note the word support*: the value is better-informed humans, not outsourced judgment.

Where AI does not create value — the no-go list:

• Accountability decisions: hiring, firing, discipline, credit or lease denials made by a machine. Humans decide; AI may organize the file. (In some jurisdictions, automated consequential decisions are legally restricted — verify current requirements with counsel.)
• Relationship repair: an escalated customer wants a human with authority, not a fluent apology engine.
• Thin-data problems: strategy pivots, one-off negotiations, novel situations. AI extrapolates from patterns; no pattern, no value.
• Anything you can't verify: if nobody in your org can check the output's correctness, you've automated the appearance of work.

The executive skill is sorting, not enthusiasm. A use case belongs in exactly one bucket, with a sentence of reasoning attached.

Example

Dana at Meridian collects six ideas from her leadership team and sorts them. Maintenance-call triage after hours → category 2 (coverage; calls currently roll to an answering service that mis-prioritizes emergencies). Lease-document first-pass review → category 3 (consistency; missing-clause rework is a known cost). Monthly owner-report drafting → category 1 (each property manager spends hours assembling them). "AI to pick which tenants to non-renew" → no-go (accountability decision; AI may assemble the file of facts, a human decides and owns it). "AI chatbot to handle angry escalations" → no-go (relationship repair). "AI to set our five-year expansion strategy" → no-go (thin data; that's Dana's job). Six ideas in, three viable, three declined with reasons she can state to the board in one breath each.

Activity

Gather 5–8 AI ideas floating around your organization (ask your directs — they have a list). Sort each into categories 1–4 or the no-go list, with one sentence of reasoning. Keep this sheet; Lessons 3 and 5 reuse it.

Check for understanding

1. What distinguishes category 4 from the no-go "accountability decisions"? — Category 4 informs a human decision-maker; the no-go is the machine making the consequential call. The dividing line is who owns the decision.
2. Why are thin-data problems poor AI candidates? — AI generalizes from patterns in data. Novel, one-off situations have no pattern to learn from, so output is confident-sounding guesswork.
3. A vendor proposes "AI that handles your escalated complaints end-to-end." Which list, and why? — No-go (relationship repair). Escalations need human authority and empathy; AI can assist with history and drafting, but a person carries the conversation.

Next lesson: Now that you know where value lives, you can hear the difference between a vendor describing it and a vendor describing vibes.

Lesson 2 — Reading Vendor Claims Critically

Objective: Apply the seven-question vendor checklist to one real (or realistic) pitch and produce a written pass/fail with follow-ups.

Explanation

Vendors aren't villains — but demos are theater, and your job is diligence. Two rules of thumb: a demo on their data proves almost nothing about your data; and any claim without a denominator ("99% accurate!") is marketing, not measurement. Accurate at what task, measured how, on whose data, with what error handling when it misses?

The seven questions (put them in writing; written answers age better than sales calls):

1. "Show me this working on data like ours." Same industry, same messiness. Offer a sanitized sample if needed.
2. "What's your measured error rate, and how is it defined?" Listen for a definition, a denominator, and a straight answer about failure modes.
3. "What happens when it's wrong?" You want: detection, escalation to humans, correction workflow. Red flag: "it's rarely wrong."
4. "Where does our data go, who can access it, and is it used for training?" Vague answers here end the conversation. So does "we'll get back to you."
5. "What does exit look like?" Data export format, contract terms, what breaks when you leave. Avoid anything you can't leave.
6. "What's the full cost structure?" License plus usage plus integration plus training plus support. Pricing models in this market shift frequently — get current figures in writing and re-verify at renewal (verify current figures before relying on this).
7. "Give me two references in our industry, including one that had problems." How a vendor handled a rough deployment tells you more than a happy logo wall.

Red-flag phrases worth an instant follow-up: "no humans needed," "works out of the box for everyone," "AI-powered" with no explanation of what the AI does, and any resistance to a paid, bounded pilot with defined success criteria.

Example

Marcus at Meridian runs two after-hours-call vendors through the checklist. Vendor A demos on generic property-management calls, answers the error-rate question with "our accuracy is industry-leading," and offers a discount if Meridian signs this quarter. Vendor B demos on Meridian's own sanitized call recordings, quotes a measured containment rate with its definition ("calls resolved without human callback, excluding emergencies — which always page a human"), documents its data-retention terms, and proposes a 60-day paid pilot with shared success metrics. Vendor B is more expensive on paper. Marcus recommends B, and the checklist gives him the one-page reasoning Dana takes to the board.

Activity

Take one real pitch from your inbox (there's one there) or a plausible fictional one. Score it against the seven questions: pass, fail, or unanswered. Draft the follow-up email requesting written answers to every "unanswered."

Check for understanding

1. Why demand a demo on data like yours? — Demos are optimized on clean, chosen data. Your value depends on performance on your messy reality; industry-similar data is the cheapest available proof.
2. What makes "99% accurate" meaningless by itself? — No task definition, no denominator, no error-type breakdown, no measurement method. Accuracy claims need context to be evaluated at all.
3. Why does the exit question matter before signing, not after? — Switching costs are set at contract time. Data portability and exit terms negotiated up front are cheap; negotiated during a dispute, they're expensive or impossible.

Next lesson: The checklist filters vendors. The budget model decides if even the good ones are worth it.

Lesson 3 — Budgeting and ROI Thinking

Objective: Build a simple total-cost model (build + run + people) and payback frame for one use case from your Lesson 1 sheet.

Explanation

Most AI budget mistakes are one of two: funding only the software (ignoring integration and people), or demanding certainty before spending anything (guaranteeing you learn nothing). The discipline in between is a simple model, conservative estimates, and a baseline measured before launch.

Total cost has three layers:

1. Build (one-time): implementation, integration with your systems, data cleanup, initial configuration and testing. This layer varies enormously with scope — from four figures for a contained tool to six figures for deep multi-system work (treat any figure as a planning range and verify current figures before relying on this).
2. Run (recurring): subscriptions/usage fees, hosting, monitoring, periodic updates as your processes change.
3. People (chronically underbudgeted): training time, the human review hours that remain by design, and a named internal owner's ongoing attention. If the people layer is zero in a proposal, the proposal is fiction.

Benefit, conservatively: hours returned × loaded cost (discounted ~15% for oversight), plus error/rework cost avoided, plus revenue captured by speed and coverage — counting only what you can tie to a measured baseline. Ignore soft benefits ("morale," "innovation culture") in the financial case; if they show up later, they're a bonus, not a justification.

The frame that keeps you honest: payback in months = build cost ÷ net monthly benefit, then judge bands, not decimals — under 6 months is strong, 6–18 defensible, beyond 18 needs strategic (not financial) justification. Our AI ROI Estimator (/academy/demos/ai-roi-estimator) implements exactly this thinking for a single task, oversight discount included. And one rule with no exceptions: the baseline is measured before launch. Post-hoc baselines flatter every project.

Budget one more line: iteration. First versions are 80% right; reserve perhaps 15–20% of build cost for the tuning that follows contact with reality. Teams that budget iteration ship; teams that don't, stall at 80%.

Example

Meridian models after-hours maintenance triage (all figures fictional). Benefit side: the call center returns roughly 120 misrouted-call hours a month, and emergency mis-prioritization — their costliest failure, occasionally turning a contained leak into a flooded unit — has a rework/damage history averaging a few thousand a month. Cost side: a build estimate in the mid five figures (range held, pending vendor B's scoping), monthly run fees, 20 hours of dispatcher training, and — the line Marcus almost missed — five review-hours a week where a senior dispatcher audits the agent's overnight priority calls. Modeled payback lands around 8–11 months: the defensible band, not the miraculous one. Dana approves it as modeled — with the pre-launch baseline (misroute rate, response times, damage incidents) assigned to an owner with a deadline.

Activity

Pick the strongest category-1 or category-2 use case from your Lesson 1 sheet. Fill the three cost layers (ranges are fine; label them), estimate benefit conservatively, compute the payback band, and name the baseline metrics plus who measures them before any contract is signed.

Check for understanding

1. Which cost layer is most often zeroed out, and why is that fiction? — People. Training, mandatory review hours, and internal ownership are real recurring costs; without them the system degrades or gets abandoned.
2. Why must baselines precede launch? — Baselines reconstructed after launch are biased toward justifying the spend. Pre-launch measurement is the only credible before/after.
3. Payback lands at 14 months. What band is that, and what does it imply? — Defensible (6–18). Proceed if the strategic fit is real and the inputs are conservative; it's not a drop-everything project.

Next lesson: The money case is necessary but not sufficient. Governance is what keeps a good project from becoming a headline.

Lesson 4 — Governance and the Risk Register

Objective: Draft a five-row AI risk register — each row with likelihood, impact, a named owner, and a mitigation.

Explanation

"AI governance" sounds like a binder nobody reads. Strip it to what an operating executive actually needs — four artifacts, each one page or less:

1. An AI-use inventory. Every AI system touching your operations or data, including the unofficial ones your teams already use. You can't govern what you haven't listed.
2. Data rules. What data may enter which tools, in plain language: e.g., "customer PII only in approved, contracted systems — never in free consumer chat tools"; "payroll and health data: named systems only." Regulated categories carry legal duties that vary by industry and region (verify current requirements with counsel).
3. Human review points. Written rules for where a person approves before action: money, legal commitments, anything customer-visible in sensitive contexts. If it's not written, it erodes on the first busy day.
4. An incident path. Who is told, who can pause the system, what gets logged when AI output causes a problem. Decided now, not during the incident.

Underneath all four sits one requirement: auditability — the ability to answer "what did the system do, when, with what data, and why?" This is the principle behind our Ed OI (Operating Intelligence) approach — governed AI with persistent, auditable memory — but the principle is vendor-neutral: if you can't see what it did, you can't govern it. Ask every vendor how they'd answer that question.

The risk register turns worry into management. Columns: risk, likelihood (L/M/H), impact (L/M/H), owner (a name, not a department), mitigation, review date. Five honest rows beat forty theoretical ones — and a quarterly 30-minute review beats both.

Example

Meridian's first register, drafted in an hour (fictional):

Note the last row: the most underrated AI risk is human, not technical — approval fatigue that turns "human in the loop" into a checkbox. Meridian treats review time as scheduled work, which is the only mitigation that survives a busy quarter.

Activity

Draft your five rows. At least one must be a data risk, one a human-factors risk (like rubber-stamping). Every owner is a person's name. Put a 90-day review date on the register itself.

Safety note: Draft the register itself with clean hands — describe incidents and risks in general terms rather than pasting customer records, employee details, or contract text into whatever AI tool you're drafting with. And treat this lesson as management hygiene, not legal advice: where regulated data or automated-decision rules apply to your industry, have counsel confirm the current requirements before you rely on your register.

Check for understanding

1. Why does the inventory come first? — Ungoverned "shadow AI" use is already happening in most organizations; rules written without knowing actual usage govern an imaginary company.
2. What does auditability mean in one sentence? — You can reconstruct what the system did, when, with what data, and why — after the fact, from records, not memories.
3. Why is rubber-stamping a top-five risk? — Because every safeguard in your design assumes the human review is real; when it decays into a reflex click, you have unattended automation while your documents claim otherwise.

Next lesson: With value, vendor, budget, and governance settled, the pilot can start — and, more importantly, end — properly.

Lesson 5 — Pilot to Production

Objective: Write pilot success criteria and an explicit go/no-go gate (including kill criteria) for one use case.

Explanation

The most common executive AI failure isn't a disaster — it's pilot purgatory: eighteen months of "still evaluating," no numbers, no decision, team quietly demoralized. Purgatory has one cause: pilots launched without a defined ending.

A well-formed pilot has six elements, written before day one:

1. Narrow scope — one workflow, one team, one location. Small enough to watch closely.
2. A duration — 30, 60, or 90 days. It ends on a date, not "when we feel ready."
3. Baseline metrics — measured before launch (Lesson 3's rule).
4. Success criteria with numbers — "containment above X% with emergency-escalation accuracy at 100%," not "see how it goes."
5. A named owner — accountable for the weekly numbers and the feedback log.
6. Kill criteria — the conditions under which you stop early without debate: a serious data incident, error rates above a stated line, or team workarounds exceeding the automation's savings. Deciding these up front makes stopping a process, not a fight.

At the end: go, fix-and-extend (once), or kill — announced either way. Killing a pilot on its stated criteria is a governance success, and saying so publicly teaches your organization that honest pilots are safe.

Production is a different animal, and the gate between is where executives earn their keep. Production adds: monitoring dashboards someone actually watches, escalation staffing at real volume (not pilot volume), documentation and trained backups (the pilot champion will someday take a vacation), an update path for when your processes change, and a named ongoing owner with budget. If nobody owns the system in month nine, month nine is when it quietly breaks. This ongoing layer is precisely what a Managed AI Ops arrangement covers if you'd rather not build the muscle internally.

Example

Meridian's after-hours triage pilot (fictional): one property cluster, 60 days, baselines locked (misroute rate, median response time, damage incidents). Success gates: containment ≥ 60% of routine calls, emergency-escalation accuracy 100% on the weekly audit, dispatcher satisfaction ≥ neutral. Kill criteria: any missed true emergency, or a data-handling breach of contract terms. Day 60 results (still fictional): containment 71%, one near-miss where a "no heat" call in winter was queued routine — caught by the human audit, prompting a rule change (weather-conditional urgency) before scale-up. The gate meeting is 40 minutes: go, with the fix, expanding cluster by cluster, plus a monitoring dashboard and a named owner in dispatch. Not a triumph, not a scandal — a decision. That's what the gate is for.

Activity

For your Lesson 3 use case, write the six pilot elements and the production gate on one page. Hardest and most valuable: the kill criteria. If you can't write them, you're not ready to start.

Check for understanding

1. What single omission causes pilot purgatory? — No defined ending: no date, no numeric success criteria, no gate. Evaluation continues indefinitely because nothing forces a decision.
2. Why write kill criteria before launch? — Mid-pilot, sunk cost and politics contaminate the stop decision. Pre-agreed criteria make stopping a process rather than a confrontation.
3. Name three things production requires that a pilot doesn't. — Any three of: watched monitoring, escalation staffing at full volume, documentation/trained backups, an update path, a named ongoing owner with budget.

Next lesson: Every artifact so far assumes your people come along. That's not automatic — it's led.

Lesson 6 — Leading Human-First Adoption

Objective: Draft a no-surprises rollout outline: who hears what, when, from whom — plus a training plan and feedback channel.

Explanation

Here is the uncomfortable truth about AI programs: more of them fail from quiet human resistance than from bad technology. And that resistance is usually earned — by leaders who announced AI to the stock market before the staff, or let "efficiency" hang in the air as a euphemism.

Human-first adoption is a leadership sequence, not a memo:

1. Answer the job question first, honestly. People hear "AI" as "layoffs" until told otherwise, explicitly. If the goal is capacity without headcount growth, say that. If roles will change, say which and how — with dates and support. What you must not do is let silence do the announcing. Automate the repetitive. Protect the human — and say out loud that this is the design goal, then be accountable to it.
2. No surprises, in either direction. The team affected hears it first — before the board slide, before the newsletter. Nobody discovers an AI system by noticing their work changed.
3. Involve the people who do the work in design. Your dispatchers know the twelve weird call types the vendor never imagined. Involvement isn't a courtesy; it's where the accuracy comes from — and it converts your most skeptical veteran into your best tester.
4. Train for confidence, not compliance. Real sessions on work time: what the system does, where it fails, how to override it, and who to call. Budget it (Lesson 3's people layer). A 45-minute demo video is not adoption.
5. Keep a feedback channel with visible consequences. A named place to report "the AI got this wrong," reviewed weekly, with fixes announced back. The announce-back is the step everyone skips — and it's the one that builds trust, because it proves reporting problems works.
6. Celebrate time returned, specifically. "The front desk got eleven hours back last week and used it for the waitlist calls we never made" beats any adoption poster.

Transparency outward matters too: where customers interact with AI (calls, chat), it identifies itself and offers a human. Deception is both a trust and, increasingly, a regulatory problem (disclosure rules vary by region — verify current requirements).

Example

Meridian's rollout of the triage agent (fictional): Week 1 — Dana briefs the nine call-center staff in person, first, including the job answer: no positions eliminated; overnight misroute cleanup disappears; two senior dispatchers get paid audit responsibilities. Week 2 — two dispatchers join vendor design sessions; their call-type list drives the script. Weeks 3–4 — paid training for all nine, including "how to override" drills. Launch — tenants hear a clear disclosure line with "say 'agent' anytime for a person." Ongoing — a #triage-feedback channel reviewed every Friday, fixes announced Mondays. Month 3, the metric Dana quietly tracks alongside containment: dispatcher-initiated improvement suggestions — eight so far, which tells her the team has adopted the system as theirs.

Activity

Draft your rollout outline: the honest job-question answer in two sentences; the who-hears-when sequence; the training plan (hours, on whose time, covering overrides); the feedback channel and its announce-back rhythm.

Check for understanding

1. Why does the affected team hear before the board deck circulates? — Because discovering change second-hand reads as disrespect and breeds resistance; hearing it first, with the job question answered, builds the trust the rollout runs on.
2. What makes a feedback channel real rather than decorative? — Weekly review by a named owner and announced fixes — visible consequences prove reports matter.
3. What belongs in training beyond "how to use it"? — Where the system fails, how to override or escalate, and who owns problems — confidence comes from knowing the edges, not just the happy path.

Next lesson: None — continue to the completion page.

Completion Page

Practice (keep it alive): Put three recurring holds on your calendar now — a quarterly 30-minute risk-register review, a monthly glance at every live system's metrics against its baseline, and a standing agenda line in leadership meetings: "what did the feedback channels surface?" Governance that isn't scheduled quietly stops existing.

Summary: You now hold the six executive disciplines: sorting use cases by real value type, interrogating vendors with written questions, budgeting all three cost layers against pre-launch baselines, governing with an inventory, data rules, review points, and a living risk register, running pilots that end in decisions, and leading adoption that answers the job question out loud. None of it requires you to become technical. All of it requires you to stay in charge — which was the point.

Your next path:

• Put numbers on your leading use case with the AI ROI Estimator (/academy/demos/ai-roi-estimator), and have department heads run the AI Opportunity Audit Worksheet (/academy/templates/ai-opportunity-audit-worksheet) — their inventories become your pipeline.
• If phone coverage appeared anywhere on your sort sheet, read AI Voice Agents — What They Can Do (/academy/voice-agents/ai-voice-agents-what-they-can-do).
• Managers of smaller units may get more from the operator-level companion course, AI for Small Business Owners (/academy/business/ai-for-small-business-owners).

Service connection: These artifacts — the sorted use cases, cost model, risk register, and gates — are exactly the inputs a Discovery & Roadmap engagement turns into a sequenced plan; Training & Change runs the human-first rollout with you; and Managed AI Ops owns the month-nine problem so your systems stay watched, updated, and auditable. Book a call at /contact — bring the risk register; it's our favorite conversation starter.