Several portfolio companies I work with have come to the same realization at different points in their AI deployments. The capability they thought was their competitive advantage was the same capability their competitors had bought from the same vendor. Strategy that gets evaluated as procurement misses what matters. The framework below is the one I use to surface this kind of dependence before it becomes a structural problem, and to evaluate AI investments as the architectural decisions they actually are.
Each lens answers a different question. Each produces a different output. Skipping ahead is the most common failure mode.
The lenses are sequential. Opportunity precedes Readiness precedes Deployment. Skipping ahead is the most common failure mode.
Most AI evaluations don't fail because the technology is wrong. They fail because they answer the wrong question first, or treat one question as if it were three. Four patterns recur in the engagements I run.
Companies that start at Deployment. "We need a RAG system." "We should fine-tune." "We need agents." The technology choice precedes the question of whether the business needs the capability at all. The infrastructure gets built. The opportunity never gets named. The investment compounds the wrong way.
Companies that score readiness with a composite. A 5 in technology and a 1 in governance averages to a 3, which suggests the company is doing fine. Composite scores hide the binding constraint. The 1 blocks everything. The shape of the maturity profile matters more than the average ever will.
Companies that treat opportunity as a list. Without a dominant thesis, the opportunity longlist accepts everything that scores plausibly. Bottom-up with no thesis becomes 23 candidate use cases. Top-down with no operator input becomes a strategy document nobody implements. The portfolio comes from running both against the thesis.
Companies that produce strategy documents. Most "AI strategy templates" produce shelfware. Strategy that doesn't end in a defended portfolio, a named binding constraint, and a deployment archetype per pilot is a document, not a strategy. The framework should produce decisions, not artifacts.
Three lenses, kept separate, produce decisions. Conflated, they produce slides.
Each lens has its own classification, its own evaluation metrics, and its own decision set. Output of one lens feeds the next. Skip a lens and the whole sequence loses integrity.
Where in this business could AI move a P&L line, and which of those places matter enough to pursue?
Five archetypes structure the answer: revenue expansion, cost compression, quality and risk, decision velocity, capability creation. Every candidate use case fits one. Mixed-archetype use cases are usually two opportunities pretending to be one.
Can this company actually execute on the opportunities the first lens surfaced?
Five pillars structure the answer: data, technical infrastructure, talent, governance, organizational. The point isn't to score comprehensively. The point is to identify the binding constraint. Most companies have one. Until it's named and addressed, every other investment under-converts.
For an opportunity that has cleared the first two lenses, how should the technology actually be deployed?
Four dimensions structure the answer: build/buy/partner, API-first/self-hosted, embedded/standalone, single-provider/multi-provider. The combinations produce six common deployment archetypes. Each demands its own kill and success criteria.
A new portfolio CEO told me her AI capability used to be a competitive advantage. Two years of customer-facing workflows had been built on one horizontal AI platform. Strong adoption. Strong outputs. The deployment had been treated as a tooling decision.
DiscoveryShe'd come to realize it was a vendor's product roadmap. What surfaced when we walked it through: the platform was doing the same work for two of her company's direct competitors. The vendor's roadmap was the capability ceiling. Whatever the vendor didn't ship, the company couldn't do. Switching cost had compounded silently. Two years of integration had made the implied exit cost roughly 18 months of engineering. Differentiation was leaking quarter by quarter. Whatever the vendor enabled her company to do, it enabled the competition to do, in the same quarter.
OutcomeThe fix wasn't ripping the vendor out. It was naming what was vendor-owned, what was company-owned, and what needed to migrate before the next opportunity required it. None of this was caught at procurement. It would have been caught at deployment review.
Yes or no for the AI portfolio you're committing capital to. Two questions per lens. Take it as a CAIO answering for your own org, or as an operating partner answering for a portfolio company. The questions are blunt by design. If the honest answer is yes-but, it's a no.
Running the three lenses isn't a strategy exercise. It's a decision exercise. Three artifacts come out of a complete pass through the framework. Each one belongs in the IC memo or the board pre-read, not in a separate technical appendix.
Each opportunity gets a magnitude, a time-to-signal, a defensibility rating, and an adoption-risk score. The ranking sequences them by the thesis the portfolio is being optimized for. The list is a portfolio, not a wish list.
One pillar gets called out as the gating issue. The rest get triaged. The plan to clear the constraint comes with quarter-level milestones and a real capital number, not a directional estimate. Most companies miss this step.
Each active deployment is tagged with one of six archetypes. Each has a measurable kill criterion (the condition under which it shuts down) and a measurable success criterion (the threshold that triggers scaling). Both pre-committed before launch.
Opportunity sets the ambition. Readiness sets the constraint. Deployment sets the path. Run them in sequence.
If you're committing capital to AI without running the lenses in sequence, I'd be glad to talk. More on technical and product due diligence for PE deal teams.