Skill: quochungto/bookforge-product-okr-implementation (version 1.0.0)

--- name: product-okr-implementation description: "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." version: 1.0.0 homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/product-okr-implementation metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}} status: published source-books: - id: inspired-how-to-create-tech-products title: "INSPIRED: How to Create Tech Products Customers Love" authors: ["Marty Cagan"] chapters: [22, 23, 28, 29, 30, 60] tags: [product-management, okrs, product-strategy, roadmaps, business-objectives, team-alignment, scaling] depends-on: [] execution: tier: 1 mode: full inputs: - type: document description: "Company context: team count, current planning system (roadmap or OKR), key business objectives, and any stakeholder concerns about date commitments" tools-required: [Write] tools-optional: [Read] mcps-required: [] environment: "Any agent environment. Best with: current roadmap or OKR document, org chart, list of product teams." --- # Product OKR Implementation ## When to Use You are designing, auditing, or transitioning to an Objectives and Key Results system for a product and technology organization. Specific triggers: - Leadership wants to move from quarterly feature roadmaps to business-outcome planning - Product teams lack clear, shared priorities or conflict with functional managers on where to spend time - The organization is growing (25+ teams) and alignment is breaking down - Stakeholders (sales, marketing) are demanding date commitments that product teams cannot responsibly make - Existing OKRs feel like tasks and deliverables rather than measurable business outcomes - Design, engineering, or QA departments have created their own OKRs that conflict with product team work ## Why Roadmaps Fail (The Two Inconvenient Truths) Before implementing OKRs, the organization must internalize why feature roadmaps produce poor business results: 1. **At least 50% of product ideas will not work.** Customers may not value the idea, find it too complex to use, or the business constraints make it undeliverable. This is not a failure — it is the nature of product work. 2. **Even ideas that are valuable typically require several iterations** before they deliver the expected business outcome. Time-to-money is rarely the first shipped version. When a list of features is published on a roadmap, the entire company interprets every item as a commitment — regardless of disclaimers. This forces teams to deliver features even when those features do not solve the underlying business problem. The solution is to give teams business outcomes to achieve and let them discover the best solutions. ## Core OKR Structure **Objectives** are qualitative statements of what the organization or team is trying to accomplish. They are aspirational and directional, not measurable. **Key Results** are quantitative measures of whether the objective was achieved. They measure *business results*, not outputs or tasks. Shipping a feature is never a key result. Changing a metric is. Example: - Objective: "Dramatically reduce the time it takes for a new customer to go live" - Key Result: "Average new customer onboarding time less than three hours" ## The 12 OKR Rules for Product Organizations All 12 rules below are required. See `references/okr-12-rules.md` for extended implementation guidance and worked examples. **Rule 1 — Objectives qualitative, key results quantitative.** Objectives are aspirational narrative statements. Key results are specific numbers with a baseline and a target. If a key result cannot be measured, it is not a key result — it is a task. **Rule 2 — Key results measure business outcomes, not output or tasks.** "Ship the mobile app" is output. "Increase mobile daily active users from 12k to 20k" is a business outcome. Key results must measure a change in business or customer behavior, not the completion of work. **Rule 3 — Only two levels: organization OKRs and product team OKRs.** Do not create OKRs for functional departments (design, engineering, QA) or for individuals. Functional OKRs conflict with product team OKRs and pull individuals in incompatible directions. See the Anti-Pattern section below. **Rule 4 — Annual cadence for organization objectives; quarterly cadence for team objectives.** Company-level objectives change rarely — annually or when strategy changes. Product team objectives change quarterly to reflect current priorities and market conditions. Do not run both at the same quarterly cadence — the organization loses strategic continuity. **Rule 5 — Scope small: 1–3 objectives per team, 1–3 key results per objective.** More than 3 objectives signals the team has no priorities. A team with 7 key results is covering everything and will achieve nothing. Force prioritization — if everything is important, nothing is. **Rule 6 — Track progress against objectives weekly.** OKRs are not a quarterly ritual. Teams should reference their key results in weekly check-ins, note current values versus targets, and call out blockers or drift. Without weekly tracking, teams discover at quarter-end that they were off-track for months. **Rule 7 — Objectives do not need to cover every team activity.** Teams do ongoing work (maintenance, support, on-call) that is not captured in OKRs. OKRs capture only what the team needs to *accomplish* — the outcomes they are accountable for changing. This is a scope boundary, not a problem. **Rule 8 — Substantial failure triggers a post-mortem.** If a team scores significantly below 0.3 on an objective, they are expected to conduct a post-mortem with peers or management: what went wrong, what was learned, and what will change. This is not punitive — it is how accountability functions without blame. **Rule 9 — Use a consistent, agreed-upon scoring rubric across the organization.** Every team must use the same 0 / 0.3 / 0.7 / 1.0 rubric (defined in the Scoring section below). Without shared standards, team scores are incomparable and coordination signals break down. **Rule 10 — Distinguish high-integrity commitments from normal OKR key results.** High-integrity commitments are binary (delivered / not delivered) and scored separately. They are never part of the normal OKR scoring curve. See the High-Integrity Commitments section below. **Rule 11 — Full transparency: every team's objectives and scores are visible organization-wide.** Every product and technology team can see every other team's objectives, key results, and current progress. This enables coordination, surfaces duplication, and creates peer accountability. Hidden OKRs are not OKRs — they are private goal-setting. **Rule 12 — Ownership hierarchy: senior management owns organization OKRs; product/technology leadership owns product team OKRs; individual teams propose key results.** The CEO or executive team defines the organization objectives. Heads of product and technology assign those objectives to specific teams. Teams then *propose* the key results they believe will demonstrate progress. Leadership reviews the proposals for gaps and adjusts. This give-and-take is the mechanism for alignment without top-down dictation. ## OKR Scoring Rubric Use this rubric consistently across the organization so teams can depend on each other's signals: | Score | Meaning | |-------|---------| | **0.0** | No meaningful progress made | | **0.3** | Bare minimum — delivered only what was already certain to be achievable | | **0.7** | Hoped-for result — accomplished more than the minimum, achieved what the team set out to do | | **1.0** | Exceptional — truly surprised the organization, exceeded what anyone was hoping for | For normal OKRs, teams should aim for 0.7. Consistently scoring 1.0 means targets are set too low. Scoring below 0.3 consistently requires examination. **High-integrity commitments are scored differently:** they are binary. Either the commitment was delivered or it was not. Do not apply the 0–1.0 scale to a high-integrity commitment. ## High-Integrity Commitments High-integrity commitments resolve the tension between stakeholders who need date certainty (hiring plans, marketing spend, contracts, partnerships) and product teams that cannot responsibly commit before knowing what they need to build. **The root cause of bad commitments is timing.** Commitments made before product discovery are made without knowing: what to build, whether it will solve the problem, or how long it will actually take. **The protocol:** 1. When an external date commitment is needed, the product team asks for a short product discovery period first — typically days or weeks, not months. 2. During discovery, the team validates the solution with customers (value, usability), with engineers (feasibility), and with the business (viability). 3. After discovery establishes a solution that works, the team makes a high-integrity commitment: a specific date and deliverable that stakeholders can depend on. 4. Delivery managers track these commitments and their dependencies. Engineers' estimates alone are insufficient — the team may be occupied on other work and unable to start immediately. **Use high-integrity commitments sparingly.** Good product organizations minimize them. When they are made, the organization must be able to depend on delivery. ## Anti-Pattern: Functional OKR Cascade **What happens:** When organizations first adopt OKRs, each functional department (design, engineering, QA) creates OKRs for their own organization: - Design: "Move to responsive design by Q3" - Engineering: "Improve architecture scalability by 40%" - QA: "Implement full test automation" **Why it breaks product teams:** The individuals on those functional teams are also members of cross-functional product teams. Those product teams have business-related objectives (reduce acquisition cost, increase daily active users, reduce onboarding time). But each person receives a separate set of objectives that cascade down through their functional manager. Result: engineers are told to work on re-platforming; designers on responsive design; QA on retooling. These may be worthwhile activities. But the cross-functional product team cannot solve its business problems if its members are pulled in incompatible directions. **The correct model:** OKR cascading in a product organization runs *upward* — from cross-functional product teams to company or business unit level. Functional leaders (head of design, head of engineering) may have their own organizational objectives (strategy for responsive design, managing technical debt) but these are management-level concerns, not individual contributor conflicts. If functional concerns like technical debt or design systems need to be addressed, they should be prioritized at the leadership level alongside business objectives and then *incorporated into relevant product team objectives*. ## OKRs at Scale (25+ Teams) When a product organization has 25 or more product teams, standard OKR mechanics require additional structure: **1. Leadership must cascade objectives before teams propose key results.** With 25 teams, not all can pursue all objectives. Leadership (head of product, head of technology, head of design) must first determine which teams are best suited to pursue each organizational objective. Teams then propose key results for the objective(s) they have been assigned. **2. Multiple teams share objectives.** Some objectives require contribution from several teams. Leadership coordinates this, identifies dependencies, and ensures teams are not duplicating effort or working at cross-purposes. **3. Platform and shared services teams need separate treatment.** At scale, platform product teams (shared services teams) serve other product teams indirectly rather than customers directly. Leadership must coordinate these teams' objectives to ensure they support the objectives of solution-facing teams. **4. Leadership runs a reconciliation process.** After teams propose key results, leadership reviews the aggregate to identify gaps — business outcomes that no team is covering — and adjusts team assignments or reprioritizes accordingly. **5. Delivery managers actively track high-integrity commitments.** At scale, the list of external commitments grows and dependencies multiply. Delivery managers are responsible for tracking which commitments exist, which teams own them, and whether dependencies are being met. **6. Enterprise organizations add a business unit layer.** In companies with multiple business units, the hierarchy is: corporate OKRs → business unit OKRs → product team OKRs. Product teams roll up into the business unit, not directly to corporate. ## Roadmap-to-Outcomes Transition Protocol (6–12 Months) For organizations where leadership is committed to the quarterly feature roadmap and cannot switch overnight: **Phase 1 — Parallel run (months 1–6):** - Continue the existing roadmap process without disruption - For every roadmap item referenced in a meeting, presentation, or document, immediately add the business outcome that feature is intended to affect, plus the current baseline metric - Example: "Adding PayPal as payment method — intended to increase conversion rate, which is currently 2.3%" - This trains the organization to see the *why* behind features, not just the what **Phase 2 — Impact reporting (months 3–12):** - After each feature ships, report the actual impact on the business metric - If impact is positive: celebrate it and attribute it to the outcome, not the feature - If impact is neutral or negative: explicitly communicate that shipping the feature was not the goal — improving the metric was. The outcome was not achieved. Share what was learned and what the team will try next - This is the key cultural shift: the team is not off the hook when the feature ships; they are off the hook when the metric moves **Phase 3 — Outcome graduation:** - Over time (can take up to a year), the organization develops the habit of evaluating work by business results rather than feature delivery dates - Stakeholders gain confidence that teams are working on the most important items (visible through OKR transparency) and that critical dates will be honored (through high-integrity commitments) - The roadmap becomes unnecessary because it served two purposes — priority visibility and date commitments — and the OKR system plus high-integrity commitments serve both more reliably ## Output Template Use this template to produce a complete OKR document for a product organization: ```markdown # [Company/Organization] OKR Document Quarter: [Q? YYYY] | Organization: [Product & Technology] --- ## Organization Objectives ### O1: [Qualitative objective statement] Owned by: [CEO / executive team] | Key Result | Baseline | Target | Score | |------------|----------|--------|-------| | [Quantitative business metric + target] | [Current value] | [Goal value] | — | | [Quantitative business metric + target] | [Current value] | [Goal value] | — | --- ## Product Team OKRs ### Team: [Team Name] Owned by: [Product Manager name] Contributing to: O[n] **Objective:** [Qualitative statement] | Key Result | Baseline | Target | Score | |------------|----------|--------|-------| | [Business metric + target] | [Current] | [Goal] | — | | [Business metric + target] | [Current] | [Goal] | — | **High-integrity commitments this quarter:** - [ ] [Specific deliverable] — due [date] — owner: [name] --- ## Scoring Reference 0.0 = no progress | 0.3 = bare minimum | 0.7 = hoped-for | 1.0 = exceptional High-integrity commitments: binary (delivered / not delivered) --- ## Weekly Check-In Log | Week | Team | KR | Current Value | Trend | Blocker | |------|------|----|---------------|-------|---------| ``` ## References - `references/okr-12-rules.md` — Full text of all 12 OKR rules with implementation guidance - `references/functional-cascade-examples.md` — Before/after examples of functional vs. product team OKR structures ## License This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/). Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan. ## Related BookForge Skills This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

