Skill: quochungto/bookforge-product-team-health-diagnostic (version 1.0.0)

--- name: product-team-health-diagnostic description: | Diagnose why a product team or organization is slow, not innovative, or delivering poor outcomes. Use when a leader or team observes slow velocity, lack of innovation, poor product quality, feature factory behavior, or team dysfunction — and needs root causes and a prioritized fix list. Also use when a new product leader is assessing an organization, when a CEO or board says teams are too slow, or when someone says 'why are we not shipping faster?', 'engineering and design aren't collaborating', 'we ship but nothing moves the needle', or 'I need to assess team health before proposing changes.' Scores 42 diagnostic criteria across team behaviors, innovation capacity, velocity killers, and design integration. Produces a severity-ranked report with a composite health score and remediation priorities. For culture-level issues (innovation vs. execution quadrant), use product-culture-assessment. For process-level waterfall diagnosis, use product-process-dysfunction-diagnosis. version: 1.0.0 homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/product-team-health-diagnostic metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}} status: published model: sonnet context: 200k execution: tier: 1 mode: full inputs: - type: document description: "Observations, notes, or description of the team/organization being assessed" - type: none description: "Skill can work from a verbal description of what the assessor observes" tools-required: [Read] tools-optional: [] environment: "No codebase access required; works from observations and descriptions" source-books: - name: inspired-how-to-create-tech-products chapters: [11, 64, 65, 66] depends-on: [] tags: [product-management, team-assessment, product-teams] --- # Product Team Health Diagnostic ## When to Use Use this skill when you are: - **New to a leadership role** — need a structured baseline assessment of product team health before making changes - **Responding to CEO/board concerns** — told teams are "too slow" or "not innovative" and need to diagnose root causes - **Running an org health review** — periodic check on whether teams are operating in a strong or weak product model - **Preparing a remediation plan** — need to prioritize which problems to fix first and justify the investment - **Onboarding a coach or consultant** — need a common diagnostic language to align on what's broken Preconditions: you have at least one of: - Direct observations of team behaviors over at least a few weeks - A written description of how teams operate (processes, rituals, structure) - Interview notes or survey data from team members - Access to team artifacts (roadmaps, sprint boards, release logs, design files) **Agent:** Clarify the scope before beginning — are you assessing one team, a portfolio of teams, or the entire engineering/product organization? The scoring applies per team; an org-level report aggregates across teams. --- ## Assessment Process ### Step 1 — Gather Observations Collect evidence for each of the 4 diagnostic categories. WHY: each category targets a distinct failure mode — behavioral dysfunction (Ch64), structural innovation blockers (Ch65), process velocity killers (Ch66), and design integration failures (Ch11). Mixing them obscures root cause. For each category, ask the assessor (or yourself) the following: **Category A — Team Behaviors (18 criteria)** Source: Ch64. These contrast what strong teams do vs. what weak teams do. Ask: - What drives the team's ideas — vision and customer insight, or stakeholder requests and sales? - How does the team relate to engineers — do they co-discover, or do engineers only see designs at sprint planning? - Does the team engage real customers weekly, or do they rely on internal assumptions? - How does the team measure success — business impact achieved, or features shipped? - See full criteria: `references/diagnostic-criteria.md#category-a` **Category B — Innovation Capacity (10 criteria)** Source: Ch65. These are organizational attributes that determine whether consistent innovation is even possible. Ask: - Is there direct, frequent customer contact at the team level? - Does the organization have a compelling, current product vision? - Are product managers strong and capable, or weak and order-takers? - Are engineers included from the beginning of ideation? - See full criteria: `references/diagnostic-criteria.md#category-b` **Category C — Velocity Killers (10 criteria)** Source: Ch66. These are the structural and process causes of slowness. Ask: - What is the current release cadence? (Benchmark: minimum every 2 weeks; great teams release multiple times per day) - Is there significant accumulated technical debt impeding the architecture? - Is there a delivery manager role actively removing impediments? - Are priorities stable, or do they shift frequently? - See full criteria: `references/diagnostic-criteria.md#category-c` **Category D — Design Integration (4 criteria)** Source: Ch11. These identify whether design is integrated as a discovery partner or treated as a service. Ask: - Who produces wireframes or interaction designs — a trained product designer, or the PM? - Are designers embedded with the product team, or do they operate as an internal agency? - Is design involved from the inception of each idea, or does it come in after requirements? - See full criteria: `references/diagnostic-criteria.md#category-d` --- ### Step 2 — Score Each Criterion WHY: Scoring converts qualitative observations into a comparable signal, making it possible to prioritize and track improvement over time. For each of the 42 criteria, assign one of three scores: | Score | Meaning | |-------|---------| | **2** | Healthy — the team clearly exhibits the strong behavior | | **1** | Partial — the behavior is inconsistent or only sometimes present | | **0** | Absent — the weak behavior is the norm | **Scoring rules:** - Score what you observe, not what the team says they do. WHY: teams frequently describe aspirational practices. - When evidence is ambiguous, default to 1 (partial), not 2. WHY: over-scoring masks real problems. - For Category C, Item 4 (release cadence): score 2 if releases happen at least every 2 weeks, 0 if monthly or less, 1 if inconsistent. --- ### Step 3 — Calculate Category and Composite Scores For each category, calculate: ``` Category score = (sum of item scores) / (max possible score) × 100 ``` | Category | Items | Max Score | |----------|-------|-----------| | A — Team Behaviors | 18 | 36 | | B — Innovation Capacity | 10 | 20 | | C — Velocity Killers | 10 | 20 | | D — Design Integration | 4 | 8 | | **Composite** | **42** | **84** | WHY: Keeping categories separate prevents a strong score in one area from masking a critical failure in another. A team can be fast (good C score) but consistently build the wrong things (low A score). --- ### Step 4 — Classify Severity WHY: Not all scores below 100% require equal urgency. This classification focuses remediation effort. **Per-category thresholds:** | Score | Severity | Interpretation | |-------|----------|----------------| | 80–100% | Healthy | Maintain; minor tuning only | | 60–79% | Caution | Targeted improvements needed | | 40–59% | Degraded | Structural issues present; prioritize fixes | | 0–39% | Critical | Fundamental dysfunction; urgent intervention required | **Red flags — any single criterion scoring 0 in these areas triggers automatic Critical classification for that dimension, regardless of category average:** - Team behaviors: engineers excluded from discovery (criterion A9) - Innovation: no customer-centric culture (criterion B1), no compelling vision (criterion B2) - Velocity: infrequent releases — monthly or less (criterion C4) - Design: design not involved in discovery (criterion D4) WHY: These specific items represent systemic dysfunctions that a higher average cannot compensate for. --- ### Step 5 — Produce the Diagnostic Report Structure the output as follows: ``` ## Product Team Health Diagnostic Report **Organization/Team:** [name] **Assessment Date:** [date] **Assessor:** [role] --- ### Composite Score: [X/84] — [XX%] — [SEVERITY] | Category | Score | % | Severity | |----------|-------|---|----------| | A — Team Behaviors | X/36 | XX% | [label] | | B — Innovation Capacity | X/20 | XX% | [label] | | C — Velocity Killers | X/20 | XX% | [label] | | D — Design Integration | X/8 | XX% | [label] | --- ### Red Flags (Criteria scoring 0 that require immediate attention) [List each, with one sentence describing the observed symptom] --- ### Category Findings #### A — Team Behaviors **Strengths:** [criteria scoring 2] **Gaps:** [criteria scoring 0 or 1, with observed evidence] #### B — Innovation Capacity [same format] #### C — Velocity Killers [same format] Note: Release cadence benchmark — minimum every 2 weeks; great teams release multiple times per day. #### D — Design Integration [same format] --- ### Prioritized Remediation Plan Ordered by: (1) Critical severity first, (2) within severity by cross-category impact | Priority | Issue | Category | Current State | Target State | Estimated Effort | |----------|-------|----------|---------------|--------------|-----------------| | 1 | ... | ... | ... | ... | ... | --- ### Summary Narrative [3–5 sentences: what is working, what is broken, and the single most important thing to fix first and why] ``` --- ### Step 6 — Validate the Assessment Before delivering the report, verify: - [ ] Every scored criterion has supporting evidence, not assumption - [ ] Red flags are confirmed, not inferred - [ ] The prioritized remediation plan addresses root causes, not symptoms - [ ] The summary narrative is actionable — it tells the reader what to do, not just what is wrong WHY: Diagnostic reports are only useful if they drive decisions. Vague findings ("culture needs improvement") create no action. Specific findings ("engineers first see features at sprint planning — exclude from discovery") point to a concrete fix. --- ## Interpreting Results **Common misread — high velocity, low innovation:** A team can score well on Category C (velocity) while scoring poorly on Category B (innovation). This is the "feature factory" pattern — teams ship fast but build the wrong things. The fix is upstream (discovery and vision), not downstream (process acceleration). **Common misread — blaming individuals:** Low PM capability scores (B4, C2) often reflect structural issues — PMs who are order-takers because leadership treats them as such. Diagnose whether the PM is weak, or whether the PM has been structurally prevented from being strong. **Common misread — design as optional:** Category D scores are frequently rationalized ("we're a B2B company, design matters less"). The book is explicit: strong design is a competitive differentiator in B2B, and companies that treat it as optional are being displaced. **The innovation/velocity relationship:** Chapters 65 and 66 share several root causes (weak PMs, engineers excluded, no vision). Fixes to these shared causes yield compound improvements across both dimensions. --- ## Reference Full 42-criterion reference table with good/bad behavior descriptions: `references/diagnostic-criteria.md` ## 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 by Unknown. ## Related BookForge Skills This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

