Pressure-Testing AI Initiatives

The story

Consider a product portfolio review at a financial services firm. Twelve AI initiatives are on the table for next-quarter funding. Each has a deck. Each has a sponsor. Each claims clear value. The CFO asks the head of product to rank them. She picks her top three and defends them with intuition and recent customer conversations.

The ranking turns out to be wrong. Two of her top three die in production within 6 months — one because the regulatory team raised concerns that nobody had pressure-tested before the build (Ethics failure), one because the unit economics didn't survive contact with realistic usage volumes (Viability failure). Both initiatives had strong Customer Value claims and clear Feasibility paths. They died on the dimensions the team didn't measure systematically.

The fix isn't better intuition. It's a systematic pressure test run before any initiative consumes engineering time. The CAPTURE framework is the discovery-to-investment bridge — the gate that turns "this idea sounds good in the deck" into "this idea has been pressure-tested across the five dimensions where AI initiatives actually die."

Consider a second team that builds an AI-powered fraud detection feature. The Customer Value is clear (banks lose billions to fraud). The Technical Feasibility is clear (the model works on historical data at 92% accuracy). The team ships. Within 4 weeks, customers complain about false positives that block legitimate transactions. The fraud team that was supposed to use the AI escalates more cases to human review than they did before — because the AI's flagging style doesn't match how human investigators triage. The Usability dimension was never pressure-tested. The team optimized for technical accuracy and missed how the output integrated into the actual investigation workflow.

Consider a third team that proposes an AI assistant for medical chart review. Customer Value strong, Feasibility strong, Usability strong. The Ethics review surfaces a problem: training the model on the firm's chart corpus would require patient consent the firm doesn't have for the existing data, and obtaining retroactive consent is not feasible at scale. The Ethics lens kills the initiative. The team frees up the budget for a different initiative that doesn't have the same data-consent problem. The kill is the right call. Without the Ethics pressure test before engineering committed, the team would have spent 4 months building something the firm couldn't legally deploy.

Three teams, three failure modes, one shared lesson: AI initiatives die from Viability, Usability, or Ethics failures more often than from Feasibility. Teams that only pressure-test Feasibility (the engineering question) ship initiatives that die in production for reasons no one tested. CAPTURE is the discipline that prevents this.

The core idea

CAPTURE adapts Marty Cagan's product discovery framework — Value, Usability, Viability, Feasibility — for AI products by adding Ethics as a co-equal fifth lens and operationalizing each lens with AI-native amendments. The five lenses:

The CAPTURE framework is the gate before the 1-week prototype sprint from L1-T05. Not every initiative deserves a prototype. CAPTURE filters which initiatives earn the investment.

The concept — visualized

The five lenses in detail

Lens 1: Customer Value. Does the user get measurable value? The AI-native amendment: pair the value claim with the Indispensability Index from L1-T03. Customer Value is strong if the workflow can't go back to pre-AI without measurable cost. Customer Value is weak if users would like the feature but their workflow doesn't restructure around it. Test with the will-they-keep-using-it lens from L1-T05's pretotyping discipline. Surveys are not evidence at this lens; observed workflow restructuring is.

Lens 2: Adoption (Usability). Will the user actually adopt the AI in their real workflow? The AI-native amendment: test with the user's actual data, in the user's actual environment, with the user's actual time pressure. Most AI features fail Adoption because the demo conditions don't match production. The fraud detection story is the canonical pattern: 92% accuracy in the lab, escalation rate climbs in production, because the output style doesn't match human investigators' triage. The discipline is dogfooding with target users in realistic conditions before the budget commits.

Lens 3: Pricing (Viability). Do the unit economics work at scale? The AI-native amendment: model cost per outcome at projected scale, not pilot scale. Cursor's $7,225 invoice happened because the per-seat pricing assumed pilot-scale usage; power-user usage at scale broke the unit economics. Test the pricing against the projected P90 user, not the average user. If the P90 cost per outcome breaks the margin, the pricing model is wrong before the product ships.

Lens 4: Technical feasibility. Can the model + harness deliver the required quality, latency, and reliability? The AI-native amendment: this is where the harness mastery from L1-T01 lives. Feasibility is not just "does the model work" — it's "does the harness deliver reliable autonomous outcomes at the volume and complexity the use case requires." A 92% accuracy on benchmark data is necessary but insufficient. The full feasibility test includes Context Durability, Intervention Rate, and Self-Optimization Rounds metrics. If the team can't run those experiments in pilot, the Feasibility lens is incomplete.

Lens 5: Unit economics + Risk + Ethics. Three sub-dimensions in one lens because they share a common structure: they all surface failure modes that aren't visible in pilot.

