Docs Use Case Templates


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 

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.



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


Outline the customer problem you are solving and how it relates to your vision, goals, and initiatives.

Success metrics


We believe <this feature> will achieve <this outcome>.



eg., Decrease page load times by 25%

eg., Customer satisfaction score increases




List any assumptions you have about your users, technical constraints, or business goals.

Product Requirements


High-Level User Story



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


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.


Next Steps


Due Date

e.g., Will the layout impact load times

e.g., Meet with design

'@ mention' owner

Insert date






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 


  • Added agenda items
  • Type '/' to insert related Docs, Stories, or Epics



  • Insert questions
  • Type '/' to insert related Docs, Stories, or Epics


Action Items


<Insert Date>

Participants: @ mention attendees 


  • Added agenda items



  • 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.


State the status, e.g., proposed, accepted, rejected, deprecated, superseded, etc.


This is the context explaining the problem we are looking to resolve and what is motivating this decision or change (technical, goals, project)?


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.


Describe what becomes easier or more difficult because of this change.


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:

  1. How & when was it reported/discovered
  2. Who was involved, and when
  3. Any notable events
  4. When was the incident resolved


  •  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.


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?


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.



Describe primary success metrics

  • ___%



Describe secondary success metrics


  • ___% 

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



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.


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



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.


  • 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?

  1. Call out work that needs a ticket that is out of scope of an active ticket to be added to draft for future refinement
  2. Call out dependencies on other tickets or people needed for progress on active ticket
  3. 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 Statement

What is this for? What problem are you addressing?


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


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 Summary

A few sentences giving a high-level summary of the solution.


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.)


Outline the pros of alternatives considered.


Outline the cons of alternatives considered.



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