The Innovation Toolkit

Choose an innovation mechanism by the uncertainty it must resolve. Agree who receives the result, what evidence decides its future and where follow-on capacity comes from.

Why this matters

Hackathons, labs and venture programs fail when the mechanism does not fit the question or its output has no route into the product. Steve Blank calls the resulting activity innovation theater.

As PM, choose the mechanism and plan its landing. Feasibility may need a prototype, adoption a design partner, availability a venture client pilot, and a capability gap a partnership or acquisition.

Cheap AI prototypes increase the volume of unfinished experiments. License-and-hire deals also widen the ways to acquire technology and talent. Compare the options deliberately, including your existing model-provider relationship.

The innovation toolkit

Two pipes: open innovation

Henry Chesbrough’s open innovation (2003) combines outside ideas and internal knowledge with external and internal routes to market:

• Inbound brings outside knowledge in: licensing a patent or technology, buying a startup’s product, working with a university lab, co-developing with customers, acquiring a company.
• Outbound takes unused inside knowledge out: licensing technology to others, spinning out a product that isn’t core, opening an interface so partners can build on your platform.

A third, coupled mode combines the two in alliances and joint development, where knowledge flows both ways at once.

Chesbrough used Xerox PARC to illustrate value escaping the inventor. The Star sold about 25,000 units while staff and spin-outs, including Metaphor in 1982, took ideas elsewhere. Xerox donated PARC to SRI in 2023. Plan a route for valuable ideas the core cannot use.

Open innovation trades control for access and speed. Manage disclosure, intellectual property and integration capacity. External knowledge has little value if no internal team can absorb it.

An API, connector specification or MCP server lets outsiders build complementary capabilities. Treat this outbound route as a product decision (Chapter 14).

Match the mechanism to the bet

Classify the bet with Chapter 20’s horizon and ambition lenses before selecting a mechanism.

The horizon. In Steve Blank’s adaptation of the three horizons, H1 executes a known model, H2 extends it into partly known territory and H3 searches for an unproven model. His H3 teams have fewer than five members and speak with over 100 customers in about ten weeks while prototyping.

The ambition. Bansi Nagji and Geoff Tuff’s innovation ambition matrix asks two questions: where you play (existing markets through to new ones) and how you win (existing products and assets through to new ones). The answers sort a bet into core, adjacent or transformational.

Mechanisms tend to produce one band more than others. Hackathons, idea challenges and design partner programs mostly feed Horizon 1 and 2 work. Incubators, venture capital and acquisitions are Horizon 2 and 3 tools. A hackathon can’t answer a Horizon 3 business model question in two days, and an acquisition is an expensive way to get a Horizon 1 feature.

The organizing rule. O’Reilly and Tushman recommend structurally separate exploratory units linked to the core at senior level. Blank adds distinct plans, incentives and metrics, embedded legal and procurement support, rewards for core managers and an agreed graduation path. Chapter 23 covers graduation.

The fourteen mechanisms

The table compares the full toolkit. Costs are relative to each other, not budgets.

Group the fourteen mechanisms into four families.

Harvest internal ideas and skills. Challenges, hackathons, training and intrapreneurship surface problems, feasibility evidence and talent. Plan continuity so outputs can be absorbed.

Idea challenges descend from prize competitions such as the Netflix Prize: $1 million offered in 2006 for a 10% better recommendation algorithm, won in 2009 by BellKor’s Pragmatic Chaos with 10.06%. In B2B, an internal challenge’s value is often in the problems submitted: asking field engineers and support staff what customers work around every week is discovery at scale.

Anthropic’s Claude Frontier Academy, announced in October 2026 with $100M backing, targets 10,000 engineers by end-2027. Its program includes a twelve-week residency tied to a real project. With no outcome data yet, treat it as a design pattern: training applied to work at the learner’s company.

Intrapreneurship, a term Gifford and Elizabeth Pinchot coined in 1978, gives employees the air cover to pursue a new venture inside the company. Lockheed’s Skunk Works, set up in 1943, is the classic structural example. These programs need a named organization ready to receive a successful project, and a promise that joining won’t damage anyone’s career. Without both, the best people stay away.

Protect new work. Incubators and labs reserve time and funding but face budget-cut risk. Google’s Area 120, founded in March 2016, produced Aloud, absorbed into YouTube auto-dubbing in 2023, and Byteboard, spun out in 2021. It moved under Google Labs in 2021 and shrank substantially in the 2023 layoffs. Define graduation and receiving ownership.

Mechanisms that bring the outside in. Corporate venture capital, startup partnerships, design partners, university partnerships and licensing all reach outside the company. They usually cost less and move faster than building, at the price of control and the work of absorbing what comes back.

