# [Project Template]

[one-line description]

Team: [Awesome]
Contributors: [PM], [Designer], [Engineer], [Analyst]
Resources: [Designs], [Analytics], [Notes]
Status: **Draft** / Problem Review / Solution Review / Launch Review / Launched
Last Updated: Thursday, May 21, 2020
* * *

## Problem alignment

>Describe the problem we are trying to solve in 1-2 sentences. I should be able to read this alone and communicate the value/risks to someone else.
- Why does this matter to our customers and business?
- What evidence or insights do you have to support this?

### High Level Approach

>Describe the rough shape of how we might tackle the problem. I should be able to squint my eyes and see the same shape. For example, if the problem was “discoverability of new features”, then this might be “a notification center for relevant features”.

### Narrative

>**Optional**: Share (hypothetical) stories to paint a picture of what life looks like for customers today. Describe common and edgy use cases to consider when designing the solution.

### Goals

1. *Describe high-level goals, ideally in priority order and not too many.*
2. *Include measurable (metrics) and immeasurable (feelings) goals*
3. *Keep it short and sweet*

### Non-goals

1. *List explicit areas we do not plan to address*
2. *Explain why they are not goals*
3. *These are as important and clarifying as the goals*

## Solution Alignment

### Key Features

Plan of record

1. *List the features that shape the solution*
2. *Ideally in priority order*

Future considerations

1. *Optionally list features you are saving for later*
2. *These might inform how you build now*

### Key Flows

>Show what the end-to-end experience will be for customers. This could be written prose, a flow diagram, screenshots, or design explorations. It will vary by project and team. Do not try to do this in isolation. Work with design and engineering to complete.

>It is natural for this section to become more specific over time. It might start as a few annotated screenshots or stories. It might become highly detailed requirements with acceptance criteria. Adjust to the way your team operates. If you have a strong designer who enjoys going into every edge case, lean on them. If you have detailed engineers who prefer to have each scenario documented, go deep on acceptance criteria.

>This will naturally change over time — that’s okay. When changes occur, document them in the [_Changelog_](https://docs.google.com/document/d/12ur-u8Px3E9OWKi-L3x6PYRFd7cKTnsV9no5NU6zS28/edit#heading=h.n2tmu89lqb7n) and notify all contributors.

### Key Logic

1. *List rules to guide design and development*
2. *Address common scenarios and edge cases*
3. *It is often easier to write these out than rely on design to show every permutation*

### Launch Plan

>Define the various phases that will get this product to market, the purpose of each phase, and the criteria you must meet to move on to the next one. Highlight risks and dependencies that can throw a wrench in timelines or progress (and ideally contingency plans). There is a table of example phases below.

### Key Milestones

| **TARGET DATE** | **MILESTONE** | **DESCRIPTION** |
|--- |--- |--- |
| YYYY-MM-DD | Ready | Designs complete, ready for engineering |
| YYYY-MM-DD | PoC | Proof of concept review |
| YYYY-MM-DD | QA/Testing | v0.1.0 release candidate |
| YYYY-MM-DD | Launch | v0.1.0 release |

## Appendix

### Open Questions

*Track open questions and answers here. *