path: references/functional-cascade-examples.md
content: # Functional OKR Cascade: Before and After

Source: INSPIRED, Chapter 29 (Cagan)

---

## The Anti-Pattern: Functional Department OKRs

When organizations first adopt OKRs, there is a natural instinct to give each functional department its own OKRs. This feels logical — each discipline has professional concerns that matter.

### Example: Functional OKRs for a product team member

**Design department OKR:**
- Objective: Modernize user experience
- KR: Migrate 100% of product surfaces to responsive design by Q3

**Engineering department OKR:**
- Objective: Improve system reliability
- KR: Re-platform authentication service to new infrastructure

**QA department OKR:**
- Objective: Increase release confidence
- KR: Achieve 80% automated test coverage across all modules

A specific individual — say, a frontend engineer — receives all three signals:
- Their product team needs them focused on reducing customer acquisition cost
- Their engineering manager needs them focused on re-platforming
- Their QA manager (if they own shared tooling) expects automation coverage improvements

**Result:** The individual cannot focus. The product team cannot solve the business problem it was formed to solve. Leadership sees poor results and blames the team.

---

## The Correct Pattern: Product Team-Level OKRs

The same functional concerns (responsive design, technical debt, test automation) are legitimate — but they belong in the leadership agenda, not in the individual contributor's objective stack.

