If your AI roadmap is a list of demos, you have a hobby, not a strategy.
Every team I have seen ships a chat assistant or a summarize button in month one. Value is real. So is the trap: two years later, the same team is still shipping bolt-ons, and every one of them costs the same as the first.
At InMobi I own the system of record under a demand-side platform and an ad exchange that clear 200M+ devices’ worth of events a day. At Pixis I ran the platform team behind an AI creative product from $0 to $10M ARR in five months. Both jobs taught me the same lesson from opposite ends: the AI that compounds is the AI you built infrastructure under, not the AI you demoed loudest.
So that’s today’s post.
Today’s Post
Why bolt-on AI stalls, what a platform actually buys you, and how to tell which stage you’re really in.
- Why AI as a feature is the trap almost every team walks into on purpose
- Why AI as integrated capability changes the question you ask
- Why AI as platform is what makes the tenth feature cheaper than the first
- How to score your maturity on evidence instead of a slide
- Why a roadmap that compounds asks one question before every bet
- Why the data flywheel only spins if you design the loop on purpose
- Why readiness is people and process, and culture is the hardest one
- Why models commoditize but moats do not
1. AI as a feature is the trap almost every team walks into on purpose
The first wave is always bolt-on AI: a chat widget, a summarize button, a “magic” badge on the release notes. It is easy to ship and easy to demo in a QBR.
It is also easy to get stuck there. Bolt-on features sit beside the core workflow instead of inside it. Nobody owns a quality metric tied to an outcome. Three different squads quietly integrate three different vendors, and the company calls that “moving fast.”
I watched this pattern up close at Pixis. When I picked up AdRoom, the pitch from the company was “AI makes ads faster.” I did not believe that was the real constraint. Generation was already cheap. The actual bottleneck was the approval queue, a designer and a brand check standing between a marketer and a live ad.
A feature proves appetite. It does not prove a strategy. The question that separates the two is simple: what do you get to reuse the next time?
2. AI as integrated capability changes the question you ask
Integrated AI reshapes a task that already exists, instead of sitting next to it. At Pixis that meant AdRoom’s editor: marketers manage projects and edit layers where they used to file a design ticket, with generation happening underneath, not as the headline.
The bet worked on numbers, not vibes. Four automotive and consumer-tech brands ran a two-week onboarding sprint, and we instrumented activation, meaning a live on-brand ad, and ignored logins. That sprint produced $800K ARR in two months; the full motion went $0 to $10M ARR in five months with a 20-person team.
Integration also forced a harder discipline than the feature stage did. Success had to be defined in task terms, not model terms: designer load, not “AI usage.” Fallbacks had to be part of the flow, because a marketer without a designer still needed a way out when the model got it wrong.
We enforced brand guidelines, fonts, color, logo rules, at generation time, not after. That single decision is the reason graphic-designer load dropped 80% and the manual QA gate disappeared entirely, instead of just moving the bottleneck one step downstream.
The team’s question changed from “what can the model do” to “what bottleneck in this workflow should disappear.” That question is what connects AI work to the rest of your roadmap.
3. AI as platform is what makes the tenth feature cheaper than the first
Platform means shared foundations: model access, evaluation harnesses, logging, safety policy, cost dashboards, reusable patterns. Not a slide titled “AI Platform.” Constraints that make the next team’s ship faster than yours was.
My first mandate at Pixis was not the AI layer at all. It was the Data Platform and Execution Engine underneath it, a 12-person pod with an unglamorous thesis: reliability is the product. We set SLAs, automated validation, and treated data freshness as a feature with a target.
That platform ended up processing 1M+ keywords a day for 400+ enterprise customers at 99.6% end-to-end sync reliability, with availability delays cut from 4 hours to under 15 minutes. None of it demoed well. All of it is why Advance, the optimization layer riding on top, could ship confidence-scored recommendations that a buyer would actually trust with real spend.
Platform work also meant unsexy integration debt somebody had to own: I stood up billing through Stripe, and ran the evaluation of measurement partners like AppsFlyer for the MMP layer the whole product feeds on. If every squad wires its own version of that, you do not have a platform. You have expense and risk wearing a platform’s name tag.
4. Score your maturity on evidence, not a slide
Strategy meetings love labels: “we are platform-ready,” “we are AI-native.” The useful work is diagnosis, and diagnosis only works on evidence.
Ask your org four questions, and answer with a number, not an adjective. Do you have instrumented features, or demos with vanity metrics? Do you have shared eval assets, or five teams each rebuilding the same spreadsheet? Do you have a repeatable launch checklist covering safety and privacy, or a scramble the night before? Do executives fund the unglamorous foundation work, or only the visible widget?
If the honest answers embarrass you, that is the starting line, not a verdict. The InMobi close is the version of this I trust most: the target for the close, days from month end to a signed number, got written down before the number moved, and finance re-measures it twelve times a year whether anyone asks or not. Borrow that cadence for anything you are trying to call a platform.
5. A roadmap that compounds asks one question before every bet
A compounding roadmap answers: what do we get for free next time if we do this now? Instrumentation first is the clearest example. Without logged prompts, outputs, and accept-or-reject signals, you cannot evaluate, price, or improve anything honestly.
Shared eval sets are the asset that survives model churn, which matters more than it sounds, and I will come back to why in section 8. A content and retrieval architecture that serves three features instead of one prompt hack is a compounding bet. So is a design pattern for confidence and review that makes every new AI surface feel consistent instead of hand-built.
The Pixis sequence is the compounding version in practice. The Data Platform came first and was not optional; Advance’s optimization only had somewhere to stand because the reliability number was already 99.6%. Non-compounding bets, a spike, a one-off prompt hack, are fine as learning exercises. They are a trap as a permanent style, because a roadmap that is only a list of demos never builds the shared foundation the next demo needs.
6. Why the data flywheel only spins if you design the loop on purpose
The flywheel story is familiar: more usage produces signal, signal improves the system, improvements attract more usage. True in principle, easy to fake in a deck.
What actually spins the wheel is purposeful capture, not passive hoarding: asking for a correction, not just watching a thumbs-up. At Pixis, Prism ran 15+ voice-of-customer interviews per launch and turned them into exactly five roadmap features, not fifty. The discipline was saying no to the other forty, and that discipline is what made the signal usable instead of a pile of unread transcripts.
Prism’s own funnel proves the same point from the outcome side: +25% trial-to-paid and -40% onboarding time came from treating the proof-of-value motion, demo accounts, an ROI calculator, walkthroughs, as the experiment, not as marketing collateral bolted on after the product shipped.
Closing the loop matters as much as opening it. If users never see their feedback change anything, they correctly assume you mined them instead of listened to them. PMs own that closure. Nobody else on the team is positioned to.
7. Readiness is people and process, and culture is the hardest one
Technology without organizational readiness produces pilot theater: an impressive demo with no durable owner. Readiness has three parts, and only one of them is hard to fix.
Skills and process are the tractable two. Pixis’s 12-person data platform pod is a skills answer: product, engineering, and data people who could run evals and read incidents together, not one lone “AI person” carrying the whole thing. SLAs and automated validation are a process answer: a launch review that includes a safety and reliability check is a process, not a hope.
Culture is the one that actually decides whether any of this survives contact with a bad quarter. A hype culture rewards demos and punishes maintenance. A professional culture rewards eval coverage and incident reduction the same way it rewards a launch. Your own roadshow is a good test: does it celebrate the reliability number, or only the feature count?
8. Why models commoditize but moats do not
Models will keep improving, and that does not remove your job. It raises the bar for everything that is not the model: workflow fit, data, trust, operations.
This site is its own small proof. The Ask AI feature here runs on Gemini through a single catalog file that the route, the browser client, and the model picker all read from, because the model underneath is not stable ground to build on directly. gemini-2.5-flash shows up in the live model listing marked “no longer available to new users.” gemini-3.5-flash and gemini-3.6-flash are both live in that same listing and both return a bare 404 the moment you call them. The free tier caps at 15 requests a minute, shared across every visitor to the site, not per visitor. None of that is hypothetical; it is what the catalog file exists to absorb so a feature written against one model does not break on the next one.
That is commoditization at the scale of one personal site. At company scale, the same pressure shows up as regulatory expectations tightening around transparency and data handling, and unit economics returning to the center of the conversation as usage grows. None of it removes the need for a moat; it just moves where the moat has to live.
Three anti-patterns dress themselves up as a moat and are not one. Vendor shopping without eval discipline buys you a new logo and the same uncertainty you had before. A demo roadmap optimizes for applause in the QBR while skipping logging and failure design. A hiring-spree narrative assumes ten new ML hires substitute for a system, when they usually substitute for clarity about what the system should have been.
The real moat is workflow integration a competitor cannot copy in a weekend, proprietary data and feedback loops you are legally allowed to use, and an operational track record: lower incident rate, faster iteration, a lower cost per successful task. “We use AI” is not a position. “We cut this close from five days to twelve hours” is.
Takeaways
Eight sections, one ladder. The test to run this week: pick your last AI feature and ask what it left behind for the next one.
Final Words
AI strategy, for a PM, is product strategy with sharper externalities and faster tooling churn. The organizations that win will not be the ones most dazzled by the newest model. They will be the ones most disciplined about what they build once and reuse ten times.
Pick the last AI feature your team shipped. Ask what it left behind, an eval set, a logging pattern, a piece of the platform, or nothing at all. Reply and tell me which one it was.
Cheers, Hoshank