What This Template Is For
Undocumented processes live in people's heads. When that person goes on vacation, changes teams, or leaves the company, the process goes with them. The rest of the team either reinvents the process from scratch or operates without one. Neither outcome is good.
Process documentation captures how recurring work gets done so that any team member can follow the same steps and achieve the same result. This is not about bureaucracy. It is about reliability. A documented process can be reviewed, improved, automated, and taught to new team members. An undocumented process can only be repeated by the person who invented it.
This template provides a standardized format for documenting any product management process. Each process document covers the purpose, trigger, steps, roles, exceptions, metrics, and review cadence. It is designed to be stored in a team wiki (Notion, Confluence, or similar) and referenced as a living document.
For teams building their full operations playbook, the Product Operations Handbook covers the broader discipline. The Product Ops Playbook Template collects multiple process documents into a single operational reference. For understanding role ownership within processes, the RACI Matrix Template provides the responsibility assignment framework.
How to Use This Template
- Identify the process to document. Start with the process that causes the most confusion or inconsistency.
- Interview 2-3 people who currently perform the process. Document what they actually do, not what they think they should do.
- Fill in every section. Skip nothing. The sections you are tempted to skip ("Exceptions" and "What happens when it fails?") are the ones new team members need most.
- Have someone who does not know the process follow the documentation. If they get stuck, the documentation is incomplete.
- Publish to the team wiki. Link it from your playbook and onboarding materials.
- Set a review date. Processes change. Documentation that is 6 months stale is worse than no documentation.
The Template
Process Overview
| Field | Details |
|---|---|
| Process name | [Clear, descriptive name] |
| Process ID | [Optional: PROC-001, for tracking] |
| Purpose | [Why this process exists. What problem does it solve?] |
| Scope | [What is included and excluded from this process] |
| Owner | [Name and role of the person responsible for maintaining this process] |
| Created | [Date] |
| Last reviewed | [Date] |
| Next review | [Date] |
| Version | [X.X] |
Trigger
What initiates this process?
| Field | Details |
|---|---|
| Trigger event | [e.g., "A new feature request is submitted via the intake form"] |
| Trigger source | [e.g., "Support team, Sales team, or internal PM request"] |
| Frequency | [How often this trigger occurs: daily, weekly, per sprint, on-demand] |
| SLA | [Time within which the process must be completed after triggering: e.g., "Triage within 3 business days"] |
Inputs and Outputs
| Inputs (what you need to start) | Outputs (what the process produces) |
|---|---|
| [e.g., Feature request form with: title, description, requester, urgency] | [e.g., Triaged backlog item with: priority score, assigned PM, status update to requester] |
| [Input 2] | [Output 2] |
| [Input 3] | [Output 3] |
Process Steps
Document each step in sequence. Include enough detail that someone new to the team can follow them.
| Step | Action | Owner | Tool | Time Estimate | Notes |
|---|---|---|---|---|---|
| 1 | [e.g., Review the new request in the intake queue] | [Role] | [Tool name] | [X min] | [Any clarifications] |
| 2 | [e.g., Check for duplicates in the backlog] | [Role] | [Tool name] | [X min] | [Search criteria to use] |
| 3 | [e.g., Score the request using the prioritization framework] | [Role] | [Tool name] | [X min] | [Link to scoring rubric] |
| 4 | [e.g., Assign to the appropriate PM based on product area] | [Role] | [Tool name] | [X min] | [Product area ownership list] |
| 5 | [e.g., Send acknowledgment to the requester with expected timeline] | [Role] | [Tool name] | [X min] | [Email/Slack template link] |
| 6 | [e.g., Add to sprint planning queue if priority >= P1] | [Role] | [Tool name] | [X min] | [Priority threshold for sprint inclusion] |
RACI Matrix
Define who is Responsible, Accountable, Consulted, and Informed at each step.
| Step | Responsible (does the work) | Accountable (final decision) | Consulted (provides input) | Informed (needs to know) |
|---|---|---|---|---|
| 1. [Step name] | [Role] | [Role] | [Role(s)] | [Role(s)] |
| 2. [Step name] | [Role] | [Role] | [Role(s)] | [Role(s)] |
| 3. [Step name] | [Role] | [Role] | [Role(s)] | [Role(s)] |
| 4. [Step name] | [Role] | [Role] | [Role(s)] | [Role(s)] |
Decision Points
Document where decisions are made within the process and what criteria are used.
| Decision Point | Question | Criteria | If Yes | If No |
|---|---|---|---|---|
| [e.g., Step 2: Duplicate check] | Is there an existing backlog item for this request? | [Matching title, similar description, same product area] | Merge with existing item. Update requester. End process. | Continue to Step 3. |
| [e.g., Step 3: Priority scoring] | Does the request score >= P1? | [RICE score > X, or enterprise customer with > $50K ARR] | Add to sprint planning queue. | Add to backlog. Inform requester of quarterly review timeline. |
| [Decision point] | [Question] | [Criteria] | [If Yes] | [If No] |
Exceptions and Edge Cases
Document what happens when the process does not follow the standard path.
| Exception | When It Occurs | Handling | Escalation |
|---|---|---|---|
| [e.g., Urgent security request] | [Customer reports a security vulnerability] | [Skip scoring. Route directly to engineering lead. Follow incident response process.] | [PM Lead + Engineering Lead within 1 hour] |
| [e.g., Request from executive] | [CEO or CXO submits a feature request directly] | [Route to VP Product for triage. Follow standard scoring but flag as "executive request" for visibility.] | [VP Product within 24 hours] |
| [e.g., Request with missing information] | [Required fields are blank or unclear] | [Reply to requester within 24 hours requesting clarification. Pause process until response.] | [If no response in 5 days, close with "Insufficient information" status] |
Metrics
How do you measure whether this process is working?
| Metric | Definition | Target | Current | How Measured |
|---|---|---|---|---|
| [e.g., Triage time] | [Time from request submission to triage decision] | [< 3 business days] | [X days] | [Timestamps in tracker] |
| [e.g., Requester satisfaction] | [% of requesters who rate the process 4+ out of 5] | [> 80%] | [X%] | [Follow-up survey] |
| [e.g., Duplicate rate] | [% of requests that are duplicates of existing items] | [< 15%] | [X%] | [Duplicate tag count / total requests] |
| [Metric name] | [Definition] | [Target] | [Current] | [Measurement method] |
Review and Maintenance
| Field | Details |
|---|---|
| Review cadence | [Quarterly / Semi-annually] |
| Review owner | [Name and role] |
| Review checklist |
- ☐ Are all steps still accurate? (Walk through the process end-to-end)
- ☐ Has the team structure changed? (Update RACI if roles changed)
- ☐ Have tools changed? (Update tool references)
- ☐ Are metrics being tracked? (Review metric values)
- ☐ Are exceptions still valid? (Add new edge cases encountered since last review)
- ☐ Is this process still necessary? (Eliminate or merge if redundant)
Change log.
| Date | Version | Change | Author |
|---|---|---|---|
| [Date] | 1.0 | Initial documentation | [Name] |
| [Date] | 1.1 | [Description of change] | [Name] |
Filled Example: Feature Request Triage Process
Process Overview (Filled)
| Field | Details |
|---|---|
| Process name | Feature Request Triage |
| Process ID | PROC-003 |
| Purpose | Ensure every feature request is evaluated, prioritized, and either accepted into the backlog or rejected with a reason, within 3 business days. |
| Scope | Covers requests from support, sales, CAB, and internal teams. Excludes bug reports (separate process) and security issues (incident response). |
| Owner | Kira Tanaka, Product Ops Lead |
| Last reviewed | March 1, 2026 |
| Next review | June 1, 2026 |
Process Steps (Filled)
| Step | Action | Owner | Tool | Time |
|---|---|---|---|---|
| 1 | Review new requests in the intake queue (filtered by "unprocessed" status) | Product Ops | Productboard | 5 min/request |
| 2 | Check for duplicates by searching existing backlog items | Product Ops | Productboard | 2 min |
| 3 | Enrich with customer context: ARR, plan tier, company size, past requests | Product Ops | HubSpot + Productboard | 3 min |
| 4 | Score using RICE framework: Reach, Impact, Confidence, Effort | Assigned PM | Productboard | 10 min |
| 5 | Decision: Accept (add to backlog), Reject (with written reason), or Defer (revisit next quarter) | Assigned PM | Productboard | 5 min |
| 6 | Notify requester of decision via automated email template | Product Ops (automated) | Productboard + Email | 1 min |
Total time per request: 26 minutes average.
RACI (Filled)
| Step | R | A | C | I |
|---|---|---|---|---|
| 1. Review queue | Product Ops | Product Ops Lead | - | - |
| 2. Duplicate check | Product Ops | Product Ops Lead | - | - |
| 3. Enrich context | Product Ops | Product Ops Lead | Sales (if deal-related) | - |
| 4. RICE scoring | Assigned PM | PM Lead | Engineering Lead (for Effort) | - |
| 5. Decision | Assigned PM | PM Lead | - | VP Product (P0 items only) |
| 6. Notify requester | Automated | Product Ops | - | Requester, Sales rep |
Metrics (Filled)
| Metric | Target | Current (Feb 2026) |
|---|---|---|
| Triage time | < 3 business days | 2.1 days |
| Requester satisfaction | > 80% | 84% |
| Duplicate rate | < 15% | 11% |
| Requests processed per week | All submitted | 28 avg (100% processed) |
Common Mistakes to Avoid
- Documenting the ideal process instead of the real one. Start by documenting what actually happens today, including the messy parts. Then improve it. If you document an aspirational process, nobody will follow it because it does not match reality.
- Writing steps that are too vague. "Triage the request" is not a step. "Open the Productboard inbox, filter by 'unprocessed', read the request title and description, check for duplicates by searching the backlog" is a step. Write for someone who has never done this before.
- Forgetting to document exceptions. Exceptions are where processes break. New team members encounter an edge case, do not know how to handle it, and either make a bad decision or stall. Document every exception your team has encountered.
- Treating documentation as a one-time task. Processes evolve. Tools change. Team members rotate. If the documentation is not reviewed quarterly, it drifts from reality. A stale process document is actively harmful because people trust it and follow outdated steps.
Key Takeaways
- Document what actually happens, not what should happen. Improve from there.
- Every process needs a trigger, clear steps, RACI, exceptions, and metrics
- Write for someone who has never performed the process before
- Review quarterly. Stale documentation is worse than no documentation.
- Store process docs where the team already works, not in a separate system
About This Template
Created by: Tim Adair
Last Updated: 3/5/2026
Version: 1.0.0
License: Free for personal and commercial use