path: references/diagnostic-criteria.md
content: # Diagnostic Criteria — Full Reference

All 42 criteria across 4 categories. Each criterion has a "healthy" state (score 2) and a "dysfunction" state (score 0).

Source: INSPIRED: How to Create Tech Products Customers Love — Marty Cagan, Chapters 11, 64, 65, 66.

---

## Category A — Team Behaviors {#category-a}

Source: Chapter 64 — Good Product Team / Bad Product Team

18 contrasting behaviors. Score 2 (healthy), 1 (partial), or 0 (dysfunction).

| # | Dimension | Healthy (score 2) | Dysfunction (score 0) |
|---|-----------|-------------------|-----------------------|
| A1 | Mission orientation | Teams have a compelling product vision pursued with missionary-like passion | Teams are mercenaries — execute tasks without genuine commitment to outcomes |
| A2 | Idea sourcing | Ideas come from vision, objectives, customer observation, usage data, and new technology | Ideas come from requirements gathered from sales and customers |
| A3 | Stakeholder relationship | Team understands stakeholder constraints and invents solutions that work for users, customers, and the business | Team gathers requirements from stakeholders and treats them as specifications |
| A4 | Idea validation method | Team uses rapid prototyping and experimentation techniques to determine which ideas are worth building | Team holds meetings to generate and prioritize roadmaps |
| A5 | Intellectual openness | Team loves brainstorming with smart thought leaders from across the company | Team is offended when someone outside their group suggests they do something |
| A6 | Collaboration structure | Product, design, and engineering sit side by side and embrace the interplay between functionality, user experience, and technology | Disciplines sit in silos and make requests through documents and scheduled meetings |
| A7 | Testing permission | Team innovates continuously in ways that protect revenue and brand | Team waits for permission before running any test |
| A8 | Design awareness | Team insists on strong product design as a necessary capability for winning products | Team doesn't understand what product designers do or why they matter |
| A9 | Engineer involvement in discovery | Engineers have time to try out prototypes in discovery daily so they can contribute to making the product better | Engineers first see prototypes at sprint planning so they can estimate |
| A10 | Customer engagement | Team engages directly with end users and customers every week to understand them and observe their response to new ideas | Team thinks they are the customer; relies on internal assumptions |
| A11 | Iteration expectation | Team knows favorite ideas often won't work and will need several iterations to produce the desired outcome | Team builds what's on the roadmap, satisfied with meeting dates and ensuring quality |
| A12 | Speed source | Team understands speed comes from the right techniques, not forced labor; rapid iteration is the key to innovation | Team complains it is slow because colleagues aren't working hard enough |
| A13 | Commitment integrity | Team makes high-integrity commitments after evaluating requests and verifying viable solutions that work for customer and business | Team complains about being a sales-driven company; accepts any commitment |
| A14 | Analytics instrumentation | Team instruments their work to immediately understand product usage and adjusts based on data | Team treats analytics and reporting as a nice-to-have |
| A15 | Release cadence | Team integrates and releases continuously; constant stream of smaller releases provides a stable solution | Team tests manually at the end of a painful integration phase, then releases everything at once |
| A16 | Reference customers | Team obsesses over their reference customers | Team obsesses over competitors |
| A17 | Success definition | Team celebrates when they achieve significant impact on business results | Team celebrates when they finally release something |
| A18 | Cross-functional idea sharing | Team actively seeks perspectives from outside the immediate team to strengthen their thinking | Team is closed off, treating outside input as interference |

