Innovation Competencies: Lean Startup, Design Thinking and Maker Culture

Test innovation bets with explicit hypotheses, real customers and the smallest useful experiment. Measure learning by the decisions it changes, then choose to continue, pivot or stop.

Why this matters

Established companies execute known business models. New ventures search for one, as Steve Blank emphasizes. A new internal product needs that search discipline too.

Treat the plan as hypotheses. Meet customers early. Build only enough to obtain useful evidence. Decide on a schedule using thresholds agreed before results arrive.

AI makes prototypes cheaper, but customer attention, experiment design and judgment remain scarce. Use Lean Startup, customer development and design thinking to turn a bet into evidence that changes the next decision.

The innovation competencies

Lean Startup: build, measure, learn

Eric Ries introduced Lean Startup in 2008 and published the book in 2011, building on Blank’s customer development and lean methods. Its five principles are:

1. Entrepreneurs are everywhere, including product teams inside large companies.
2. Entrepreneurship is management: search mode needs its own management practice.
3. Validated learning is the unit of progress.
4. Innovation accounting measures progress, sets milestones and prioritizes work with actionable metrics.
5. Build-Measure-Learn: turn ideas into products, measure how customers respond, learn whether to pivot or persevere, and speed up the loop.

Plan Build-Measure-Learn backward: what must you learn, what evidence would establish it and what is the least you must build to obtain that evidence?

The minimum viable product

Ries defines an MVP by maximum validated learning with minimum effort. His 2009 clarification emphasizes the fastest route to evidence. An ad test, for example, can reject a concept before weeks of building.

Choose an MVP type by the riskiest assumption. These categories are common across lean practice:

Ries describes Dropbox testing demand with an explainer video. Zappos’s Nick Swinmurn tested online shoe sales using photographs of store stock. In B2B, concierge, Wizard of Oz and presale tests often provide stronger evidence about outcomes and contracts.

Innovation accounting

Ries’s innovation accounting uses three milestones to measure search progress:

1. Establish the baseline. Use an MVP to get real data on where the business stands today, not where the plan says it will be.
2. Tune the engine. Run experiments that move the baseline toward the ideal in the business plan.
3. Pivot or persevere. If tuning isn’t moving the numbers fast enough, the hypothesis is wrong; change it.

Use actionable metrics that reveal cause and effect, often by cohort. Cumulative sign-ups and views can flatter without explaining progress. Ries also requires accessible definitions and auditable links to customers.

Long enterprise sales cycles delay revenue evidence. Track faster signals: design-partner use, AI acceptance, passed security reviews, procurement progress and letters of intent. Chapter 05 covers measurement.

Pivots

A pivot changes a fundamental product, strategy or growth hypothesis while retaining validated learning. Ries’s “one foot in the past” guidance distinguishes it from abandoning the work for an unrelated idea.

The Lean Startup catalogues ten pivot types:

In B2B, value capture and business architecture pivots are common and underrated, because many enterprise ideas fail on the business model while the product is fine. Chapter 15 covers pricing.

Ries also proposed a regular strategic review, for example once per development cycle, so pivot decisions get made on a schedule against evidence. His warning signs: a chronically frustrated team, experiments that produce only modest gains, and doubt about three questions. Are we solving an important problem? Are early adopters actually adopting? Does the product deliver what it promises?

Ries’s The Startup Way (2017) applies the method inside established companies, drawing on his work with GE on its FastWorks program, and is associated with metered funding: internal ventures get money in tranches tied to validated learning (Chapter 23).

Customer development: get out of the building

Steve Blank developed customer development from startup practice and described it in The Four Steps to the Epiphany, then The Startup Owner’s Manual with Bob Dorf. Test business-model hypotheses with customers.

The method has four steps. The first two are search; the last two are execute.

1. Customer discovery. Turn the business model into hypotheses and test them with customers.
2. Customer validation. Prove the sale is repeatable and scalable.
3. Customer creation. Scale demand once the model is proven.
4. Company building. Organize to execute the proven model.