University partnerships, such as the MIT-IBM lab set up in 2017, suit hard research questions with long timelines. They fail when product teams expect quarterly results, or when nobody settles intellectual property ownership until after it exists. Licensing in suits a well-defined asset that a contract can protect. Licensing out turns an internal asset into revenue: Arm built its business on designing processor technology and licensing it to chipmakers for fees and royalties, rather than manufacturing chips.

Mechanisms that change ownership. Acquisitions, acqui-hires, license-and-hire deals and spin-outs move assets, people or both across the company boundary. They’re the hardest to unwind and are covered below.

Hackathons that change the roadmap

Atlassian reports that five employees built the portal that became Jira Service Desk during a 24-hour ShipIt event. Use hackathons to answer a product question and plan continuity.

Nolte, Herbsleb, Gama and Affia-Jomants’s hackathon planning kit, published in 2020 and revised in 2025, specifies twelve decisions:

1. Goal: what do you want to achieve?
2. Theme: what is the overall theme?
3. Competition or cooperation: do teams compete for prizes or work together?
4. Stakeholder involvement: how do people from outside take part?
5. Participant recruitment: who should come?
6. Specialized preparation: what will teams need in order to take part?
7. Duration and breaks: how long and how intense?
8. Ideation: when and how do teams develop ideas?
9. Team formation: how do people with shared interests find each other?
10. Agenda: what happens during the event?
11. Mentoring: how will you support participants?
12. Continuity planning: what happens after it ends?

The authors recommend setting goals about four months ahead and managing tensions between organizational and participant needs, usefulness and illustration, challenge and feasibility, and speed and quality. Plan continuity before the event, including reusable technology, community and learning as possible outcomes.

For a B2B product team, three adaptations matter. Pick a goal the roadmap needs answered. Give teams realistic data and systems, cleared by security in advance. Judge on measured results against a shared test set rather than demo polish. The AI lens section turns these into rules for AI hackathons.

Design partners and co-development

A design partner shares workflows, data and scheduled feedback before general availability, in exchange for early access and influence. B2B programs reveal real operating, security and purchasing constraints.

We found no rigorous study of design partner programs, so the guidance here is this book’s own practice, built around the mechanism’s familiar failure modes.

• Choose partners for representativeness, not enthusiasm. The most eager customer is often the least typical. Pick partners who match the target segment, who will share data and who have an executive sponsor.
• Make commitments run both ways. The partner commits to a feedback cadence and to letting you use what you learn. You commit to early access, a named contact and usually some pricing protection.
• Guard against custom work. The classic failure is building one loud partner’s special requirements into the product. Ship a partner-requested feature only if it serves several partners.
• Set an end date and exit rules. When the program ends, partners convert to paying customers on normal terms or leave.

Chapter 01 covers the discovery interviewing that sits inside a design partner program. Chapter 21 covers the experiments you run with partners.

Venture clients and corporate venture capital

When a startup may already have solved your problem, the fastest path is often to become its customer. The venture client model, associated with Gregor Gimmy and BMW, builds on this idea: the company buys and uses a startup’s product for a strategic purpose, without taking equity. BMW’s Startup Garage, founded in 2015, describes itself as the first venture client unit. Its process runs from discovery through assessment, a purchase order that makes the startup a supplier, a proof of concept and, if it works, a long-term partnership. BMW reports assessing more than 6,000 startups, piloting more than 280 and turning more than 38 into regular suppliers, with four to eight weeks from first contact to evaluation. The numbers are self-reported; the process is the useful part.

Use a venture client pilot to test workflow fit. Include procurement and security in week one and agree a contract path to avoid successful pilots stalling.

Corporate venture capital takes equity in startups through a fund. Its aims are strategic (a view of a market, access to technology, a pipeline of acquisitions), financial or, most often, both, with strategic fit screened first. The acquisition pipeline matters. In the United States in 2024, according to PitchBook and NVCA data, 1,083 of 1,147 venture-backed exits were acquisitions and only 42 were IPOs. Acquisition is the usual exit, so a corporate fund often doubles as a scouting channel for corporate development.

Give the corporate fund a thesis linked to roadmap needs over two to three years. Run pilots when investments fit. Use the thesis to resolve strategic and financial tensions.

Build, partner or buy

Laurence Capron and Will Mitchell’s resource-pathways research compares building, licensing, alliances and acquisitions. Their implementation trap is choosing the familiar route by habit. Use their sequence:

Ask the questions in order:

1. Are our internal resources relevant? If the knowledge, skills and organizational fit are close enough to what the new capability needs, build it.
2. If not, is the resource tradable? If a contract or license can define and protect what you need, borrow it by contract: license it or buy it as a service.
3. If not, how close do we need to be to the partner? If a bounded collaboration with aligned goals is enough, borrow it through an alliance, such as co-development or a joint program.
4. Only if deep integration is needed, and feasible, buy. Acquisition comes last.

Two 2026 additions fit the framework to AI products. The first is model-provider dependency: a team using a frontier model has already made a partner decision, often without calling it one. Inference cost, switching costs and contract terms belong in the analysis. The second is the talent-only path: since 2024, “buy” has split into buying a company, buying a team and licensing technology, and each option leaves customers in a different place.

Acquisitions, acqui-hires and license-and-hire

Acquisitions are the most expensive mechanism, with the worst reputation. Clayton Christensen, Richard Alton, Curtis Rising and Andrew Waldeck wrote in 2011 that study after study puts the failure rate of mergers and acquisitions “somewhere between 70% and 90%.” The range summarizes other studies and is contested, so treat it as a warning rather than a measurement.

The 2011 authors distinguish deals that leverage an existing business model from those that reinvent it. Compatible customers, processes and economics favor integration. A different model may need separation to preserve its value. State this choice in the acquisition brief.

The AI era added a new deal shape. In a license-and-hire deal (sometimes called a reverse acqui-hire), a large company hires a startup’s founders and key staff and pays a license fee for its technology, which lets investors get a return while a smaller company carries on. Four public deals show the pattern and its variations:

• Microsoft and Inflection, March 2024. Microsoft hired Inflection’s co-founders and most of its roughly 70 staff and paid about $650 million to license its technology. The UK Competition and Markets Authority treated the deal as a merger situation and cleared it in September 2024.
• Google and Character.ai, August 2024. Google hired co-founder Noam Shazeer and took a non-exclusive license to the company’s technology.
• Meta and Scale AI, June 2025. Meta agreed to buy a 49% non-voting stake for about $14.8 billion, and Scale’s chief executive, Alexandr Wang, joined Meta.
• Google and Windsurf, July 2025. Google reportedly paid about $2.4 billion in a license-and-hire deal for Windsurf’s chief executive and senior staff. Within days, on July 14, 2025, Cognition signed an agreement to acquire the rest of Windsurf: its intellectual property, product, brand, about $82 million of annual recurring revenue, more than 350 enterprise customers and the remaining staff, with vesting accelerated for all employees.

Compare buying a company, a team and technology. License-and-hire can weaken the remaining supplier. Full acquisition takes on customer contracts. Include target-customer continuity in the buying brief and supplier-risk monitoring.

Spin-outs make valuable noncore assets independent, as Byteboard and Metaphor illustrate. Decide whether to retain commercial ties, equity or neither. Balance autonomy with strategic options.

How to apply it

Use this method whenever a bet in the roadmap or innovation portfolio (Chapter 20) needs something normal delivery can’t provide. The selection steps take a few days of PM time.

Frame the bet.

1. Write the bet as a question, not a solution. “Can we convert runbooks into supervised agents that pass our safety evals?” is a question. “Build a runbook agent” is a solution looking for permission.
2. Place it on the horizon and ambition lenses from Chapter 20: core, adjacent or transformational; Horizon 1, 2 or 3. Note the time by which you need an answer.
3. Name the type of uncertainty that blocks it. Most bets are blocked by one of five: feasibility (can it be built?), desirability and adoption (will customers use it and will their security teams approve it?), availability (does someone already have it?), capability (do we have the skills and people?) or business model (can we make money from it?).

Choose the mechanism.

4. Map the uncertainty to a short list of mechanisms. Feasibility points to hackathons, internal prototypes and university partnerships. Desirability and adoption point to design partners and co-development. Availability points to venture client pilots and licensing. Capability points to training, partnerships, acqui-hires and acquisitions. Business model points to incubators and design partners, and at the far end to acquisitions that bring a proven model.
5. Run the build, partner or buy questions on the short list. Start with “are our internal resources relevant?” and move outward only when the answer is no. Add the two 2026 checks: model-provider dependency, and whether you need the team or only the technology.
6. Score the candidates on cost, time to an answer, control, customer impact and reversibility. Pick the cheapest mechanism that can answer the question in time. Write the reason down on the mechanism selector.

Plan the landing before the launch.

7. Name the receiving owner: the PM and engineering leader who will own the output if it works. If nobody will sign, stop here.
8. Reserve follow-on capacity in advance: a sprint, a quarter’s slot or a budget line, depending on the mechanism.
9. Set the decision date and the evidence that will decide it. Use the same discipline as an experiment card in Chapter 21: thresholds written before the work starts.
10. Bring in security, legal and procurement early for anything that touches outside parties or production data. Gatekeepers who hear last turn successful pilots into stalled ones.

