Prototype to learn. Clarity before commitment.
Why the Innovation Accelerator exists: to get enterprise ideas — especially AI ideas — to shared clarity before we trigger the full weight of the product, legal, security, and integration machinery.
In enterprises, the expensive part of building the wrong thing is no longer the engineering — it's the product time, the cross-team coordination, the legal and security reviews, and the system integrations that surround it. AI features make this worse, because they can't be safely A/B tested in production with real data. A working prototype, produced early, is the cheapest instrument we have for getting to shared clarity before any of that machinery is triggered.
A prototype is the fastest path to shared understanding.
Documents, decks, and Figma flows produce agreement on words and pictures. A working prototype produces agreement on the thing itself — and surfaces the disagreements while they're still cheap to resolve.
Documents and mockups produce the illusion of alignment. A working prototype forces the disagreements into the open — while they're still cheap to resolve.
Cagan's long-standing argument: most product waste comes from committing to solutions before the team has evidence they are valuable, usable, feasible, and viable. Discovery exists to answer those questions cheaply, before delivery is triggered.
- Key idea: separate discovery (learn) from delivery (build).
- Prototypes are the cheapest instrument for the four risks — value, usability, feasibility, viability.
- Our takeaway: our operating model is a concrete instantiation — Discovery → Rapid Prototype → Validation before Handoff.
Torres frames discovery as continuous assumption testing against an opportunity–solution tree. The point of a prototype is not to demo a feature; it is to expose the riskiest assumption to reality as quickly as possible.
- Key idea: prototypes are structured experiments against named assumptions.
- Teams that skip explicit assumption testing default to building the first plausible solution.
- Our takeaway: 'prototype as instrument for learning' is exactly this discipline, done in working software instead of sticky notes.
In an enterprise, engineering is the tip. Everything else is the iceberg.
When the organization talks about the cost of a feature, it usually pictures engineering. In reality, most of the effort behind any shipped feature is product time, coordination across workstreams, legal and security review, integrations, and stakeholder approvals. Building the wrong thing burns that scarce capacity — not just dev hours.
The "AI cost" conversation usually centers on engineering. In enterprises, engineering is the smallest slice. Building the wrong thing burns the coordination, review, and integration budget — the parts we can't easily scale.
Pendo's analysis of aggregated product usage data found roughly 80% of features in the average B2B product see little to no use; the classic Standish CHAOS finding put 'rarely or never used' at about 64%. Every one of those features consumed product, design, engineering, legal, security, and coordination time.
- Key finding: majority of shipped features generate near-zero user value.
- Cost is not just engineering — it's the entire enterprise pipeline that shipped it.
- Our takeaway: the cheapest feature is the one you don't build. Prototype-to-learn is a bet against that waste.
Hamel and Zanini quantify the drag of enterprise coordination — meetings, approvals, handoffs, alignment — at trillions of dollars annually. The point is not that coordination is bad; it is that spending it on the wrong bet is where the waste actually compounds.
- Key idea: in large enterprises, coordination cost dwarfs build cost.
- Every feature that reaches delivery has already burned product, legal, security, integration, and stakeholder time.
- Our takeaway: prototypes let us spend that scarce coordination budget on the bets we already know are worth it.
You can't safely A/B test an AI feature in production.
A/B tests assume stable, deterministic variants and low-risk exposure to real users. AI features are probabilistic, drift over time, and carry data and reputational risk that legal and security correctly require to be managed up front. That means the cheap learning has to happen before the AI risk pipeline is triggered — in a prototype, with sponsors and target users, not in the market.
NIST's framework treats AI systems as fundamentally different from deterministic software: outputs are probabilistic, behavior drifts, and harms are context-dependent. Governing, mapping, measuring, and managing risk becomes an ongoing lifecycle activity — not a pre-launch checkbox.
- Key idea: AI systems require continuous risk management, not one-time QA.
- Standard A/B testing assumes stable, deterministic variants — AI features violate that assumption.
- Our takeaway: for AI features, the cheap learning has to happen before the risk pipeline is triggered — in prototype, not production.
The canonical paper on ML systems debt: the model is a small fraction of the real system. Data pipelines, feedback loops, monitoring, evaluation, and configuration surround it — and every one of those surfaces has to exist before you can meaningfully test an AI feature in production.
- Key finding: the ML model is < 5% of a real AI system by code and complexity.
- Production AI testing requires evals, guardrails, monitoring, and rollback — all of which must be built first.
- Our takeaway: prototyping is the only affordable way to answer 'is this even worth building the pipeline for?'
McKinsey's annual survey finds that companies reporting meaningful EBIT impact from AI are the ones redesigning workflows and decision rights, not the ones deploying tools onto legacy processes. The gap between AI ambition and AI value is a governance and workflow gap.
- Key finding: workflow redesign is the strongest predictor of AI value capture.
- Legacy discovery-then-delivery flows are especially poor fits for AI features.
- Our takeaway: prototype-to-learn is not a tool choice — it is the workflow change that lets AI value show up.
The evidence and the story we tell match.
Leg 1 (clarity before commitment) is why the Future team has a working artifact — and a real conversation — while the Historical team is still writing it up.
Leg 2 (coordination iceberg) is why accumulating learning early beats accumulating documents early: every unshared assumption becomes coordination cost later.
Leg 3 (AI ≠ A/B) is why a prototype in week 1 is not a nice-to-have for AI features — it's the only affordable way to learn before the risk pipeline is triggered.
This page argues for prototype-to-learn as an operating-model change — not a developer productivity claim. Where a source is broader than our thesis, we've noted it on the source card.