Failed validation returns the team to discovery. Blank’s Lean LaunchPad spread to more than 75 universities, and NSF adopted it for I-Corps in 2011.

In enterprise products, adapt it two ways:

• The customer is a buying group. Discovery has to cover the end user, the champion, the economic buyer and the security gatekeeper separately (Chapter 01 sets out the B2B persona set). An idea can pass discovery with users and fail it with the gatekeeper.
• Validation means a repeatable sale. One enthusiastic design partner is discovery evidence. Validation is several customers buying without heroic help: a sales rep closes without the PM on the call, and security reviews pass without a custom exception.

Design thinking: from empathy to prototype

IDEO and Stanford helped popularize design thinking. IDEO credits David Kelley, Tim Brown and Jane Fulton Suri, while explicitly avoiding a claim to invention. Brown’s 2008 HBR article puts design at the start of product, service and strategy decisions.

IDEO combines desirability, feasibility and viability, the same lenses David Bland uses for assumptions. This book adds adoptability for B2B buying groups, security and procurement (Chapter 01).

The d.school’s five modes

The d.school’s Design Thinking Bootleg (2018) names five iterative modes:

The Nielsen Norman Group’s version, by Sarah Gibbons, adds a sixth phase, Implement, and groups the six into three stages: understand, explore and materialize. Both sources stress that the phases loop. Testing usually sends you back to understanding.

The Double Diamond

The UK Design Council began developing the Double Diamond in 2003. It contains four phases:

• Discover: understand the real problem by spending time with the people affected.
• Define: reframe the challenge using what discovery revealed.
• Develop: generate varied solutions, ideally co-designed with users.
• Deliver: test at small scale, reject what fails and improve what works.

Each diamond expands options, then narrows them: first the problem, then the solution. Teams can return to earlier phases. The wider framework emphasizes people, visual communication, co-creation, iteration and leadership support.

The most common enterprise failure is skipping the first diamond. A large customer “asked for” a feature, so the team starts in Develop with the customer’s proposed solution as the brief. The customer’s request is a clue about a problem, not a definition of it.

The critiques of design thinking

Design thinking’s critics describe what many enterprise design programs actually produce. Rebecca Ackermann’s 2023 retrospective in MIT Technology Review gathered the main lines:

• Short, fresh-eyes engagements produce recommendations ungrounded in how the work really happens.
• Innovation theater: workshops and sticky notes that change nothing.
• Pilots that stall before scale, such as an IDEO.org project that became too expensive to scale and a 2013 San Francisco school cafeteria redesign that relied on connected vending machines many sites couldn’t support.
• Designers as privileged interpreters. Lilly Irani argued in 2018 that the method elevates designers over the people they interpret; former IDEO designer George Aye described consultants as tourists.

Ackermann also reports responses: the d.school shifted toward making and care, while Tim Brown calls for capability-building and longer engagement. Connect each design activity to an experiment, threshold and decision.

Testing Business Ideas: the experiment library

David Bland and Alexander Osterwalder’s Testing Business Ideas (2019) links these methods: map assumptions, prioritize risk, choose an affordable test with sufficient evidence and decide.

The book’s library holds more than 40 experiment types, each graded by cost, time to run and strength of evidence. They split broadly into two families:

• Discovery experiments: cheap, fast and weaker evidence. Customer interviews, search trend analysis, discussion forums, explainer videos, paper prototypes.
• Validation experiments: costlier and stronger evidence. Concierge, Wizard of Oz, mock sales, letters of intent, presales, split (A/B) tests and single-feature MVPs.

Bland’s assumptions mapping, which he learned from Jeff Gothelf, Josh Seiden and Giff Constable, is covered in Chapter 01. Here the important tool is the Test Card, which forces four things into the open before a test runs: the hypothesis that must hold, how you’ll test it, what you’ll measure and what success looks like, including the threshold. Its partner, the Learning Card, records afterwards what you believed, what you observed, what you learned and what you’ll do as a result. After each round, each hypothesis is marked right, wrong or still unclear.

