Templates
Free PM Templates
Copy these directly. Each template includes the structure, the rationale for that structure, and the most common mistake people make when using it. No sign-up required.
One-Page PRD
A product requirements doc short enough that engineers actually read it. Covers the problem, the user, the scope, and the success metric. Everything on one page.
Best for
Features, bugs with ambiguous scope, or any spec that needs to get engineering buy-in before work starts
Template structure
Problem statement
What problem are we solving? For whom? Why does it matter?
User story
As a [user type], I want to [action] so that [outcome].
Scope (in)
What is explicitly included in this release? List each specific item.
Scope (out)
What are we explicitly not building? This prevents scope creep.
Success metric
What measurable outcome tells us this worked? One metric, specific target.
Open questions
What do we still need to resolve before work starts? Who owns each?
The most important thing
If your PRD is longer than one page, you have not finished thinking about the problem. Cut, not expand.
User Interview Guide
The questions that produce insight, the order that does not prime the interviewee, and the phrases you should never say. Built on the Mom Test approach.
Best for
Discovery conversations with potential customers, churned users, or anyone you are trying to understand
Template structure
Warm-up (5 min)
Tell me about your role. What does a typical day look like for you? Walk me through the last time you dealt with [problem area].
Context (10 min)
When did you last run into [problem]? What were you trying to accomplish? What did you try first? What happened next?
Pain (10 min)
What was the most frustrating part of that? How often does this happen? What have you done to work around it?
Behavior (10 min)
What tools or processes do you currently use? Why those? What would a 10x better version of this look like?
Wrap-up (5 min)
Is there anything I have not asked that you think is important? Who else should I talk to about this?
The most important thing
Do not mention your product until they ask. If they ask, say you are still in research mode. Every minute they spend talking about your solution is a minute they are not giving you signal.
Prioritization Matrix
A lightweight spreadsheet structure for RICE scoring your backlog. Columns for Reach, Impact, Confidence, and Effort — auto-calculated score, sortable by priority.
Best for
Sprint planning, roadmap reviews, or any conversation where you need to defend why one thing is more important than another
Template structure
Item name
The feature, bug, or initiative name.
Reach (R)
Number of users affected per quarter. Use data, not estimates.
Impact (I)
Rate 0.25 / 0.5 / 1 / 2 / 3. Require a reason for anything above 1.
Confidence (C)
Percentage: 100%, 80%, 50%. Below 50% means more research first.
Effort (E)
Person-weeks. Include design + engineering + QA.
RICE score
Calculated: (R × I × C) / E. Sort descending. Highest goes to top of backlog.
The most important thing
Run RICE as a team exercise, not alone. The value is in the conversation about why reach is 500 vs 5000, not in the final number.
Sprint Retrospective Template
A 45-minute retro structure that surfaces real problems instead of generating a list of action items no one follows up on.
Best for
End of each sprint or milestone, especially when the team feels like something is not working but cannot name it
Template structure
What went well (10 min)
Each person shares one thing. No discussion yet. Just list.
What did not go well (10 min)
Each person shares one thing. Focus on systems and processes, not people.
Root cause (15 min)
Pick the top issue from 'what did not go well.' Apply five whys as a group.
One action item (10 min)
Agree on one specific change to make in the next sprint. Assign an owner. Set a follow-up date.
The most important thing
One action item is better than ten. Ten action items with no owner become zero action items within a week. One action item with an owner has a chance.
Roadmap Slide Template
A one-slide roadmap structure for communicating product direction to founders, investors, or a board. Time-based, outcome-focused, not a feature list.
Best for
Board updates, fundraising conversations, or any time you need to show product direction without getting buried in feature-level details
Template structure
Now (0-60 days)
What is actively being built? One to three items. Include current status.
Next (60-180 days)
What comes after the current sprint? Still concrete enough to be credible.
Later (180+ days)
Direction, not commitments. This is allowed to change as you learn.
North Star
Display the single metric this roadmap is designed to move. Grounds everything else.
The most important thing
A roadmap that shows every feature the team has discussed is not a roadmap. It is a backlog dump. The value of a roadmap is the things that did not make it.
Community
Have a template or process worth sharing?
The best templates come from real experience, not textbooks. Expert Perspectives is where practitioners share original process thinking with other builders. Contributions are open.