Run, decide and record.

11. Run the mechanism using the plan for its type (the hackathon plan, design partner program plan or acquisition brief in this chapter).
12. On the decision date, make one of four calls: absorb into the roadmap, continue with a new question, hand to a different mechanism (a successful hackathon prototype often becomes a design partner pilot) or stop.
13. Record the decision and the evidence in the decision log, and update the portfolio view in Chapter 20. Chapter 23 covers how successful bets scale.

The AI lens

Building AI-powered products

AI changes the toolkit in four ways that matter for anyone building AI-powered products.

Your model provider is a partner decision. The FTC’s January 2025 report on major AI partnerships raised switching-cost, exclusivity and information-access concerns. Review those risks before deepening your own contract. Portable model interfaces and model-agnostic evaluations preserve options.

Connectors make partnering cheaper. Anthropic introduced the Model Context Protocol in November 2024 as an open standard for connecting AI assistants to the systems where data lives. Standard connectors lower the cost of several mechanisms. A design partner can connect a prototype to their own tools in days, a hackathon team can build against realistic systems instead of mock data, and a platform can open itself to partners by publishing an MCP server. That last one is an outbound open innovation move.

Agent prototypes need a judging rule. AI hackathons tend to produce agents that impress in a demo and fail on real cases. Erik Schluntz and Barry Zhang’s guidance on building effective agents (Anthropic, December 2024) supplies one. They distinguish workflows, where code fixes the sequence of model and tool calls, from agents, where the model directs its own steps and tool use. They recommend starting with the simplest solution, often a single well-grounded model call, and adding complexity “only when it demonstrably improves outcomes.” Ask every team which pattern it used, and for an eval result that justifies anything beyond a workflow. Chapter 31 covers evals.

Buy has new shapes. License-and-hire deals, minority stakes with key hires and full acquisitions of the remaining business are all now normal in AI. On the buying side, choose the shape by what customers need as well as what you need. If you depend on an AI startup as a supplier, a license-and-hire deal can take its founders and key engineers at short notice.

Doing the work with AI

An AI harness with connectors to your documents, CRM, support tickets and market research does much of the reading and drafting around each mechanism. You keep the judgment.

• Scouting. A harness can scan public information on startups in a problem space and draft a long list with the evidence for each claim. Whether a product works in your environment is a question for a venture client pilot.
• Selecting. Give the harness your bet, the five types of uncertainty and the mechanism table, and ask it to argue for and against each candidate. It’s a useful sparring partner because it names mechanisms you habitually skip, the implementation trap in action.
• Running hackathons. The harness can generate a sandbox data set, draft the eval cases from anonymized historical data and score submissions against them consistently. Judges still decide what matters.
• Running design partner programs. Partner calls, tickets and usage can be synthesized weekly, with every theme traced to the partners who raised it, which is how you enforce the several-partners rule.
• Diligence. For a partnership or acquisition, the harness can read public filings, documentation, security pages and customer reviews, and draft the questions you need answered. Treat its summaries as leads to verify. Anything that touches a confidential deal stays inside tools your company has approved for it, and within a small, named circle.

One widely quoted piece of evidence on building against partnering needs careful handling. In August 2025, Fortune reported on an MIT NANDA study, The GenAI Divide, which found that only about 5% of enterprise generative AI pilots delivered rapid revenue acceleration, and that buying from specialized vendors and partnering succeeded about 67% of the time while internal builds succeeded less often. The study’s methods (interviews, a survey and a small sample) have been publicly criticized. Use it as a reason to ask whether your team is building what it could buy, and not as proof that partnering wins.

If you run AI training for your product organization, borrow the residency pattern described earlier and end it with a shipped improvement to your own product.

The Beacon case: choosing mechanisms for the Beacon backlog

The four bets. You write each one as a question and name the uncertainty that blocks it.

The remediation safety bet comes straight out of the hallucinated root cause that led a customer to roll back the wrong service. Sam and the EU customers asking for AI Act documentation want evidence from someone other than Northlight. That’s why you pair an outside research partner with the internal eval team, instead of choosing one.

The hackathon. You plan “Beacon Agent Days,” a two-day event, using the twelve decisions. The goal is three runbook agents that pass an eval on sandbox incidents. The theme is supervised remediation. Teams cooperate and share a connector library. Priya and two customer SREs judge; Sam pre-approves sandbox access two weeks ahead. Preparation means a sandbox with MCP connectors and a replay of anonymized past incidents. The judging rule is measured diagnosis acceptance and safe action rate on the replay, not slide quality. For continuity, each winning agent gets a named PM owner and a one-sprint follow-on slot, agreed with engineering leadership before the event starts.