Bland rates what people do above what they say. Translated to B2B:

Design sprints

Jake Knapp developed design sprints at Google from 2010, then GV with colleagues. Knapp, John Zeratsky and Braden Kowitz published Sprint in 2016. The method compresses problem and solution exploration into five days:

The book adds about seven people or fewer, a Decider who makes the calls, a Facilitator who runs the room and five customer interviews on Friday, drawing on Jakob Nielsen’s usability research. Knapp and Zeratsky have since added a Foundation Sprint for earlier-stage work.

In enterprise products, recruit five people per persona that matters and don’t mix them; five SRE leads and five security reviewers will tell you different things. The facade is usually an admin console, an approval flow or an ROI report, and an AI harness can now build it in hours.

Maker culture and rapid experimentation

DIY communities, Make: magazine (2005), Maker Faire (2006), hackerspaces and digital fabrication spread low-cost prototyping. Neil Gershenfeld compared this shift with the spread of personal computing.

Use prototypes to think and test an argument. Ask what building one would let you learn.

The same habit scales into large-company experimentation. Stefan Thomke’s 2020 Harvard Business Review article “Building a Culture of Experimentation” describes Booking.com running about 25,000 tests a year, including a test of a stripped-down home page that removed years of optimized content. Most B2B products don’t have that traffic, so enterprise experiments are usually qualitative or small-sample: design partners, pilots and fake doors in an admin console. They’re still worth running, as long as every experiment card states its evidence strength honestly. Chapter 05 covers controlled experiments for products with the volume.

How the methods fit together

A workable division of labor:

How to apply it

Use this eight-week cycle for a bet selected in Chapter 20, starting with Chapter 01’s hypothesis and assumption map.

Week 1: Frame the bet.

1. Decide which diamond you’re in. If the problem isn’t yet evidenced with the people who have it, spend the cycle on the first diamond, whatever the customer’s feature request says.
2. Pull the top-right quadrant from the assumption map: important assumptions with little evidence. Label each desirability, feasibility, viability or adoptability.
3. Agree who decides. Name a Decider for the cycle and a date for the pivot-or-persevere review, and put both in the calendar now.

Week 2: Design the experiments.

4. Write an experiment card for each of the top three assumptions. Fill in the Test Card fields (we believe, to verify that we will, and measure, we are right if) before anyone builds anything. The threshold is a number or an observable behavior, written down in advance.
5. Pick the cheapest experiment that produces evidence strong enough for the decision. Spending two engineering quarters needs stronger evidence than running another test.
6. For anything that needs a build, write an MVP plan: the MVP type, who sees it, how they’re recruited, what you won’t build and what happens to the MVP after the decision.

Week 3: Set the baseline.

7. Choose three to five actionable leading indicators for the bet and get today’s value for each, by cohort. Write down the vanity metrics you’ll deliberately ignore.
8. Put them on an innovation accounting dashboard alongside the experiments and their status.

Weeks 3 and 4: Prototype and sprint where it pays.

9. If the riskiest assumption is about the solution experience, run a five-day design sprint on it, with five customers per key persona on the Friday.
10. Build prototypes with your AI harness as realistic facades. Label what’s faked, keep real customer data out and decide who on the team checks the prototype before a customer sees it.

Weeks 4 to 7: Run, measure, learn.

11. Run the experiments. Write a learning card within two days of each result, with the evidence attached.
12. Update the dashboard weekly. Mark each assumption right, wrong or still unclear.
13. Kill experiments that can no longer change the decision.

Week 8: Decide.

14. Hold the pivot-or-persevere review. Bring the dashboard, the learning cards and the options: persevere, pivot (name the type) or stop. For each, state the cost and what you’d keep.
15. Record the decision, the reason and the next milestone. A pivot starts a new cycle with a new hypothesis; a stop gets a short write-up so the learning isn’t lost.

