The Three Horizons of AI, From the Product Development Seat

If you run product development at a mid-market B2B SaaS company, your board is already asking what your AI plan is. The honest answer most CTOs are giving sounds something like: "Adoption is jagged. Some teams are deep into Codex and Claude Code. Others are running pilots. A few engineers are getting real leverage out of it. We are tracking productivity gains." None of that is wrong. None of it is enough either.

The gap is not at the engineering level. It is at the leadership-team level. AI keeps getting prioritized as an engineering decision, when it is a business decision. It shows up on the engineering line item. It gets scoped against the same infrastructure-spend criteria the team applies to any other tooling investment. The conversation that should have happened across the leadership team about what AI does for the business, what gets built that could not be built before, and what the team has to stop doing to fund it, never quite happens. The board hears engineering speak about Copilot rollouts. The strategic horizons stay invisible.

I have been thinking about why this gap exists reading Anil Kumar's recent series on AI capital allocation at Alvarez & Marsal. His three-horizon framework is the cleanest articulation of the sponsor-side problem I have read this year. Anil writes for the Investment Committee seat. This article is the corollary for the seat where the work happens. The CTO, the VP Engineering, the VP Product, the Head of Product. The people whose name is on the AI plan.

The short version. Anil's three horizons are right at the capital level. They break down predictably inside the software development organization, in three different ways. Most companies are running all three at once without knowing it, which is why so many AI plans look busy on the inside and produce nothing the board can see.

---

The framework, in two paragraphs

If you have not read Anil's post, the short version. AI sponsors should fund three parallel horizons, not one. Horizon 1 is self-funding cost takeout in the first year. Horizon 2 is workflow re-architecture across years one and two. Horizon 3 is data and asset accumulation across the entire hold, starting at day zero.

Most companies fund Horizon 1 heavily, Horizon 2 partially, and Horizon 3 almost not at all. The exit math, Anil writes, is "strong margin expansion, weak multiple expansion, and a next buyer who prices all the gains as baseline." Every horizon is real. Most companies only run one of them.

---

Horizon 1: Tool rollouts. The horizon that looks like wins but rarely is.

Horizon 1 is supposed to be the easy one. Proven payback. Cost takeout. Anil cites 3-8% reduction of addressable cost base in twelve months for customer service and back-office. Inside software development, the math is harder.

The vendor pitch is straightforward. Roll out AI coding assistants. Developers go faster. Engineering velocity rises. EBITDA improves. The DX Q1 2026 AI-Assisted Engineering Impact Report, drawing on 135,000+ developers, found daily AI users save 4.8 to 4.9 hours per week. Roughly 22% of merged code is AI-authored. Those are real numbers.

The Faros AI Productivity Paradox report tells the second half of the story. 75% of engineers use AI tools. High-adoption teams complete 21% more tasks and merge 98% more pull requests. Pull request review time goes up 91%. The bottleneck moves. Across companies, Faros found no significant correlation between AI adoption and company-level performance.

That is the Horizon 1 trap. Individual developers are faster. The organization is not. The reviewer who used to handle four pull requests a day is now handling six, and the reviewer is the same person. The license shows up on the bill. The board does not see the speed because the company does not ship faster. Anil's "3-8% of addressable cost base" never lands on the P&L.

Horizon 1 inside the software development organization is real. It is also a workflow problem disguised as a tool problem. The CTOs who get it right do not start with the tool. They start by finding the bottleneck and asking whether AI can move it. If your bottleneck is code review capacity, your Horizon 1 move is not another assistant license. It is redesigning who reviews what.

---

Horizon 2: Rewiring the development lifecycle, not bolting AI on it.

Horizon 2 is the workflow re-architecture horizon. This is where Anil's framework moves from "AI bolted on" to "AI as the backbone of a redesigned process." Inside software development, this is the gap most companies are not closing.

The data is unambiguous. McKinsey's 2025 State of AI report tested 25 attributes that drive EBIT impact from generative AI. Workflow redesign was first. Tool adoption was not on the list. Only 21% of organizations using generative AI have redesigned at least one workflow. The other 79% are running AI on top of unchanged operating models. Google's 2025 DORA report reinforces it. 90% of developers use AI daily. The teams seeing real value are not the ones with the best tools. They are the ones with strong internal platforms and engineering cultures that already worked.

What does this look like inside a real development lifecycle? It is not adding AI to your existing requirements-to-merge cycle. It is redesigning what a requirement is when AI can draft, critique, and pressure-test the spec in the same hour the product manager wrote it. It is not adding AI to quality engineering. It is redesigning what quality is when generated tests can produce ten times the edge case coverage at a different cost structure. The development lifecycle you ran in 2024 is not the one you run in 2027.