The design partner program. For the MSP console, you select partners on three criteria: multi-tenant scale, willingness to share incident data and an executive sponsor. Partners commit to a feedback session every two weeks and to sharing usage data; Northlight commits to early access, a named PM contact and price protection for the first contract year. You add the rule that matters most for a partner channel: a console feature ships only if at least three partners need it. Leo’s company is a partner, and so are MSPs that look less like Leo’s.

The build, partner or buy question. The biggest decision sits off the backlog list: the diagnosis model layer, which drives the margin problem. You work through the four questions.

• Are internal resources relevant? Partly. Northlight has Observe telemetry and a history of resolved incidents, which is the data needed to fine-tune smaller, cheaper models for diagnosis. It has only two applied AI engineers, so a full in-house model program isn’t realistic.
• Is the resource tradable? Yes. Frontier model access can be bought by contract, and the commercial terms can be negotiated.
• Is a bounded collaboration enough? For now, yes. A deeper commercial agreement with a model provider could lower inference cost. You list the risks the FTC report named (switching costs, exclusivity and access to sensitive data) as terms to negotiate.
• Is deep integration needed? Not yet. Buying a small team with inference-optimization skills is a real option, and you note it as the fallback if the partnership doesn’t move margin within two quarters.

Your recommendation: partner now, behind a portable abstraction layer and a model-agnostic eval suite, and build selectively where Observe data gives an edge, starting with a fine-tuned model for alert correlation. This eases the tension between using Observe data and staying tool-agnostic: the data advantage goes into the models, and the product stays open to other tools through its connectors.

The acquisition brief. Corporate development brings you a target: Kestrel, a fictional startup created for this example, which builds Kubernetes remediation agents with unusually strong evals. You write the brief. Kestrel leverages Beacon’s business model (same buyers, same incident workflow, compatible pricing), so it could be integrated rather than kept separate. You lay out four options in order of commitment: a venture client pilot first, a minority investment, a license-and-hire for the eval team, or a full acquisition. You note what each does to Kestrel’s own customers, because a license-and-hire would leave them with a hollowed-out supplier, the position Windsurf’s customers were in until Cognition bought the rest of the company. You set trigger conditions to proceed: the pilot must show Kestrel’s evals catch failure cases that Beacon’s current evals miss, on Beacon’s own incident replay, within eight weeks.

The decision. The VP approves all four mechanisms and the model partnership, and asks corporate development to start with the venture client pilot for Kestrel rather than a term sheet. Every mechanism has a receiving owner, and two of them are the other Beacon PMs.

Product 360 artifacts

# Innovation mechanism selector · [Bet name] · [Date]

**Owner:** [PM]   **Decision maker:** [Name]   **Answer needed by:** [Date]