The AI lens

Building AI-powered products

AI products put extra weight on certain assumptions, and the methods need small adjustments to test them.

• Feasibility is a quality distribution. For an AI feature, feasibility means how often the model is right, on which inputs, at what cost per call. Treat model quality as an assumption with a threshold and test it with an evaluation set before you test desirability with customers (Chapter 31 covers evals).
• Wizard of Oz is the natural AI MVP. A person who produces or checks the output behind the interface separates the desirability question (do they want this output?) from the feasibility question (can the model produce it reliably?).
• Trust is usually the riskiest assumption. For agents that act, the open question is whether customers will let the agent act, and under what controls. Test approval rates, overrides and what the gatekeeper requires.
• Viability includes inference cost. An AI MVP can be desirable and feasible and still lose money on every use. Track cost per successful outcome from the first experiment, and expect a value capture pivot on the table at the first review.

Doing the work with AI

AI tools reduce prototype cost. Anthropic introduced Artifacts in June 2024 and described design-to-code workflows in July 2025. Figma launched its prompt-to-app Make tool in May 2025.

Andrej Karpathy named the casual end of this “vibe coding” in February 2025: describe what you want in plain language, accept the generated code and steer by results. In March 2025 Y Combinator’s Jared Friedman informally estimated that about a quarter of its Winter 2025 batch had codebases about 95% generated by AI, while YC’s partners stressed that founders still needed the skill to judge and fix the output.

A harness can build approval flows, mock ROI reports and fake-door tiles quickly. Three consequences follow.

The bottleneck moves from building to learning. When building is nearly free, the scarce resources are customer attention, crisp hypotheses and the willingness to kill ideas. Lean Startup’s “least you must build” becomes “least customer time you must spend.” Design experiments so each customer conversation answers a real question.

Measured speed isn’t perceived speed. METR’s July 2025 randomized study of 16 experienced open-source developers, working on 246 real issues in their own repositories, found they took 19% longer when AI tools were allowed. The developers had expected a 24% speedup and still believed afterwards that they’d been about 20% faster. METR is explicit about the limits (a small sample, early-2025 tools, one setting), now labels the results out of date and never claimed AI slows most developers. What the study does show is that people misjudge their own speed. Apply innovation accounting to your own process: measure the cycle time from hypothesis to decision, and ignore the number of prototypes produced.

AI-built prototypes carry real risk. Public reporting in 2025 described apps built on vibe-coding platforms exposing personal data and an AI coding agent deleting a production database. A prototype you show an enterprise customer is a facade. It should never touch real customer data or production systems without the same security review as any other software. Label it as a prototype on screen.

Use AI to draft experiment cards, suggest tests, build facades, organize sourced learning notes and prepare reviews. You set thresholds, interpret strategic implications and obtain evidence from real customers.

The Beacon case: experimenting toward Beacon Agents

Framing the bets. The top-right quadrant of the assumption map becomes three bets, each with an owner and a Decider:

1. Supervised remediation trust (desirability and adoptability): SRE leads like Priya will approve agent-proposed runbook steps inside the approval gate.
2. Per-resolved-incident pricing (viability): economic buyers like Marcus will accept a price per resolved incident, and partners like Leo can bill their own customers that way.
3. MSP multi-tenant view (desirability): managed service providers want a per-customer view of incidents enough to justify building one.

Experiment 1: a Wizard of Oz for remediation. Building the full Act capability would take quarters. Instead, five design-partner environments get an approval card: Beacon proposes a runbook step (restart, roll back or scale) with cited evidence, and a Northlight engineer checks it before it appears. The contract owners know a human is in the loop. The card reads: We believe that SRE leads will approve agent-proposed runbook steps. To verify that, we will show verified proposals in five design-partner environments for four weeks. And measure approval rate and time to approve. We are right if at least 60% of proposals are approved within two minutes (a fictional threshold the team set before the test). Sam reviews the card first, because the gatekeeper’s requirements are part of the assumption.