---

## Category B — Innovation Capacity {#category-b}

Source: Chapter 65 — Top Reasons for Loss of Innovation

10 organizational attributes required for consistent innovation. Score 2 (present), 1 (partial), or 0 (absent).

| # | Attribute | Healthy (score 2) | Dysfunction (score 0) |
|---|-----------|-------------------|-----------------------|
| B1 | Customer-centric culture | Direct and frequent customer contact at team level; team is driven to delight customers | No focus on customers; teams rarely interact with actual users; internal assumptions dominate |
| B2 | Compelling product vision | A clear, current, inspiring vision exists and is understood by all teams; leadership steps up when original vision is realized | Original vision is largely realized; team is struggling to understand what's next; no one has filled the void |
| B3 | Focused product strategy | Strategy spells out a logical, intentional sequence of target markets; teams know what to focus on | Strategy tries to please everyone at once; teams are pulled in too many directions |
| B4 | Strong product managers | Each team has a strong, capable PM who inspires the team and drives clear product thinking | PM role is weak or absent; order-takers rather than product leaders; team operates as mercenaries |
| B5 | Stable product teams | Teams are durable and have had time to learn the space, technology, and customer pain | Team membership is constantly shifting; no institutional knowledge builds up |
| B6 | Engineers in discovery | Engineers are included from the very beginning of ideation and exposed directly to customer pain | Engineers are brought in only at the end, after solutions have been fully specified |
| B7 | Corporate courage | Leadership is willing to risk disruption to current business in the pursuit of innovation | Organization is extremely risk-averse; teams avoid anything that might disrupt existing revenue |
| B8 | Empowered product teams | Teams are given business problems to solve and trusted to determine the best solution | Teams are handed roadmaps of features; empowerment has been revoked as the company scaled |
| B9 | Product mindset | Teams exist to serve the company's customers in ways that meet the needs of the business | IT mindset — teams exist to serve the needs of the internal business; customers are secondary |
| B10 | Time to innovate | Teams have capacity beyond "keep the lights on" activities to pursue harder, more impactful problems | Teams are entirely consumed by bugs, technical debt, and operational requests; no innovation capacity remains |

