Welcome to the Docs Use Case templates! These example templates are designed to help you easily get started in Shortcut Docs. You can also see them all in our cool demo workspace if you would prefer to view and copy them from there.
We are working on building out true templates in Shortcut, in the meantime, you can copy and paste any of these into a Shortcut Doc. The formatting here looks a little off, but when pasted into a Shortcut Doc it looks much better. Click the link to the template you want to try to quickly navigate to that template.
- Product Requirement Doc
- 1:1 Meeting
- ADR (Architecture Decision Record)
- Incident Postmortem
- MVP Ideation
- OKRs
- Project Kickoff
- Sprint/Iteration Planning
- Squad Daily Standup
- Technical Design Doc
Product Requirement Doc
Use this Product Requirements Doc (PRDs) template to define the requirements of a particular product, including the product's purpose, features, functionality, and behavior. Use this as a guide for business and technical teams to help build, launch, or market the product.
Overview
Overview
| Target release | Insert Date |
|---|---|
| Epic | Type '/' to add Epic |
| Document status | DRAFT |
| Document owner | @ mention owner |
| Designer | @ mention designer |
| Tech lead | @ mention lead |
| Technical writers | @ mention writers |
| QA | @ mention QA |
Objective
Outline the customer problem you are solving and how it relates to your vision, goals, and initiatives.
Success metrics
Hypothesis
We believe <this feature> will achieve <this outcome>.
|
Goal |
Metric |
|
eg., Decrease page load times by 25% |
eg., Customer satisfaction score increases |
|
|
|
Assumptions
List any assumptions you have about your users, technical constraints, or business goals.
Product Requirements
|
Requirement |
High-Level User Story |
Story |
Notes |
|
e.g., Load times must remain fast |
e.g., Engineers enjoy using a tool that loads quickly |
Type '/' to add Story |
e.g., Research confirmed last quarter |
Designs
Click + Edit Block to insert an image or paste in other design assets. For teams using Figma paste the link for a design preview.
Open Questions
Add any unanswered questions here.
|
Question |
Next Steps |
Owner |
Due Date |
|
e.g., Will the layout impact load times |
e.g., Meet with design |
'@ mention' owner |
Insert date |
|
|
|
|
|
Scope
Outline what is in and out of scope for the initial launch and what is planned for a later date.
In Scope for <date> launch
- eg., Out of Scope for <date> launch
- eg., Edge Cases
1:1 Meeting
Use this template to take notes for your 1:1 meeting with your manager or teammates. Docs default to being shared with your workspace but you can update to private or share with individual teammates for 1:1 docs.
<Insert Date>
Participants: @ mention attendees
Agenda
- Added agenda items
- Type '/' to insert related Docs, Stories, or Epics
Questions
- Insert questions
- Type '/' to insert related Docs, Stories, or Epics
Action Items
<Insert Date>
Participants: @ mention attendees
Agenda
- Added agenda items
Questions
- Insert questions
Action Items
ADR (Architecture Decision Record)
An Architecture Decision record (ADR) captures an important architectural decision made along with its context and consequences.
Status
State the status, e.g., proposed, accepted, rejected, deprecated, superseded, etc.
Context
This is the context explaining the problem we are looking to resolve and what is motivating this decision or change (technical, goals, project)?
Decision
Summary of the decision or outcome.
Related decisions
List any related decisions here or include a visual such as a traceability matrix or decision tree.
Consequences
Describe what becomes easier or more difficult because of this change.
Proposal
Outline the details of the change that you're proposing.
Other Notes
Because the decision-making process can take weeks, we’ve found it useful to capture notes and issues that the team discusses during the socialization process.
Incident Postmortem
The purpose of a postmortem is to share things we learned from the incident and help us get better. Psychological safety is critical for improvement. We keep postmortems blameless to focus on systems and processes, not human error.
| Postmortem owner | @ mention owner |
|---|---|
| Incident | Brief description of the incident |
| Priority | P0/ P1 / P2 |
| Affected Areas |
Bug Name: Type / to insert bug Story
Video recording: link to visual of the bug
What happened?
Short description of what happened.
Timeline in EST (adjust timezone as needed)
Important items to include in the timeline are:
- How & when was it reported/discovered
- Who was involved, and when
- Any notable events
- When was the incident resolved
Example:
- 3:35 AM- First report in Zendesk (link to ticket) of a user being unable to view the website
- Ultimately 8 Zendesk tickets were connected to this issue
- 7:43 AM - (@ mention name) created bug in Shortcut (Type / to add the link to the Story)
Users affected
Summarize how many users were affected and in what way.
Resolution
Summarize the final resolution.
Contributing Factors
Failure in complex systems are complex and are rarely from a root cause or a linear chain of causes. What factors contributed to the failure? People generally act in a way that seems correct to them based on the info they have ("local rationality"). Why did these actions seem correct at the time? What systems, practices, and information contributed?
Discussion
Describe what you learned, what went well, and how you can improve.
Action Items
Action items are "we really need to do this", not "we could do this" (put those in discussion).
Best practice recommendations for action items:
- Reify as Stories, assigned owners, and have a severity field, and due date.
- Stories are labeled with "postmortem" so they are easily searchable
MVP ideation
Use the MVP (Minimum Viable Product) template document to outline goals, success metrics, key value props, marketing, and release plan of a feature or project.
Problem to solve
Why are you building the MVP? What problem are you trying to solve?
MVP Solution
Describe the solution to the problem above.
Value Props and Messaging
Describe the selling propositions of the MVP.
Value Prop 1
Value Prop 2
Target Market
Name the specific users or personas that are the target market for the MVP.
Competitors/Current State of the Market
What is your target market/group/users using right now for this problem? What is lacking in those solutions?
| Competitor | Problems | Strengths |
|---|---|---|
| Name of your competitor | e.g., Their solution doesn't integrate with key tools | e.g., UX feedback is very positive |
Success Metrics
Outline how you will know if the MVP has been successful and solved the problem outlined.
Primary:
Describe primary success metrics
- ___%
Secondary:
Describe secondary success metrics
Adoption
- ___%
Key Steps and Timelines
| Key Step/Epic | Timeline | Owner |
|---|---|---|
| Type '/' to insert Epic or describe the key step | Add date or general timeline | @ mention owner |
OKRs
Use the OKR template to help your team set and track measurable goals.
| Timeline | Add the timeline for these OKRs |
| Docs | Type '/' to add other key docs |
Objective: e.g., Create the lowest carbon footprint in our industry.
Owner: @ mention owner
Epic: Type / to add an Epic
Key Results 1: e.g., Pay 100% carbon offset for calculated carbon dioxide emissions.
Key Results 2: e.g., Supply chain and shipping infrastructure 99% zero waste.
Objective: e.g., Create the lowest carbon footprint in our industry.
Owner: @ mention owner
Epic: Type / to add an Epic
Key Results 1: e.g., Pay 100% carbon offset for calculated carbon dioxide emissions.
Key Results 2: e.g., Supply chain and shipping infrastructure 99% zero waste.
Objective: e.g., Create the lowest carbon footprint in our industry.
Owner: @ mention owner
Epic: Type / to add an Epic
Key Results 1: e.g., Pay 100% carbon offset for calculated carbon dioxide emissions.
Key Results 2: e.g., Supply chain and shipping infrastructure 99% zero waste.
Project Kickoff
Use the Project kickoff to ensure your team understands the project’s vision, mission, and strategy.
Overview
| Initiative | High level overview |
| Epic | Type '/' to add Epic |
| Date | Add a date |
| Resources | Type '/' to add other relevant Docs |
| Project Owner | @ mention project owner |
| Design Researcher | @ mention Design Researcher |
| Product representation | @ mention Product |
| Design representation | @ mention Design |
| Eng representation | @ mention Eng |
Overview
Project Goals
Project Deliverables
| Deliverable | Date |
| e.g., Phase 1 | 6/1/2022 |
| e.g., Phase 2 | 9/1/2022 |
Open Questions
Sprint/Iteration Planning
Whether your team runs Sprints (or some version of them) use this Sprint/Iteration Planning template to set goals, plan team capacity, and set your team up for success. For the purpose of this template, we are using Sprints and Iterations interchangeably.
General Check-In
- Staffing / organizational announcements
Capacity Check-In
What's your capacity for this Sprint? (0-10 out of 10 days). Include OOO and any other capacity-reducing items.
- % total eng capacity:
n/ <# eng x 10>
| Name | Capacity (0-10) | Notes |
|---|---|---|
| @ mention name | insert capacity | e.g., Out of office on Friday |
Check in on previous goals, create new iteration
- Look at the previous sprint goals. See if you met them or not. Don’t let this discussion last too long, or feel free to address in a retro.
- Create a new Iteration/Sprint. Tip: Create a naming convention to create consistency and make finding past sprints easier.
- Talk about what the most important goals are from a Product Manager perspective. You’re not going to formalize what exactly is going to get done, but we should know after this moment what is most important.
Housekeeping
- Clean up the previous Sprint
- View all Started Iterations/Sprints by going to the Stories board page, then filter by Team & Started Iterations. This will include all previous and current issues.
- Add to Stories to the current Sprint.
Decide on Realistic Goals
Working together, come up with 1-3 sentence long goals that describe what the team will accomplish.
Any blockers / open questions?
Ask the team whether there are any other concerns.
Name the Sprint
Name the Sprint, have fun with it!
Go team! 🎉
Squad Daily Standup
Use this Squad Daily Standup with your team to help your team uncover and coordinate interdependencies, and bring visibility to what you are working on as a team. Standups can be run synchronously during a meeting or asynchronously via a Doc.
Tip: Try filtering the board by each person, Team or Iteration or showing the Status view to make sure everyone is covered.
Meeting Format:
Ask each person to state the high-level points of their updates. Aim to be concise in each of your updates. If the discussion needs to be more than a minute or two, ask the involved folks to regroup after standup or schedule a deeper discussion for later.
What did you accomplish yesterday?
Provide a quick overview of the things you've done since yesterday's meeting
- Add relevant Stories by Typing / to insert
What you are planning to do today?
Provide a quick overview of what's on your agenda to tackle today.
- Add relevant Stories by Typing / to insert
- Call out non-sprint work - interviews, meetings, etc.
What risks there are to getting this done?
- Call out work that needs a ticket that is out of scope of an active ticket to be added to draft for future refinement
- Call out dependencies on other tickets or people needed for progress on active ticket
- Call out the need for pairing for more team support
Technical Design Doc
A Technical Design Document lets an engineering team define, evaluate, and iterate on a solution when it's cheapest: before implementing it. This shares knowledge within the engineering team and can be the basis for future documentation.
Problem
Problem Statement
What is this for? What problem are you addressing?
Goals
What are the goals of the feature? What outcomes will make this a success? How is the code, the system, the product, or THE WORLD 🌎 different?
- Goal 1
Non-Goals
What is not in scope? This helps reviewers focus on the important parts of the solution instead of pointing out areas that were deliberately not addressed.
- Not a goal of this feature
Solution
Solution Summary
A few sentences giving a high-level summary of the solution.
History
Provide relevant background information to give context about why the solution makes sense. Designs are often path-dependent. This is your chance to lay out the path.
Solution Overview
The technical approach to solving the problem. This can include pseudocode and diagrams. This is the longest part of the design doc and requires the most research, planning, and preparation.
Considered Options
Describe the alternatives considered. (This section is optional.)
Pros
Outline the pros of alternatives considered.
Cons
Outline the cons of alternatives considered.
Related
Links to internal process documentation of the decision, e.g. Stories, Epics, Docs, etc.
| Link | Notes |
|---|---|
| Type / to insert Story or Epic or copy and paste other links | Any relevant callouts about link |