Experiment 2: a mock sale for pricing. Live billing stays untouched. In renewal conversations, account teams show Marcus-type buyers a pricing page with per-resolved-incident options beside the current per-environment price and record what buyers choose to discuss and what they object to. The partner team asks three MSPs for letters of intent for per-incident billing. The card rates buyer preferences in conversation as medium evidence and a signed letter of intent as strong.

Experiment 3: a concierge for MSPs. Before anyone designs a multi-tenant interface, the shared product ops lead compiles a weekly per-customer incident report by hand for three MSP partners. If Leo’s team uses the reports in their own customer reviews, the need is real; if the reports go unread, nobody builds a dashboard.

A design sprint for Dana. The designer runs a five-day sprint on a long-term goal Beacon already has: Dana knows what broke and what to do in under five minutes. On Thursday the team builds the incident summary card as a facade with the AI harness, using fabricated incidents. On Friday they run five sessions with on-call engineers, and a separate set with security reviewers on what the audit trail must show.

The dashboard. By design-partner cohort, the dashboard tracks diagnosis acceptance rate, MTTR, autonomous resolution rate on allowlisted actions, proposal approval rate and inference cost per resolved incident, which ties the bet to the margin problem. It deliberately leaves out total agent invocations, which go up whatever happens.

The pivot-or-persevere review. Midway through the cycle, a customer rolls back the wrong service on a hallucinated Beacon root cause. The review moves forward, with three options for the Decider:

• Persevere, with stronger evals and a cited-evidence threshold below which Beacon won’t propose an action.
• Zoom-in pivot: make diagnosis the product for now and remove Act for a segment of customers until trust is rebuilt.
• Customer segment pivot: launch Beacon Agents first with MSPs, whose operators run remediations across many customers and may value the speed more.

The Decider chooses to persevere with diagnosis and narrow Act to allowlisted low-risk actions with the cited-evidence threshold, with no rollback proposals until the evals pass. The correlation and diagnosis learning stays and only the riskiest part of the bet changes. The Northlight Live launch message changes with it (Chapter 25), and the pricing experiment continues, because its evidence never depended on Act.

Product 360 artifacts

# Experiment card · [Experiment name] · [ID] · [Date]

**Owner:** [PM]   **Decider:** [Name]   **Linked bet or opportunity:** [Link]   **Status:** Designed / Running / Done

## Riskiest assumption
[One assumption from the assumption map]
Type: desirability / feasibility / viability / adoptability (buying group, security, procurement)

## Test card (complete before the test starts)
- We believe that: [assumption]
- To verify that, we will: [experiment type, audience, number of customers, duration]
- And measure: [metric or observable behavior]
- We are right if: [threshold, written before any data arrives]

## Cost and evidence
- Cost (people, money, customer time):
- Time to result:
- Evidence strength expected: weak / medium / strong, and why
- What decision this evidence will inform:

## AI disclosure
- Generated by the AI harness: [prototype / analysis / draft materials]
- From real customers: [sessions, behavior, signatures]
- Synthetic output used as evidence: none (synthetic output may only prepare the test)

## Learning card (complete after the test)
- We believed that:
- We observed: [result against the threshold, with links to evidence]
- From that we learned:
- Therefore we will: persevere / pivot (type) / run next test / stop
- Assumption status: right / wrong / still unclear

# MVP plan · [Product or bet] · [Date]

**Owner:** [PM]   **Decider:** [Name]   **Time box:** [Start] to [End]

## What we need to learn
- Hypothesis under test:
- Leap-of-faith assumptions: value hypothesis: [ ]; growth or buying-process hypothesis: [ ]
- The decision this MVP informs:

## MVP type and why
Smoke test or fake door / Explainer video / Concierge / Wizard of Oz / Single-feature / Piecemeal / Presale or letter of intent
Why this is the cheapest route to evidence strong enough for the decision:

## Who sees it
| Segment or persona | Number | How recruited | Consent and contract owner informed |
|---|---|---|---|
| | | | |

## Data and security
- Customer data used: none / synthetic only / real (security review reference: [ ])
- What is faked or manual, and who knows:

## Thresholds (set before launch)
- Success: [metric and threshold]
- Kill: [metric and threshold]
- Ambiguous result: [what we'll do]

## What we will deliberately not build
-
-

## After the decision
Destroy / harden and fold into the roadmap / hand to another team. Owner of the clean-up:

# Innovation accounting dashboard · [Bet] · Week of [Date]

**Owner:** [PM]   **Next pivot-or-persevere review:** [Date]

## Milestone status
- [ ] Baseline established (date and source)
- [ ] Tuning the engine (experiments since baseline: [n])
- [ ] Pivot-or-persevere decision due: [date]

## Leading indicators (by cohort, weekly)
| Indicator | Why it's actionable | Cohort | Baseline | Current | Target | Trend |
|---|---|---|---|---|---|---|
| | | | | | | |

## Learning velocity
| Measure | This cycle | Last cycle |
|---|---|---|
| Experiments completed | | |
| Assumptions validated | | |
| Assumptions invalidated | | |
| Still unclear | | |
| Median days from hypothesis to decision | | |
| Cost per validated learning (people-weeks) | | |

## Viability
- Cost per successful outcome (include inference cost for AI products):
- Evidence of willingness to pay (letters of intent, paid pilots):

## Vanity metrics deliberately excluded
- [Metric]: excluded because [it rises regardless of what we change]
-

## What changed our mind this week
[One paragraph, with links to learning cards]

# Design sprint plan · [Challenge] · [Dates]

**Decider:** [Name]   **Facilitator:** [Name]   **Team (seven or fewer):** [Names and roles]

## Monday: Map
- Long-term goal:
- Sprint questions (what could make us fail?):
  1.
  2.
  3.
- Experts to interview and their slots:
- Target customer and moment on the map:

## Tuesday: Sketch
- Existing ideas to remix (competitors, other teams, other industries):
- Recruiting started: [personas, numbers, screener]

## Wednesday: Decide
- Decision method:
- Storyboard owner:

## Thursday: Prototype
- Fidelity and tool (AI-built allowed):
- What is faked (label on screen):
- Data used: fabricated only, no production data
- Interview script owner:

## Friday: Test
| Persona | Sessions (five per persona) | Interviewer | Observers |
|---|---|---|---|
| | | | |

## Scorecard
| Sprint question | Session 1 | 2 | 3 | 4 | 5 | Pattern |
|---|---|---|---|---|---|---|
| | | | | | | |

## Decision and next experiment
[What the Decider decided, and the experiment card it produced]

# Pivot-or-persevere review · [Bet] · [Date]

**Cadence:** every [6 to 8] weeks or once per cycle   **Decider:** [Name]
**Attendees:** product trio, Decider, finance partner, [others]

## Evidence summary
- Dashboard link and milestone status:
- Experiments since last review, with learning cards:
- What moved, and why we think so:
- What didn't move:

## Warning signs
- Are we solving an important problem? Evidence:
- Are early adopters actually adopting? Evidence:
- Does the product deliver what it promises? Evidence:
- Is the team chronically frustrated, with only modest gains from tuning?

## Options
| Option | Pivot type (if any) | What we keep | What changes | Cost | Evidence for |
|---|---|---|---|---|---|
| Persevere | n/a | | | | |
| Pivot | zoom-in / zoom-out / customer segment / customer need / platform / business architecture / value capture / engine of growth / channel / technology | | | | |
| Stop | n/a | | | | |

## Decision
- Decision:
- Rationale (one paragraph):
- What we keep from the past (validated learning carried forward):
- New or revised hypothesis:
- Next milestone and review date:
- Who will be told, and how:

# Double Diamond brief · [Challenge] · [Date]

**Owner:** [PM]   **Designer:** [Name]   **Current phase:** Discover / Define / Develop / Deliver

## The request as received
[What the customer or stakeholder asked for, in their words. Treat it as a clue, not a brief.]

## Discover (diverge on the problem)
- People to spend time with (by persona, including the buying group):
- Methods: observation, interviews, data review
- What surprised us:

## Define (converge on the problem)
- Point of view or job story: When [situation], [persona] wants to [motivation], so they can [outcome].
- Problem statement we will design for:
- What we're explicitly not solving:

## Develop (diverge on solutions)
- Options generated (at least five, including "do nothing"):
- Co-design sessions held, and with whom:

## Deliver (converge on a solution)
- Small-scale test and its experiment card:
- What failed and was rejected:
- What will be improved and carried forward:

## Loop-backs
| Date | From phase | Back to phase | Why |
|---|---|---|---|
| | | | |

Prompts

Goal: Get draft experiment cards for your riskiest assumptions, with honest evidence ratings.
Paste in: the assumption map (or its top-right quadrant), the decision the experiments must inform and any constraints on customer access, budget and time.

Act as an experienced product experimenter working on [product or bet].

For each of the top [three] important, unevidenced assumptions:
1. Restate it as a single falsifiable belief and label it desirability, feasibility, viability or adoptability (will the buying group, security and procurement let it through?).
2. Propose two candidate experiments: the cheapest one that could produce weak evidence, and the cheapest one that could produce strong evidence. For each, state cost, time to result and evidence strength, and say why.
3. Fill in a test card: we believe that, to verify that we will, and measure, we are right if. Propose a threshold, and explain what would make it too easy or too hard.
4. Say which decision the result would change, and what we would do if the result is ambiguous.

Rules: ground conclusions in observed behavior and commitment: signatures, payments, security approvals and time spent. Treat opinions and synthetic responses as hypotheses. Use supplied customer facts.

[assumption map]
[decision and constraints]

Check the output: challenge every threshold yourself and agree it with the Decider before the test starts. Reject any experiment whose "strong evidence" is something customers say rather than something they do.

Goal: Pick the cheapest MVP that answers your riskiest question, and see what you'd skip.
Paste in: the hypothesis, the single riskiest assumption, your persona set and what you can and can't put in front of customers (contract, security and data limits).

For [product or bet], compare these MVP types for testing this assumption: [assumption]. Types: smoke test or fake door, explainer video, concierge, Wizard of Oz, single-feature, piecemeal and presale or letter of intent.

Produce a table with: what the customer would see, what the MVP would actually prove, what it couldn't prove, cost and time, evidence strength, and risks in an enterprise setting (customer data, security review, contract owner disclosure).

Recommend one type and explain why it's the cheapest route to evidence strong enough for this decision: [decision]. Then define the minimum build and its explicit exclusions.

Check the output: confirm the recommended MVP tests the assumption you named, not an easier neighboring one. If it needs real customer data or production access, take it through security review or choose another type.

Goal: Get a realistic, clearly fake prototype in hours, ready for five customer sessions.
Paste in: the storyboard or sketches, the target persona and moment, the sprint questions and any design system files. Use fabricated data only.

Build an interactive prototype of [screen or flow] for [persona] at [moment]. It is a facade for customer interviews, not production software.

Requirements:
- Follow the storyboard exactly. Where it is unclear, ask me rather than guess.
- Use realistic but fabricated data. Never use real customer names, hostnames, incidents or credentials.
- Show a small "Prototype" label on every screen.
- Make only the paths in the storyboard work. Other controls can show "Not in this prototype."
- List every place where the prototype fakes behavior the real product would need to earn (for example accuracy, speed or permissions).

Check the output: click through every path in the storyboard yourself before a customer sees it. Confirm no real data appears anywhere, and that the list of faked behaviors is shared with everyone who runs a session.

Goal: Turn raw results into a learning card with the evidence attached.
Paste in: the experiment card (with its threshold), session notes or transcripts and any measured results. Use an approved tool for customer recordings and notes.

Using this experiment card and these results for [experiment], write a learning card:
- We believed that: (copy from the card)
- We observed: the result against the threshold, stated plainly, with each observation linked to its source (session ID and timestamp, or data source).
- From that we learned:
- Therefore we will: persevere, pivot (name the type), run a next test or stop, with the reason.
- Assumption status: right, wrong or still unclear.

Rules:
- Apply the original threshold. Mark near-threshold results and the assumption as still unclear.
- Separate what customers did from what they said, and weight behavior more.
- Quote participants verbatim and link each interpretation to its source.
- List any surprises that don't fit the hypothesis.

[experiment card]
[results]

Check the output: open two of the cited sources and confirm them. If the learning card says "right" but the threshold wasn't met, it's wrong.

Goal: Arrive at the review with the evidence assembled and the options costed, so the meeting is spent deciding.
Paste in: the innovation accounting dashboard, learning cards since the last review, the current hypothesis, and budget and team constraints.

Prepare a pivot-or-persevere review pack for [bet].

1. Summarize what the evidence shows since the last review: what moved, what didn't, and how strong the evidence is.
2. Answer three warning-sign questions with evidence: Are we solving an important problem? Are early adopters actually adopting? Does the product deliver what it promises?
3. Propose options: persevere, at most three pivots (name each type: zoom-in, zoom-out, customer segment, customer need, platform, business architecture, value capture, engine of growth, channel, technology) and stop.
4. For each option, state what validated learning we keep, what changes, the cost and the next milestone.
5. Name the evidence that would most change the recommendation.

Return decision options for the Decider, grounded in the supplied evidence.

[dashboard]
[learning cards]
[hypothesis and constraints]

Check the output: make sure each pivot keeps real validated learning rather than jumping to an unrelated idea. Remove any option whose evidence is only opinion. The Decider decides.

Goal: Find the activities that look like innovation but produce no decisions.
Paste in: a list of the last quarter's innovation activities (workshops, sprints, hackathons, pilots, prototypes), with any outputs and follow-up actions.

Review these innovation activities for [team or portfolio]. For each, answer:
1. What hypothesis did it test? (Write "none stated" if none.)
2. Was a success threshold set before it started?
3. What evidence did it produce, and how strong was it (weak, medium, strong)?
4. What decision did it change, and who made it?
5. Classify it as learning, preparation or theater, with a one-line reason.

Then list the three changes that would turn the most theater into learning, such as requiring an experiment card before a workshop or a decision owner for every pilot.

Check the output: confirm the classifications with the people who ran the activities before sharing. The goal is to change the system, not to blame a team.

Anti-patterns

Checklist

• The bet has a named Decider and a scheduled pivot-or-persevere review date.
• The team knows which diamond it’s in, and hasn’t skipped Discover because a customer asked for a feature.
• Every experiment has a card with a threshold written before the test started, plus its cost, time to result and evidence strength.
• Assumptions are labeled desirability, feasibility, viability or adoptability, and the riskiest are tested first.
• Every MVP has a plan naming its type, audience, thresholds, what won’t be built and what happens after the decision.
• The innovation accounting dashboard shows actionable leading indicators by cohort, with a baseline, and lists the vanity metrics excluded.
• For AI products, cost per successful outcome and model quality thresholds are on the dashboard.
• Customer discovery covers each member of the buying group separately.
• Validation claims rest on repeatable behavior (signatures, payments, security approvals), not one champion’s enthusiasm.
• Prototypes shown to customers use fabricated data, are labeled as prototypes and list what they fake.
• No synthetic or AI-generated response appears as evidence on a learning card.
• Every experiment ends in a learning card, and every review ends in a recorded decision that names what learning was kept.