---

## Category C — Velocity Killers {#category-c}

Source: Chapter 66 — Top Reasons for Loss of Velocity

10 structural and process causes of slowness. Score 2 (not a problem), 1 (partial), or 0 (active problem).

**Release cadence benchmark:** Teams should release no less frequently than every 2 weeks. Great teams release multiple times per day.

| # | Killer | Healthy (score 2) | Dysfunction (score 0) |
|---|--------|-------------------|-----------------------|
| C1 | Technical debt | Architecture facilitates rapid product evolution; debt is actively managed | Architecture does not enable rapid evolution; significant accumulated debt blocks progress |
| C2 | Product manager strength | PM is strong, capable, and inspires the team as missionaries | PM is weak; team operates as mercenaries; no inspiration or evangelism |
| C3 | Delivery management | Delivery manager role exists and actively removes impediments before they compound | No delivery management; impediments accumulate and compound non-linearly |
| C4 | Release cadence | Releases happen at minimum every 2 weeks; great teams release multiple times per day | Releases happen monthly or less; no test or release automation; big-bang releases |
| C5 | Product vision and strategy | Team has a clear vision and understands how immediate work contributes to the big picture | No vision or strategy; team lacks context for why their work matters |
| C6 | Co-located, durable teams | Teams are co-located (or effectively distributed with strong tooling); engineers are not outsourced | Teams are split across locations or engineers are outsourced; communication is costly and slow |
| C7 | Engineer early involvement | Engineers participate in product discovery from the start of ideation, contributing faster implementation alternatives | Engineers are not included until solutions are fully designed; critical input comes too late |
| C8 | Design in discovery | Product design is utilized in discovery; design work is done before engineering begins | Design runs in parallel with or after engineering; design debt and poor outcomes result |
| C9 | Priority stability | Priorities are stable enough that teams can build momentum and complete meaningful work | Priorities shift rapidly; significant churn; throughput and morale suffer |
| C10 | Decision culture | Decisions are made with appropriate authority and clear accountability | Consensus culture; all decisions require group agreement; everything slows to a crawl |

---

## Category D — Design Integration {#category-d}

Source: Chapter 11 — The Product Designer

4 failure modes describing how design is commonly mis-integrated. Score 2 (failure mode absent), 0 (failure mode present).

| # | Failure Mode | Healthy (score 2) | Dysfunction (score 0) |
|---|-------------|-------------------|-----------------------|
| D1 | PM designs without training | A trained product designer owns interaction and visual design on the team | PM produces wireframes despite lacking design training; engineers cobble together visual design from them |
| D2 | PM provides only user stories | A dedicated product designer translates product thinking into interaction and visual design | PM provides only high-level user stories; engineers must work out the design themselves |
| D3 | PM does interaction + separate visual designer | A single product designer handles both interaction and visual design holistically | PM produces interaction design (wireframes); a separate visual/graphic designer provides visual layer; no holistic design ownership |
| D4 | Design as internal agency | Designer is embedded with the product team as a full partner in discovery and delivery | Design operates as an internal agency — the team submits requests, waits for design output; designers are not partners in discovery |

---

## Scoring Summary Template

```
Category A — Team Behaviors:       ___/36 = ___%
Category B — Innovation Capacity:  ___/20 = ___%
Category C — Velocity Killers:     ___/20 = ___%
Category D — Design Integration:   ___/8  = ___%

Composite Score:                   ___/84 = ___%
```

**Severity thresholds:** 80–100% Healthy | 60–79% Caution | 40–59% Degraded | 0–39% Critical

**Automatic Critical red flags (score 0 on any of):** A9, B1, B2, C4, D4


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