The Ethics sub-lens is the one most teams skip. The teams that skip it ship initiatives that get pulled in production review or by regulators. "We'll figure out the ethics later" is the most expensive sentence in AI product management.

Where this hits in production

The discovery-to-investment bridge is operational, not philosophical. A well-run CAPTURE review runs in 5–10 days, includes representatives from product, engineering, design, finance, legal, and (where applicable) compliance and ethics. The output is a 1-page CAPTURE scorecard plus a go/no-go decision. The friction is the feature — most initiatives that score below 3/5 on any lens get killed or sent back to discovery. Only initiatives that pass all five lenses earn the 1-week prototype sprint from L1-T05.

The Klarna mixed AI story is a multi-lens diagnostic. The 2024 announcement (AI replaces 853 FTEs) shows strong Customer Value and Pricing claims. The 2025 reality (re-hiring humans for nuance) suggests the Adoption lens — specifically, will-they-actually-use-it-as-the-only-channel — was weaker than the headline. A multi-lens CAPTURE review would have surfaced the workflow restructuring question earlier and would likely have produced a more nuanced rollout plan.

The Apple Intelligence pattern is a multi-lens success. All five lenses are addressed in the public architecture: Customer Value (deep workflow integration), Adoption (the user doesn't have to adopt anything new — Intelligence sits inside familiar apps), Pricing (monetization through device margin, not per-token), Technical Feasibility (Stateless AI + Private Cloud Compute), Ethics (PCC's privacy architecture as the explicit answer to the Ethics lens). The architecture was the CAPTURE scorecard.

The cost of skipping CAPTURE compounds. Teams that ship without a multi-lens review usually discover the missing lens in production — at which point the cost of fixing it is 10–100× higher than catching it in discovery. The 4-month bespoke assistant from L1-T02 is the public version: a Feasibility-only review missed the durability question (Ethics lens, in the form of "will this be obsolete in 6 months when the API expands?"). The fix would have been a CAPTURE review that included a durability question.

The trap

Trap 1: Skipping the Ethics lens. The Ethics lens feels abstract until it kills an initiative. The fix is to make Ethics a co-equal lens with Feasibility — same review process, same documentation, same kill authority. Most teams that skip it learn the cost in production, not in discovery.

Trap 2: Running CAPTURE as a checkbox. A scorecard with five fives doesn't mean the team passed. It means the team didn't pressure-test hard. The discipline is to try to fail each lens — bring the most skeptical voice from each function (legal for Ethics, finance for Pricing, design for Adoption) and let them stress-test.

Trap 3: Treating Feasibility as the only "real" lens. Engineering-led teams default to Feasibility. The 95% of failures aren't Feasibility failures. They're Adoption, Pricing, and Ethics failures. The CAPTURE review's value is forcing attention on the lenses the team would otherwise underweight.

Trap 4: Running CAPTURE too late. CAPTURE happens before the prototype, not after. Once 1-week prototype sprints have started, CAPTURE becomes documentation theater. The discipline is gate before invest, not gate after invest.

Remember this

In practice

Step 1: Build the CAPTURE review template. A 1-page scorecard with the five lenses, scored 1–5, plus a one-paragraph evidence note for each lens. Template includes: the customer (specific persona), the value claim (numerical, time-boxed), the adoption test (how was this validated with real users in real conditions), the pricing model (with projected-scale unit economics), the feasibility test (model + harness, with evidence), and the ethics review (data consent, regulatory exposure, model-behavior risk).

Step 2: Schedule a CAPTURE review for every initiative before prototype investment. 5–10 days, cross-functional. Product, engineering, design, finance, legal, compliance, and (where applicable) ethics. The output is a go/no-go decision, not a prioritization vote.

Step 3: Bring skeptics to each lens. Finance for Pricing. Design for Adoption. Legal for Ethics. Engineering for Feasibility. The skeptics' job is to try to fail their lens. The lens that fails is the next workstream — either fix it or kill the initiative.

Step 4: Document every CAPTURE review in a central registry. Six months later, run a retrospective: which lens predictions held up? Which were too soft? The retrospective tightens the team's CAPTURE craft over time.

Step 5: Translate CAPTURE outcomes into leadership language. Leadership doesn't read scorecards. Translate: "This initiative passes Customer Value and Feasibility but fails Pricing at projected scale and has unresolved Ethics exposure on data consent. Recommendation: send back to discovery with two specific workstreams — pricing redesign and data consent path." The translation makes the CAPTURE review a defensible artifact in budget conversations.

The practice — visualized

References