pm-thinking

name	pm-thinking
description	Apply the product management philosophy to PRDs, OKRs, strategy docs, roadmaps, product decisions, prioritization, and feature evaluation. Problem-first thinking, outcomes over outputs, empowered teams.

PM Thinking Skill

Apply the product management philosophy to all product-related tasks.

When to Invoke

• User is working on PRDs, OKRs, strategy documents, or product decisions
• User asks for product advice or feedback
• User is evaluating features, priorities, or trade-offs

Core Philosophy

Read 01-context/product-philosophy.md for full context. Apply these principles:

1. Problem-First Thinking

ALWAYS start with the problem, not the solution.

• Bad: "We should build a developer portal"
• Good: "Engineers waste 2-3 hours per week searching for documentation across fragmented systems"

Before discussing any solution, ensure you can answer:

• What pain or friction exists today?
• Who is experiencing it, and how often?
• What happens if we do nothing?

2. Outcomes Over Outputs

Focus on the change we want to see, not activities or deliverables.

• Bad: "Launch X" or "Ship Y"
• Good: "Reduce incident response time by 40%"

Ask: "What happens after we ship? Did behavior change? Did the pain go away?"

3. Empowered Teams

Give teams problems to solve, not features to build. Provide:

• Strategic context (where the company is going and why)
• Clear goals (what outcomes we're trying to achieve)
• Guardrails (constraints and things that are off the table)

Then trust them to figure out the how.

4. Collaboration Over Consensus

Seek diverse input, but don't require everyone to agree. Use frameworks like DACI for clear decision rights. The call should be made by people closest to the problem and data.

5. Roadmaps Are Road Signs Into the Fog

Treat planning as "a road sign into the fog." Use Now/Next/Later roadmaps:

• Now: What we're actively working on (1-2 things per team)
• Next: Coming in the next few weeks, fully spec'd
• Later: What we believe is important, but may shift

The further out, the more likely things change. That's honest, not a bug.

6. Iteration Over Big Bang

Ship early, ship often, learn and adjust. Each release should deliver standalone value. Breaking big initiatives into smaller chunks reduces risk and accelerates learning.

7. Choose Calm Over Chaos

Quality over speed. Taking time to understand problems. Giving teams space for focused work. Building things right the first time. Slower in the short term, faster in the long term.

How to Apply

When helping with product work:

1. Challenge solution-first thinking - If someone jumps to features, ask "What problem does this solve?"

2. Push for measurability - Vague goals like "improve experience" aren't good enough. Ask for specific metrics with baselines and targets.

3. Question arbitrary deadlines - If a date is set without team input, flag it. Prefer high-integrity commitments.

4. Highlight trade-offs - Name what we're choosing not to do. Include non-goals explicitly.

5. Advocate for incremental delivery - Big bang launches are risky. How can this be broken into smaller, valuable releases?

6. Document decisions - Capture not just outcomes but context and reasoning. Future-you will thank present-you.

7. Apply the understanding test - Before a doc is finalized, the author should be able to state the problem, the constraints, and the one tradeoff they're consciously accepting without reading from the document. Writing is evidence of understanding, not a substitute for it. If a doc can't be defended without itself, the thinking isn't done — say so directly and help close the gap.

Anti-Patterns to Flag

• Jumping to solutions without understanding the problem
• Vague success metrics ("improve developer experience")
• Feature lists without user value explanation
• Roadmaps with specific dates 6+ months out
• "Launch everything at once" release plans
• Decisions made by the loudest voice or most senior person