**How to handle legitimate functional concerns:**

1. The head of design identifies that responsive design is a strategic need
2. This concern is raised at the leadership team level alongside business objectives
3. Leadership decides which product teams should incorporate responsive design work into their objectives for the quarter
4. The product team objective becomes: "Improve mobile conversion rate" — and responsive design may be one solution they explore

The functional concern is now channeled through the product team objective rather than creating a parallel obligation.

**Product team OKR (correct):**
- Objective: Make it significantly easier for new customers to activate
- KR: Reduce time from signup to first value event from 14 days to 3 days
- KR: Increase 7-day activation rate from 22% to 40%

The engineer, designer, and QA engineer on this team all work toward the same outcome. Their skills are means, not ends.

---

## Who Can Have Their Own OKRs

| Role | Own OKRs? | Reasoning |
|------|-----------|-----------|
| Cross-functional product team | Yes | Primary unit of product delivery |
| Organization (CEO + exec team) | Yes | Sets strategic direction |
| Functional manager (head of design, head of engineering) | Yes, carefully | Not on a product team; organizational objectives are their job |
| Individual contributor on a product team | Small personal growth only | Must not conflict with product team contribution |
| Functional department as a group | No | Creates dual-reporting confusion and conflicting priorities |

---

## The Direction of Cascade

