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.

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:

  1. How & when was it reported/discovered
  2. Who was involved, and when
  3. Any notable events
  4. 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?

  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

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