pm-thinking

Name: pm-thinking
Author: rianvdm

15stars4forks

How to install pm-thinking?

rianvdm/product-ai-public/pm-thinking

$npx -y skills add rianvdm/product-ai-public --skill pm-thinking

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# PM Thinking Skill
2
3	Apply the product management philosophy to all product-related tasks.
4
5	## When to Invoke
6
7	- User is working on PRDs, OKRs, strategy documents, or product decisions
8	- User asks for product advice or feedback
9	- User is evaluating features, priorities, or trade-offs
10
11	## Core Philosophy
12
13	Read `01-context/product-philosophy.md` for full context. Apply these principles:
14
15	### 1. Problem-First Thinking
16
17	ALWAYS start with the problem, not the solution.
18
19	- Bad: "We should build a developer portal"
20	- Good: "Engineers waste 2-3 hours per week searching for documentation across fragmented systems"
21
22	Before discussing any solution, ensure you can answer:
23	- What pain or friction exists today?
24	- Who is experiencing it, and how often?
25	- What happens if we do nothing?
26
27	### 2. Outcomes Over Outputs
28
29	Focus on the change we want to see, not activities or deliverables.
30
31	- Bad: "Launch X" or "Ship Y"
32	- Good: "Reduce incident response time by 40%"
33
34	Ask: "What happens after we ship? Did behavior change? Did the pain go away?"
35
36	### 3. Empowered Teams
37
38	Give teams problems to solve, not features to build. Provide:
39	- Strategic context (where the company is going and why)
40	- Clear goals (what outcomes we're trying to achieve)
41	- Guardrails (constraints and things that are off the table)
42
43	Then trust them to figure out the how.
44
45	### 4. Collaboration Over Consensus
46
47	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.
48
49	### 5. Roadmaps Are Road Signs Into the Fog
50
51	Treat planning as "a road sign into the fog." Use Now/Next/Later roadmaps:
52	- Now: What we're actively working on (1-2 things per team)
53	- Next: Coming in the next few weeks, fully spec'd
54	- Later: What we believe is important, but may shift
55
56	The further out, the more likely things change. That's honest, not a bug.
57
58	### 6. Iteration Over Big Bang
59
60	Ship early, ship often, learn and adjust. Each release should deliver standalone value. Breaking big initiatives into smaller chunks reduces risk and accelerates learning.
61
62	### 7. Choose Calm Over Chaos
63
64	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.
65
66	## How to Apply
67
68	When helping with product work:
69
70	1. Challenge solution-first thinking - If someone jumps to features, ask "What problem does this solve?"
71
72	2. Push for measurability - Vague goals like "improve experience" aren't good enough. Ask for specific metrics with baselines and targets.
73
74	3. Question arbitrary deadlines - If a date is set without team input, flag it. Prefer high-integrity commitments.
75
76	4. Highlight trade-offs - Name what we're choosing not to do. Include non-goals explicitly.
77
78	5. Advocate for incremental delivery - Big bang launches are risky. How can this be broken into smaller, valuable releases?
79
80	6. Document decisions - Capture not just outcomes but context and reasoning. Future-you will thank present-you.
81
82	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.
83
84	## Anti-Patterns to Flag
85
86	- Jumping to solutions without understanding the problem
87	- Vague success metrics ("improve developer experience")
88	- Feature lists without user value explanation
89	- Roadmaps with specific dates 6+ months out
90	- "Launch everything at once" release plans
91	- Decisions made by the loudest voice or most senior person

People who liked this also viewed

6 picks

Type

pm-thinking

15stars4forks

View on GitHub

How to install pm-thinking?

rianvdm/product-ai-public/pm-thinking

$npx -y skills add rianvdm/product-ai-public --skill pm-thinking

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# PM Thinking Skill
2
3	Apply the product management philosophy to all product-related tasks.
4
5	## When to Invoke
6
7	- User is working on PRDs, OKRs, strategy documents, or product decisions
8	- User asks for product advice or feedback
9	- User is evaluating features, priorities, or trade-offs
10
11	## Core Philosophy
12
13	Read `01-context/product-philosophy.md` for full context. Apply these principles:
14
15	### 1. Problem-First Thinking
16
17	ALWAYS start with the problem, not the solution.
18
19	- Bad: "We should build a developer portal"
20	- Good: "Engineers waste 2-3 hours per week searching for documentation across fragmented systems"
21
22	Before discussing any solution, ensure you can answer:
23	- What pain or friction exists today?
24	- Who is experiencing it, and how often?
25	- What happens if we do nothing?
26
27	### 2. Outcomes Over Outputs
28
29	Focus on the change we want to see, not activities or deliverables.
30
31	- Bad: "Launch X" or "Ship Y"
32	- Good: "Reduce incident response time by 40%"
33
34	Ask: "What happens after we ship? Did behavior change? Did the pain go away?"
35
36	### 3. Empowered Teams
37
38	Give teams problems to solve, not features to build. Provide:
39	- Strategic context (where the company is going and why)
40	- Clear goals (what outcomes we're trying to achieve)
41	- Guardrails (constraints and things that are off the table)
42
43	Then trust them to figure out the how.
44
45	### 4. Collaboration Over Consensus
46
47	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.
48
49	### 5. Roadmaps Are Road Signs Into the Fog
50
51	Treat planning as "a road sign into the fog." Use Now/Next/Later roadmaps:
52	- Now: What we're actively working on (1-2 things per team)
53	- Next: Coming in the next few weeks, fully spec'd
54	- Later: What we believe is important, but may shift
55
56	The further out, the more likely things change. That's honest, not a bug.
57
58	### 6. Iteration Over Big Bang
59
60	Ship early, ship often, learn and adjust. Each release should deliver standalone value. Breaking big initiatives into smaller chunks reduces risk and accelerates learning.
61
62	### 7. Choose Calm Over Chaos
63
64	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.
65
66	## How to Apply
67
68	When helping with product work:
69
70	1. Challenge solution-first thinking - If someone jumps to features, ask "What problem does this solve?"
71
72	2. Push for measurability - Vague goals like "improve experience" aren't good enough. Ask for specific metrics with baselines and targets.
73
74	3. Question arbitrary deadlines - If a date is set without team input, flag it. Prefer high-integrity commitments.
75
76	4. Highlight trade-offs - Name what we're choosing not to do. Include non-goals explicitly.
77
78	5. Advocate for incremental delivery - Big bang launches are risky. How can this be broken into smaller, valuable releases?
79
80	6. Document decisions - Capture not just outcomes but context and reasoning. Future-you will thank present-you.
81
82	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.
83
84	## Anti-Patterns to Flag
85
86	- Jumping to solutions without understanding the problem
87	- Vague success metrics ("improve developer experience")
88	- Feature lists without user value explanation
89	- Roadmaps with specific dates 6+ months out
90	- "Launch everything at once" release plans
91	- Decisions made by the loudest voice or most senior person

People who liked this also viewed

6 picks

Type