**Wrong direction (functional cascade):**
Corporate → Business unit → Design department → Design team member

**Right direction (product team cascade):**
Corporate → Business unit → Product team → (team proposes KRs up)

The cascade runs *upward* from product team key results to company objectives — product teams propose how they will contribute to the organization's objectives. It does not run *downward* from functional hierarchies through individual contributors.


path: references/okr-12-rules.md
content: # The 12 OKR Rules for Product Organizations

Source: INSPIRED, Chapters 28–30 (Cagan)

These rules are specific to the product management, design, and technology organization. Other parts of the company may use OKRs differently.

---

## Rule 1: Objectives are qualitative; key results are quantitative

Objectives describe direction and aspiration. They should be motivating and clear but are not measurable by themselves.

Key results must be specific numbers that can be objectively evaluated. If there is no number, it is not a key result — it is a task or milestone.

Wrong KR: "Launch the new onboarding flow"
Right KR: "Reduce median time-to-first-value from 14 days to 3 days"

## Rule 2: Key results measure business outcomes, not output or tasks

Key results track whether the business moved — not whether the team shipped something. Shipping is an activity. The question is whether the shipping changed a metric that matters.

Wrong KR: "Deliver payment redesign by March 15"
Right KR: "Increase checkout completion rate from 61% to 75%"

