The AIDA Manifesto

The AIDA Playbook

The operating system for turning AI & Data into impact.
This is not a methodology. It’s a discipline: prove value fast, then scale what works.

CEO / Exec Sections 1, 2 & 10
CIO / CDO Sections 3–8
Product Teams Sections 4–6
Section 1

The AIDA Non-Negotiables

If you violate these, you are not “adapting AIDA to your context.” You are returning to the old machine.

1
One problem at a time. One team. One clear user. One measurable outcome.
2
Baseline first. No baseline → no work.
3
Discovery before commitment. You earn funding with evidence, not ambition.
4
Proof of Value over Proof of Concept. POCs impress. PoVs change outcomes.
5
Off-the-shelf discovery. Zero customization. If you can’t prove value with what exists, reframe.
6
Kill fast. Stopping work is a sign of maturity, not failure.
7
Ownability beats feature-fit. If you can’t sustain it, don’t buy it.
8
Teams own outcomes end-to-end. No “throw it over the wall.”
9
Guardrails, not bureaucracy. Governance enables speed while preventing harm.
10
Measure value, not activity. Milestones are not impact.

Print this page. If anyone argues with it, you have found the root cause.

Section 2

The 90-Day Plan

What “starting AIDA” actually means. Three phases. One shipped outcome.

Days
1–10

Reset

Align & Focus
  • Name an executive sponsor
  • Choose one problem
  • Assign product owner + team
  • Define baseline & success threshold
  • Block 4 weeks for discovery
Days
11–40

Discover

Sprint & Prove
  • Run the 4-week discovery sprint
  • Produce a Proof of Value memo
  • Make a go / kill / pivot decision
Days
41–90

Deliver

Ship & Sustain
  • Ship MVP to production users
  • Stand up governance guardrails
  • Install monthly portfolio review
  • Capture the case study
  • Choose next problem

After 90 days: one shipped value outcome, one repeatable discovery mechanism, one scorecard, one team that knows how to do it again.

Sections 3 & 4

Team Design & Problem Selection

The smallest team that can ship value, pointed at the right problem.

The AIDA Product Team

  • Product Owner — owns the outcome and the roadmap. Not a committee.
  • Domain Lead — understands the workflow and the decisions.
  • Data / AI Engineer — from data access → experiment → deploy.
  • Analyst / UX / Change — makes the result usable and adopted.
2–5 people for the first product. Anything bigger is usually a coordination tax.

Good First Problem Checklist

  • Painful — someone feels it weekly
  • Measurable — baseline exists or can be created fast
  • Narrow — one workflow, one decision
  • Actionable — output changes behavior, not just reporting
  • Owner-clear — a leader will own adoption
  • Safe to learn — failure won’t harm customers or compliance
If you can’t commit to one problem for 4 weeks, you don’t want impact — you want optionality.
Section 5

The Discovery Sprint

Four weeks. From problem to proof. The heart of AIDA.

Week 1

Problem Deep-Dive

Clarity before code
  • Problem Brief (one page)
  • User + workflow map
  • Success metric + threshold
  • Constraints & scope
Stop: If you cannot define a measurable success threshold, kill or reframe.
Week 2

Data Reality Check

Truth before ambition
  • Data inventory: sources, owners, access
  • Data profiling summary
  • Minimal dataset definition
Stop: If critical data does not exist or cannot be accessed ethically, kill.
Week 3

Off-the-Shelf Experiments

Zero customization
  • Experiment log (5+ experiments)
  • Baseline comparator
  • Shortlist of best approach
Stop: If you cannot beat a simple baseline, kill or reframe.
Week 4

Proof of Value

Evidence in the real world
  • PoV Memo (2 pages max)
  • Go / no-go recommendation
  • If go: MVP scope + 6–8 week plan
Stop: If value is not measurable, it is not a PoV.
Section 6

Decision Gates

How AIDA prevents zombie projects. Three evidence-based checkpoints.

Gate 1

End of Discovery
Week 4

Go: Evidence Level 2+, measurable uplift, path to adoption, named owner team.
Kill: Data missing, doesn’t beat baseline, adoption unrealistic, ownership unclear.
Gate 2

End of MVP
6–8 weeks after Go

Scale: Runs reliably, impact repeats, monitoring exists, support model defined.
Pause: Impact fragile, operations manual, team can’t sustain without external help.
Gate 3

Scale Decision
Portfolio level

Invest: Value replicable across domains, reuse engineered, guardrails working.
Contain: Value is local. Scale would add complexity without proportional return.

Scale is not a celebration. It is an operating commitment.

Sections 7 & 8

Production & Governance

Ship the smallest product that keeps the value alive. Govern with guardrails, not gates.

MVP Delivery Checklist

  • Integration — only what is required for adoption
  • Monitoring — performance, drift, data quality, failure modes
  • Human fallback — what happens when the model is wrong?
  • Change management — workflow updated, not just informed
  • Ownership — who fixes it at 02:00 on a Monday?
Teams prove value, then “hand over to IT” and start a new pilot. That is how you create pilot factories. AIDA teams own the outcome through production.

Governance Guardrails

  • Data access tiers defined
  • Approved tool stack for discovery
  • Risk categories (low / medium / high)
  • Privacy & security requirements clear
  • Documentation minimums set
  • Escalation paths for exceptions
Replace steering committees with: weekly team demos, monthly portfolio reviews, quarterly strategy refresh.
Section 9

Vendor Discipline

Vendors are not the enemy. Dependency is.

Fit-to-Operate Test

  • Can we run it without the vendor in a realistic timeframe?
  • Do we have the skills to implement it properly?
  • Do we have the operating model to maintain it?
  • Do we have budget for the run, not just the build?
  • Will this make our teams stronger or more dependent?
If you can’t own it, don’t buy it.

How to Work with Vendors

  • Use vendors as tools in discovery, not architects of your future
  • Do not let vendors define the problem
  • Contract for knowledge transfer and internal capability
  • Prefer modular, reversible decisions
  • Avoid bespoke customization until PoV is proven
External help must reduce dependency over time. If dependency grows, stop.
Section 10

The AIDA Scorecard

What leadership should ask every month. Outcomes and capability, not theatre.

Lagging Indicators — Impact
Problems Solved
Which business problems improved because of AI & Data?
Problems moved from baseline to improved; adoption rate in workflow
Value Delivered
What measurable value appeared?
Revenue lift, cost reduction, cycle time reduction, quality improvement
Time to Value
How fast did we go from problem to measurable impact?
Median days from selection to proof of value; to production
Leading Indicators — Learning
Discovery Velocity
How quickly are we buying evidence?
Experiments per month; time per experiment; % killed early
Capability Built
What can we do now that we couldn’t do 90 days ago?
Reusable data assets; deployment maturity; internal skills
Dependency Reduction
Are we becoming more or less reliant on outsiders?
% changes requiring vendors; consulting spend trend; internal ownership

“Which problem did we prove value on this month?”

If the answer is vague, your program is vague.
Appendix

Templates

Copy-paste. Lightweight. Sharp.

A

Problem Brief

  • Problem (1 sentence)
  • User
  • Decision to improve
  • Baseline metric
  • Success threshold
  • Constraints / out of scope
  • Why now
  • Owner
B

Experiment Card

  • Hypothesis
  • Method
  • Data used
  • Comparator baseline
  • Result
  • Decision: continue / change / kill
C

Proof of Value Memo

  • 1. Problem + baseline
  • 2. What we tested
  • 3. Result vs baseline (numbers)
  • 4. Adoption signals
  • 5. Risks + mitigations
  • 6. Recommendation: go / no-go
  • 7. MVP plan (6–8 weeks)