Horizon 2 fails the same way every enterprise resource planning rollout failed. The CTO protects the org chart. The team layers AI on top of the current process. Six quarters later, the Horizon 1 wins are flat and there is no Horizon 2 to show for the spend. The reason is not that the technology did not work. It is that nobody redesigned the work.

---

Horizon 3: Building product value that did not exist before.

Horizon 3 is the horizon most software development plans starve. Anil calls it data and asset accumulation. Inside the development organization, it is what your product becomes worth more for because AI now makes it possible. Not faster versions of the existing product. New value the product creates for customers, new defensibility against competitors, new asset value at exit.

Better customer data and the products it powers.

The telemetry your product produces every day, the support tickets, the customer interaction logs, the engineering activity, the deployment patterns. Most of it is captured for incident response and then deleted. Two years from now you will wish you had kept five years of it in a form a model can read. The CTOs investing in Horizon 3 today are building the data foundation for product features that compound the customer relationship: better onboarding, smarter retention, predictive recommendations the competition cannot replicate.

Competitive insights you could not surface before.

Customer behavior patterns that take hundreds of hours to identify manually. Feature usage drift. Subtle regressions in product quality that would have hidden inside aggregate metrics for two more quarters. Market signal pulled from your own data faster than your competitors can pull theirs. The capability is not "use AI to write a query." It is to know what your customers and your market are doing while your competitors are still scheduling the next quarterly review.

Product work you would not have staffed before.

Quality investigations you would not have funded. Customer success programs you would not have scoped. Engineering investigations that were always on the wishlist and never on the roadmap. The point is not to do the same work faster. It is to do work the business had previously decided was not worth the headcount, which now adds to the product and to the company's defensibility.

This horizon is the one that shows up at exit and never before. Your Horizon 1 cost takeout will be priced as baseline by the next buyer. Your Horizon 2 workflow redesigns will be the cost of staying in business. Horizon 3 is what they pay a premium for. The CTO who starts Horizon 3 instrumentation at year one of the hold builds an asset. The CTO who waits until year three is funding a sprint that will not ship in time.

---

The diligence question your next buyer is going to ask

Anil closed his series last week with a five-question AI diligence framework for sponsors entering at the indication-of-interest or letter-of-intent stage. Question five is the one that matters most for software development: "Does the operating organization actually use AI in decisions, or does it have AI tools?"

The honest answer for most companies right now is "we have AI tools." The deeper question is whether your team's actual work has changed. Does your sprint planning meeting run differently now? Do your design reviews surface different conclusions than they did a year ago? Does your roadmap include things you could not have built before? If the answer is no, you have not crossed into Horizon 2 or 3 yet. Your AI work is decoration. Your next buyer will price it that way.

The next buyer is going to run this diligence on you in eighteen to thirty-six months. The CTOs who get ahead of it run it on themselves first.

---

The AI Trajectory Audit

This is the question the AI Trajectory Audit is built to answer for the CEO. Where do you actually stand on AI inside your software development organization, where will you be in six months at the current trajectory, and what three specific moves change it?

You get a defensible position you can walk into a board meeting with. You get a six-month projection that is not flattery and is not panic. You get three named moves, each tied to one of three measures that matter to a software development organization: quality, cycle time, or unit cost. You get a board paragraph in your own voice.

The Read is built around eight questions every CEO of a mid-market software business should be able to answer about AI in product and engineering. Most cannot answer them cold. That is the diagnostic.

1. Could you give your board a defensible answer right now on why AI is in your investment thesis, what outcomes you have committed to, and what you are choosing not to do to fund it?
2. Do you have one to three AI initiatives in flight right now with named owners, named business outcomes, and visible progress?
3. Are those initiatives tied to specific business outcomes your board would recognize as material (revenue, margin, retention, cost to serve), or are they running as their own line of work?
4. Is the work coordinated to produce system-level gains across product and engineering, or are individuals getting faster while the system stays flat?
5. Do the people running AI work have the space and resources to execute, or is the work stacked on top of existing commitments?
6. When AI work hits organizational friction (approvals, security review, data access, conflicting priorities), does the team have a way through, or does the work stall?
7. When an AI experiment works in one team, does the company capture the learning and compound it, or does the win stay where it happened?
8. Is the person driving AI in product and engineering telling you the wins, the misses, and the don't-knows directly, or are you piecing it together from other signals?

If you can answer all eight without prep, you do not need the Read. Most CEOs cannot, and the gap between what you believe and what your team is actually doing is what costs the multiple at exit.

---

Close

The strategy is the easier half of the work. The harder half is the operator who shows up Monday morning and makes the plan real. That is the bar AI plans need to meet now. Anil's framework gives you the right capital question. The software development organization has to answer the operator question. Both halves have to be true.