## The bet as a question
[One question the roadmap can't answer yet. No solution language.]

## Placement (from the innovation portfolio, Chapter 20)
- Ambition: Core / Adjacent / Transformational
- Horizon: 1 / 2 / 3
- Why: [one or two sentences]

## Blocking uncertainty (pick the main one)
- [ ] Feasibility: can it be built?
- [ ] Desirability and adoption: will customers use it, and will their security teams approve it?
- [ ] Availability: does someone already have it?
- [ ] Capability: do we have the skills and people?
- [ ] Business model: can we make money from it?

## Candidate mechanisms
| Mechanism | Answers the question? | Cost (L/M/H) | Time to answer | Control | Customer impact | Reversible? |
|---|---|---|---|---|---|---|
| [e.g. hackathon] | | | | | | |
| [e.g. venture client pilot] | | | | | | |
| [e.g. design partners] | | | | | | |

## Build, partner or buy check
1. Internal resources relevant? [Yes / Partly / No, with evidence]
2. Resource tradable by contract? [Yes / No]
3. Bounded collaboration enough? [Yes / No]
4. Deep integration needed and feasible? [Yes / No]
- Model-provider dependency: [none / describe]
- Need the team, or only the technology? [team / technology / both]

## Choice
**Mechanism:** [name]   **Why this one:** [the cheapest mechanism that answers the question in time, and why]
**Rejected and why:** [one line each]

## Landing plan
- Receiving owner (PM and engineering lead): [names, signed]
- Follow-on capacity reserved: [sprint, quarter slot or budget]
- Gatekeepers involved from the start: [security, legal, procurement]
- Decision date: [date]   **Evidence that decides:** [thresholds set now]
- Possible outcomes: Absorb / Continue with new question / Hand to another mechanism / Stop

# Hackathon plan · [Event name] · [Dates]

**Sponsor:** [Exec]   **Owner:** [PM]   **Planning started:** [date, about four months ahead]

## 1. Goal
[What the roadmap needs answered. Measurable: e.g. "three prototypes that pass eval X".]

## 2. Theme
[One theme tied to a named bet.]

## 3. Competition or cooperation
[Choice and why. Shared assets teams can reuse.]

## 4. Stakeholder involvement
- Customer or partner participants and judges: [names]
- Security pre-approval of data and system access: [name, date]

## 5. Participant recruitment
[Who, how many, which skills. Include domain experts, not only engineers.]

## 6. Specialized preparation
- Sandbox environment and connectors: [list]
- Data set (anonymized, approved): [description]
- Eval set and scoring method: [description]
- Templates, starter code, model access: [list]

## 7. Duration and breaks
[Length, hours, rest. No overnight heroics unless chosen.]

## 8. Ideation
[Before or during the event; problem list seeded from customer evidence.]

## 9. Team formation
[How people find teams; maximum team size.]

## 10. Agenda
| Time | Activity |
|---|---|
| | Kickoff: goal, rules, judging |
| | Build |
| | Mentor check-ins |
| | Evaluation run on the shared eval set |
| | Presentations and judging |

## 11. Mentoring
[Who mentors on product, security, AI, domain.]

## 12. Continuity (agreed before the event)
- Each winning project gets: [named PM owner, follow-on slot, budget]
- Other outcomes we'll keep: [reusable components, connectors, eval cases, people to recruit into the bet]
- Decision review date: [date]

## Judging rules
- Measured results on the shared eval set: [weight]
- Customer value against the bet's question: [weight]
- Safety and security: [pass/fail gate]
- Demo polish: not scored

## Tensions we're managing
[Organizational vs personal goals; concept vs useful output; challenge vs achievable; speed vs quality.]

# Design partner program plan · [Product or capability] · [Dates]

**Owner:** [PM]   **Executive sponsor:** [Name]   **Program length:** [one to three quarters]

## Learning goals
1. [What we must learn about workflow]
2. [What we must learn about adoption and approval]
3. [What we must learn about pricing or packaging]

## Selection criteria
- Matches target segment: [criteria]
- Willing to share data: [what, under which agreement]
- Executive sponsor on their side: [required]
- Mix: [include at least one partner unlike the most enthusiastic one]
- Number of partners: [typically five to eight]

## Commitments
| Partner commits to | We commit to |
|---|---|
| Feedback sessions every [n] weeks | Early access to builds |
| Usage and outcome data shared | Named PM contact |
| [Reference or case study if successful] | [Pricing protection for first term] |
| [Security review in parallel] | [Roadmap visibility under NDA] |

## Rules for what ships
- A partner-requested feature ships only if [at least n] partners need it.
- Single-partner requests go to a separate log, reviewed at program end.
- No custom branches or one-off integrations.

## Cadence and evidence
- Weekly: synthesis of feedback, every theme traced to partners
- Monthly: progress against learning goals
- Thresholds that end the program early (positive or negative): [list]

## Exit
- End date: [date]
- Conversion terms to standard commercial contract: [summary]
- What happens to partners who don't convert: [plan]
- Data handling at exit: [return or delete]

# Build, partner or buy analysis · [Capability] · [Date]

**Owner:** [PM]   **Reviewers:** [engineering, finance, corporate development, security]

## Capability needed and why
[What the strategy requires, by when, and the cost of not having it.]

## The four questions
| Question | Answer | Evidence |
|---|---|---|
| 1. Are internal resources relevant (knowledge, skills, organizational fit)? | | |
| 2. Is the resource tradable (can a contract define and protect it)? | | |
| 3. Is a bounded collaboration enough (limited joint work, aligned goals)? | | |
| 4. Is deep integration needed, and is it feasible? | | |

## Options compared
| | Build | Partner (contract or alliance) | Buy (company, team or technology) |
|---|---|---|---|
| Time to capability | | | |
| Cost (one-time and ongoing) | | | |
| Control | | | |
| Effect on gross margin | | | |
| Switching cost later | | | |
| Effect on customers | | | |
| Talent risk | | | |
| Regulatory exposure | | | |

## AI-era checks
- Model-provider dependency: [which provider, terms, switching cost, what they can see]
- Exclusivity or limits on other partners: [terms]
- Portability: [abstraction layer, model-agnostic evals]
- Team or technology only? [answer]

## Our default path and the trap
[Which path this company usually takes, and whether this analysis is just repeating it.]

## Recommendation
[Path, scope, and the conditions that would trigger the next path.]
**Review date:** [date]

# Acquisition opportunity brief · [Target] · [Date] · Confidential

**Author:** [PM]   **Corporate development lead:** [Name]   **Distribution:** [named list only]

## The target in one paragraph
[What they build, for whom, stage, team, and why it came up.]

## Strategic fit
- Roadmap bet it answers: [bet]
- Capability gained: [technology, team, customers, data]
- Time saved against building: [estimate with reasoning]

## Leverage or reinvent?
- Value proposition: [same / different]
- Customers and buyers: [same / different]
- Sales motion and pricing: [compatible / different]
- Verdict: Leverages our model (integrate) / Reinvents it (keep separate)

## Options, in order of commitment
| Option | What we get | Cost | Effect on the target's customers | Reversible? |
|---|---|---|---|---|
| Venture client pilot | Evidence of fit | | Served as normal | Yes |
| Minority investment | Option and relationship | | Unchanged | Partly |
| License-and-hire | Team and technology | | Risk of stranding | No |
| Full acquisition | Everything, plus contracts | | Inherited | No |

## Integration risks
[Talent retention, product overlap, technology stack, culture, security posture.]

## Diligence questions
[Technical, eval quality, data rights, security, customer contracts, open-source licenses.]

## Regulatory and approval considerations
[Merger review, data transfer, sector rules. Confirm with legal.]

## Trigger conditions to proceed
[Measured results, by date, that would justify the next level of commitment.]

## Recommendation
[Next step only. Not the whole deal.]

# Venture client pilot charter · [Startup] · [Dates]

**Owner:** [PM]   **Startup contact:** [Name]   **Procurement:** [Name]   **Security:** [Name]

## Problem we're buying a solution to
[One paragraph, in customer terms.]

## Why buy rather than build
[Short answer from the build, partner or buy check.]

## Scope
- Workflow and environment: [where it runs]
- Data shared: [what, under which agreement]
- Duration: [weeks]
- Paid pilot value: [amount]

## Success criteria (set before the pilot)
| Measure | Threshold | Source |
|---|---|---|
| | | |

## Gates
- Security review completed by: [date]
- Purchase order issued by: [date]
- Mid-pilot check: [date]
- Decision: [date]

## Outcomes
- Pass: [contract path, owner, budget line]
- Partial: [what changes and one more cycle]
- Fail: [how we exit and what we keep]

Prompts

Goal: Pick the cheapest mechanism that can answer a roadmap question in time, and avoid your organization's habitual path.
Paste in: the bet, its horizon and ambition placement, the date you need an answer, your team's capacity and a list of the mechanisms your company already runs.

Act as a skeptical product leader helping me choose how to pursue this bet for [product].

1. Rewrite the bet as a single question with no solution language.
2. Name the main blocking uncertainty: feasibility, desirability and adoption, availability, capability or business model. Explain your choice.
3. Shortlist three mechanisms from this toolkit: idea challenge, hackathon, innovation training, intrapreneurship program, internal incubator, innovation lab, corporate venture capital, venture client pilot, open innovation program, design partners, university partnership, licensing, acquisition or license-and-hire, spin-out.
4. For each, give cost (low, medium, high), time to an answer, control, effect on customers and reversibility.
5. Run the build, partner or buy questions in order: internal resources relevant, resource tradable, bounded collaboration enough, deep integration needed.
6. Recommend one mechanism. Name the receiving owner role and the follow-on capacity it needs.
7. Tell me which mechanism I'm probably skipping out of habit, and why it might be better.

Use supplied company facts. Label additional assumptions explicitly.

[bet and context]

Check the output: confirm the recommendation actually answers the question you wrote in step 1. If it recommends the mechanism your company always uses, ask it to argue the strongest case for the second option.

Goal: Produce a hackathon plan that answers a roadmap question and has a landing plan before the event.
Paste in: the bet, the date range, likely participants, available sandbox systems and connectors, and any security constraints.

Draft a hackathon plan for [event] using these twelve decisions: goal, theme, competition or cooperation, stakeholder involvement, participant recruitment, specialized preparation, duration and breaks, ideation, team formation, agenda, mentoring and continuity planning.

Requirements:
- The goal must be measurable and tied to the bet.
- If teams build AI agents, the preparation must include a sandbox with approved data, an eval set and security pre-approval. The judging rule must reward measured results on the eval set over demo polish, and each team must state whether it built a workflow or an agent and justify any added complexity with an eval result.
- Continuity must name, for winning projects, an owner role, follow-on capacity and a review date.
- List the tensions we'll need to manage and how.

[context]

Check the output: if the continuity section could be deleted without changing anything else in the plan, it's too weak. Make sure no participant needs production data or credentials that security hasn't approved.

Goal: Set up a design partner program that produces learning without turning into custom work for one customer.
Paste in: the capability, learning goals, target segment and a candidate partner list with what you know about each. Remove personal details and use an approved tool for customer information.

Design a design partner program for [capability].

1. Propose selection criteria and score each candidate partner against them. Flag partners who are enthusiastic but unrepresentative of the segment.
2. Draft commitments in both directions.
3. Propose a rule for which partner requests ship, and a separate log for single-partner requests.
4. Set a cadence, the evidence we'll collect and thresholds that would end the program early.
5. Draft exit and conversion terms.

[context]

Check the output: count how many proposed partners look like your most enthusiastic customer. If it's most of them, change the mix. Have legal review any data-sharing terms before you share them.

Goal: Make a resource pathway decision with the evidence written down, including AI-era dependencies.
Paste in: the capability needed, the deadline, your team's relevant skills and assets, candidate partners or vendors, and any acquisition targets under consideration. Keep confidential deal information inside approved tools.

Analyze whether we should build, partner or buy [capability].

1. Answer in order: Are our internal resources relevant? Is the resource tradable by contract? Is a bounded collaboration enough? Is deep integration needed and feasible? Give the evidence for each answer, or say it's missing.
2. Compare build, partner and buy on time, cost, control, gross margin, switching cost, customer effect, talent risk and regulatory exposure.
3. For any AI capability, assess dependency on a model provider: switching cost, what the provider can see, exclusivity, and how to stay portable.
4. Say whether we need the team, the technology or both.
5. Name our likely default path and test whether this analysis is just confirming it.
6. Recommend a path and the conditions that would trigger the next one.

[context]

Check the output: every answer to the four questions should rest on evidence you supplied. Where the model filled a gap with a plausible guess, mark it and find out.

Goal: Get a first draft of a brief for a possible acquisition, using only public information, to structure the conversation with corporate development.
Paste in: the target's name, public material about it (website, documentation, public announcements, reviews) and your roadmap bet. Do not paste confidential deal information into an unapproved tool.

Draft an acquisition opportunity brief for [target] in relation to [our bet].

Sections: the target in one paragraph; strategic fit; whether it leverages or reinvents our business model (value proposition, customers, sales motion, pricing); options in order of commitment (venture client pilot, minority investment, license-and-hire, full acquisition) with the effect of each on the target's own customers; integration risks; diligence questions; regulatory considerations to raise with legal; trigger conditions to proceed.

Rules:
- Cite the public source for every factual claim about the target. If something isn't in the material, write "unknown."
- Keep valuation outside this assessment.

[material]

Check the output: open three cited sources and confirm the claims. Remove any fact without a source. Recommend only the next step, never the whole deal.

Goal: Find out which innovation mechanisms are changing product decisions and which are theater.
Paste in: a list of the organization's innovation programs from the past year, with outputs (projects, pilots, investments, events) and any record of what happened to them afterward.

Review these innovation programs for [organization].

For each program:
1. List the outputs and trace each one to a roadmap decision, shipped capability, partnership, hire or stop decision. Write "no trace" where none exists.
2. Identify whether a receiving owner and follow-on capacity existed before the program started.
3. Classify the program as landing, partly landing or theater, with the evidence.
4. Recommend: keep, fix (name the fix) or stop.

Then list outputs that are still waiting for an owner and suggest who should own each.

[program list and outcomes]

Check the output: confirm a sample of "landing" claims with the owners named. A program that lands only through one person's heroics is at risk; note it.

Anti-patterns

Checklist

• Every innovation bet is written as a question, placed on the horizon and ambition lenses, and tagged with its main blocking uncertainty.
• The chosen mechanism is the cheapest one that can answer the question in time, and the selector records why the others were rejected.
• The build, partner or buy questions were answered in order, with evidence, including model-provider dependency and team versus technology.
• A receiving owner has signed up, and follow-on capacity is reserved before the mechanism starts.
• Security, legal and procurement are involved from the start for anything that touches outside parties or production data.
• Hackathon plans cover all twelve decisions, judge AI prototypes on a shared eval set and plan continuity in advance.
• Design partner programs have selection criteria, commitments both ways, a multi-partner rule for features and an end date.
• Venture client pilots have success criteria, gates and a contract path set before they start.
• Acquisition briefs state whether the target leverages or reinvents the business model, compare options in order of commitment and show the effect on the target’s customers.
• Confidential deal and customer information stays inside approved tools and a named circle.
• The innovation portfolio is reviewed quarterly, and mechanisms with no changed decisions in a year are fixed or stopped.