Part of the "AI Leadership in the Real World" series: how leaders turn AI from scattered pilots and executive excitement into governed, adopted, measurable business capability.
TLDR: 60 ideas on a board. 4 product teams to build them. $1.2M in annualized run cost for pilots that produced $340K in measurable value.
The week we made tradeoffs visible was the week AI stopped being a budget line item and started being a product strategy.
My AI backlog looked like a menu with 60 "top priorities" and no kitchen to cook them.
Every function had a smart idea.
Every idea came with urgency and a sponsor.
Customer support wanted a deflection chatbot.
Engineering wanted a code review assistant.
Sales wanted lead scoring.
Operations wanted anomaly detection.
HR wanted resume screening.
Finance wanted invoice reconciliation.
Each one was a good idea.
That was the problem.
When every idea is good, prioritization becomes political.
The loudest pitch keeps winning.
People start optimizing for being seen, not for being useful.
And the organization quietly trains everyone to be louder.
I run a product P&L.
I do not have the luxury of treating every good idea as a funded initiative.
My job is not to maximize the number of AI pilots.
My job is to maximize the return on the engineering capacity, infrastructure budget, and organizational trust I have been entrusted with.
Those are finite.
Every pilot I approve is a pilot I cannot fund somewhere else.
Every dollar of inference cost is a dollar that did not go to a product feature, a reliability improvement, or a person.
We were treating AI like a lottery ticket instead of a managed investment.
The P&L was telling us that before I was willing to listen.
What Changed: The Cost of the First Prototype Collapsed Two years ago, prototyping an AI use case took weeks — data pipeline, model, inference endpoint, UI, deployment path.
The cost itself was a prioritization mechanism.
Only ideas that survived a viability check got built.
That barrier is gone.
Today, a prompt, an API key, and an afternoon get you a working demo.
A LangGraph agent can be built in an evening.
A RAG pipeline can be running by lunch.
This is great for product.
I can test a hypothesis before writing a quarterly business case.
A product manager can answer "would this help our users?" in days, not months.
But it also means the filter is gone.
Now every idea can get a prototype, every prototype a demo, every demo enough excitement to justify keeping it alive.
And every live pilot has a run cost: API calls, cloud infrastructure, developer attention, security review cycles, roadmap slots.
The prototype is cheap.
The pilot is not.
The production system is expensive.
The distance between those three stages is where most AI budgets quietly bleed out.
HBR Noticed the Same Pattern I started seeing this pattern in my own portfolio before I saw it in print.
Then HBR published three pieces in six months that described exactly what I was living through.
In November 2025, Goutam Challagalla, Mahwesh Khan, and Fabrice Beaulieu (IMD/BCG) published "Stop Running So Many AI Pilots".
Subtitle: "Instead of testing lots of use cases across the company, pick one area and go deep." They used Reckitt as their case study.
Reckitt found use cases spanning the business — presentations, customer support, procurement.
Each guaranteed time savings.
But the executives realized "the effort wouldn't transform the company's strategy or create a meaningful advantage.
They were hoping for something more dramatic, not just marginal efficiency improvements." That sentence hit me.
We had pilots that worked, saved time, produced decent demos.
But they were not changing the product.
They were making the same product slightly faster.
The same month, Ania Masinter published "Prioritizing AI Investments That Create Real Value" as an HBR Executive Playbook.
Her argument: "It's time for companies to move from experimentation to disciplined, focused investment in AI." She referenced the 2025 Wharton-GBK AI Adoption Report on executive pressure for AI ROI.
That pressure is not theoretical — I feel it every quarter.
Then in January 2026, Faisal Hoque, Erik Nelson, Tom Davenport, and Paul Scade published "Manage Your AI Investments Like a Portfolio".
Their framing: "Business leaders now face intense pressure to transform their organizations with AI, even though the technology, public attitudes, and the competitive landscape are all still in flux.
The result is often too many pilots with too little coordinated oversight." They cited an IBM study finding "isolated, piecemeal deployments," a Deloitte report on "limited buy-in by senior executives," and McKinsey's State of AI 2025 finding "weak linkage to strategic goals." Three articles.
Three author groups.
One diagnosis: too many pilots, too little oversight, too little connection to strategy.
The Question That Changed How I Think Larry Page, co-founder of Google, famously said: "Put more wood behind fewer arrows." The phrase is sometimes attributed even earlier to Scott McNealy, co-founder of Sun Microsystems.
The idea is old and simple: when you have limited strike capability, concentrate resources on fewer bets so each one hits harder.
The opposite is the scattergun: build lots of small arrows, fire them all, hope something sticks.
In AI, that means launching pilots across every department, demoing them all, declaring whatever survives as "the strategy." It feels productive — your board sees activity, your teams feel empowered.
But every live pilot consumes maintenance, infrastructure, security review, and trust.
A pilot that does not get retired becomes a permanent tax.
And it fragments your roadmap — you cannot ship a coherent product when engineering is maintaining six pilots that were never supposed to become products.
The question is not whether you should experiment.
You should.
The question is whether you experiment to explore — cheap and healthy — or to avoid committing, which is expensive and corrosive.
I do not think there is a universal right answer.
There is the answer that fits your capacity, your P&L, and your market's window.
The Framework That Helped: GIST I did not invent the portfolio model from scratch.
I borrowed from GIST — Goals, Ideas, Step-Projects, Tasks — a framework created by Itamar Gilad during his time at Google.
The piece that matters for this conversation is the transition between Ideas and Step-Projects.
Ideas are a hypothesis bank.
Everything goes in.
Nothing is committed.
The low cost of AI prototyping makes this stage richer than ever — you can test more hypotheses in a week than you used to in a quarter.
That is the advantage.
Step-Projects are the gate.
Small, timeboxed experiments with a measurable question and a kill criterion.
An idea only becomes a step-project when it has a hypothesis, an owner, and a metric.
The prototype proves technical feasibility.
The step-project proves it is worth scaling.
That transition — from idea to step-project — is where most AI portfolios fail.
The prototype is cheap, the demo is impressive, and the idea skips the gate and goes straight to production.
GIST forces a different discipline: scaling is earned at the step-project gate, not granted at the demo.
I am not claiming we adopted GIST wholesale.
We borrowed the principles and adapted them to an organization with monthly planning, security review cycles, and a finance team that wanted ROI narratives.
But the core insight — ideas are hypotheses, experiments are gates, scaling is earned — is what made the portfolio work.
Two things nobody tells you about the gate There are two problems I see teams hit at the step-project gate that GIST does not fully solve on its own.
Both are culture problems dressed up as process problems.
How much do you build to test the hypothesis?
This is the question I get asked most.
Some teams build too little — a thin wrapper around an API call that cannot answer the actual question.
Some teams build too muc