What we are trying to achieve with this feature. Which company goals it relates to.

The metric that we will use to measure whether the feature has been successful.

Who needs to be kept up to date on the progress of this feature, or should be giving input on it.

This is the core of this section, detailing why this is important to work on, from both a user and business perspective. It likely links to other strategy documents and existing insights the team has.

Notes on what is in and out of scope, as well as any constraints that the team should bear in mind, such as a limit to the time or investment that can be made, or impact on other teams.

The key risks that the team has identified and is working to reduce.

Plan of record

1. List the features that shape the solution

2. Ideally in priority order

3. Think of this like drawing the perimeter of the solution space

4. Draw the boundaries so the team can focus on how to fill it in

5. Link out to sub-docs for more detail for particularly large projects

6. Challenge the size to see if a smaller component can be shipped independently

Future considerations

1. Optionally list features you are saving for later

2. These might inform how you build now

1. User profiles

2. Detailed user stories

3. Key flows and diagrams showing the states and screens that the user can move between.

4. Ideally these can be embedded Figma / Miro / etc. files that are automatically kept up to date.

Wireframes, mockups and prototypes as they are developed, showing what the feature will look like, and how users will interact with it. Ideally, these are also embedded files or links to the latest designs, and are automatically updated.

Insights from user testing and key stakeholders on how well the solution solves the problem.

Quantitative insights that guide the development of this feature

Screenshots from competitors and other products that are useful references for the development of this feature

Details of the tracking in place, and dashboards or reports that are needed to assess the performance of the solution.

The details of how the solution will be marketed to users. It's useful here to think through the message and channels for different user groups, as well as who is responsible for pulling together and triggering these comms.

This might be a simple to-do noting whether or not the customer service team has been briefed (e.g. a workshop or team meeting), and could include the materials they will need to support the solution once it is live.

This should ensure that any legal implications of launching (e.g. updating T&Cs, partner contracts) are dealt with before the feature goes live.

It's useful to answer anticipated questions from both internal stakeholders and external users ahead of the feature going live. In some situations, this might include updating your public FAQs or support documents.

How much the release moved its success metrics. How much it contributed to the team's objective.

Any insights we can see in terms of how much users engaged with this feature, or other behaviour. Whether there are any second order effects to the release.

What feedback we saw from users both direct to customer service, and indirectly via forums, social media and so on.

Any follow-up actions arising from the release. Whether AB tests will be rolled out or rolled back. Further phases of developing this solution.