Product Okr Implementation

Design and implement an OKR (Objectives and Key Results) system for product teams. Use when transitioning away from feature roadmaps to outcome-based planning, setting up OKRs for a product organization, replacing quarterly roadmaps with business objectives, aligning multiple teams to shared goals, or when someone asks 'how do we set up OKRs?' Also use when diagnosing OKR cascade failures, structuring high-integrity commitments to stakeholders, establishing OKR scoring standards, running quarterly OKR planning cycles, or scaling OKRs to 25+ teams. Covers the 12 OKR rules, scoring rubric, functional cascade anti-patterns, and a 6–12 month roadmap-to-outcomes transition plan. Not for diagnosing team health or culture — use product-team-health-diagnostic or product-culture-assessment instead.

Install

Claude CodeClawhHubnpxCursorCodexGemini CLI

1. Add marketplace

› /plugin marketplace add bookforge-ai/bookforge-skills

2. Install plugin

› /plugin install inspired-how-to-create-tech-products@bookforge-skills

3. Use the skill

› /product-okr-implementation

CC-BY-SA · Open sourceGitHub

Source Book

INSPIRED: How to Create Tech Products Customers Love

Marty Cagan

More from INSPIRED: How to Create Tech Products Customers Love

Product Managementfull

Business Viability Stakeholder Testing

Test whether a product solution is viable for the business before building. Use when business viability risk is Medium or High, when multiple internal functions (legal, sales, finance, marketing) may have constraints on a proposed solution, when someone asks 'will this work for our business?', 'do we have stakeholder buy-in?', or 'does legal/finance/sales need to review this?' Also use when a proposed solution would change pricing, go-to-market motion, or support model, or when you need documented cross-functional sign-off before committing engineering resources. Identifies all stakeholders who can veto launch across 8 domains, conducts 1:1 preview sessions with high-fidelity prototypes, and resolves disagreements with evidence rather than opinions. Produces a structured viability sign-off document. Not for customer value testing — use value-testing-technique-selection. Not for product-market fit — use customer-discovery-program.

Product Managementplan-only

Customer Discovery Program

Design a customer discovery program to achieve product-market fit for a significant new product or market expansion. Use when launching a new product, entering a new market segment, redesigning a product for a different customer segment, or when someone asks 'how do we find product-market fit?', 'how do we get reference customers?', or 'are we stuck in a sales-driven fragmentation spiral?' Also use when the team is unsure if they have achieved product-market fit, when scaling sales feels premature, or when checking whether the Sean Ellis test applies. Produces a complete program plan: single target market definition, recruitment criteria for 6 reference customers, co-development relationship structure, and product-market fit definition by product type (B2B, platform/API, consumer, internal). Not for small features or minor improvements — use value-testing-technique-selection for those.

Product Managementfull

Discovery Framing Technique Selection

Select and execute the right discovery framing technique before building. Use when value risk is High and the underlying problem is not yet clearly defined, when a team is about to start discovery without a shared problem statement, when someone asks 'how should we frame this discovery effort?', or when starting any non-trivial feature, redesign, or new product effort. Also use for: writing an opportunity assessment, writing a customer letter (press release alternative), completing a startup canvas for a new business, or constructing a story map to scope discovery. Determines effort size (typical/large/new-product), selects the matching technique, and produces the framing document. Best triggered after product-discovery-risk-assessment. For specific testing techniques, use value-testing-technique-selection. For prototype selection, use discovery-prototype-selection.

Product Managementhybrid

Discovery Prototype Selection

Select the right prototype type and fidelity level for any discovery risk. Use when deciding what kind of prototype to build, when choosing between a feasibility spike, user prototype, live-data prototype, or Wizard of Oz prototype, or when someone asks 'what prototype should we build?' Also use when prototyping for usability testing, when validating a technical approach before building, when building a simulation for stakeholder alignment, or when an AI/ML feature needs pre-model validation. Maps the active risk (feasibility/usability/value/viability) to one of four prototype types and determines fidelity. Includes anti-pattern warnings for ambush estimation and prototype-as-value-proof confusion. Best triggered after product-discovery-risk-assessment. For executing usability or value tests after the prototype, use value-testing-technique-selection.