## Rule 3: Focus OKRs at the organization and product team level

For the product and technology organization, there are two valid levels:
- Organization-level OKRs (owned by senior leadership)
- Product team-level OKRs (one set per cross-functional product team)

Functional department OKRs (design OKRs, engineering OKRs, QA OKRs) and individual OKRs for people who sit on product teams create conflicting priorities and should be avoided. See `functional-cascade-examples.md`.

Exception: Functional managers (head of design, head of engineering) who do not sit on product teams may have their own objectives. Individual contributors may have a small number of personal growth objectives, as long as these do not interfere with their product team contributions.

## Rule 4: Annual cadence for organization; quarterly cadence for teams

Organization objectives should be stable enough to last a year. Changing them mid-year signals poor strategic clarity.

Product team objectives refresh quarterly, allowing teams to respond to what was learned in the prior quarter and to what changed in the business.

## Rule 5: Keep the number of objectives and key results small

1–3 objectives per organization or team. 1–3 key results per objective.

More than three objectives at the team level is not focus — it is a task list. Teams that struggle to select three objectives have not made hard prioritization decisions.

## Rule 6: Teams track progress against objectives weekly

Weekly check-ins are not status theater. They are the mechanism by which teams catch problems early, surface blockers to leadership, and maintain accountability to the outcomes they committed to. Quarterly-only reviews are too infrequent to course-correct.

## Rule 7: Objectives do not need to cover every team activity

Teams do ongoing maintenance, bug fixes, technical work, and support activities that are not captured in OKRs. Objectives cover what the team *needs to accomplish* — the meaningful outcomes that require focused effort and represent the team's highest-priority contribution to the business.

## Rule 8: Teams are accountable; failure triggers post-mortems

Accountability means something. Teams that consistently miss objectives should conduct retrospectives with peers or management. The goal is not punishment but learning: did the team set targets that were too ambitious? Did they encounter blockers? Did the key results turn out to be the wrong metrics?

Accountability without inquiry produces fear. Inquiry without accountability produces drift.

## Rule 9: Agree on a consistent scoring rubric organization-wide

| Score | Meaning |
|-------|---------|
| 0.0 | No meaningful progress |
| 0.3 | Bare minimum — only what was already certain to be achievable |
| 0.7 | Hoped-for — accomplished what the team set out to do |
| 1.0 | Exceptional — truly surprised the organization |

Consistency matters more than the specific scale. When every team uses the same rubric, scores communicate real signal. When teams calibrate their own scores privately, the numbers are meaningless for cross-team comparison.

Teams should generally aim for 0.7. An organization where every team scores 1.0 every quarter is setting targets too low.

## Rule 10: Distinguish high-integrity commitments from normal OKRs

High-integrity commitments are specific deliverables promised to external parties (customers, partners, other business functions) with a specific date. They exist because the business sometimes must coordinate across functions with hard dependencies.

They are different from OKR key results in two ways:
1. They are negotiated and date-bound after product discovery, not before
2. They are scored as binary: delivered on time or not delivered

For high-integrity commitments, 0.7 is not acceptable. The organization depends on these.

## Rule 11: Full transparency across the product and technology organization

Every team's objectives and current progress scores should be visible to every other team and to leadership. Transparency prevents redundancy, surfaces dependency conflicts early, and creates social accountability that supplements formal accountability structures.

## Rule 12: Ownership hierarchy

| Level | Owns |
|-------|------|
| Senior management (CEO, executive team) | Organization objectives and key results |
| Heads of product and technology | Product team objectives (ensuring alignment with organization objectives) |
| Individual product teams | Proposed key results for each objective they have been assigned |

The give-and-take process each quarter: leadership assigns objectives to teams; teams propose the key results they believe will demonstrate achievement of those objectives; leadership reviews the aggregate across teams, identifies gaps, and negotiates adjustments.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)