⭐️⭐️⭐️⭐️
Hustle Badger
Problem Definition
Objective
What we are trying to achieve with this feature. Which company goals it relates to.
Success metric
The metric that we will use to measure whether the feature has been successful.
Stakeholders
Who needs to be kept up to date on the progress of this feature, or should be giving input on it.
Responsible | The people doing the work. Usually the team |
Accountable | The person ultimately responsible for the work. Usually the PM |
Consulted | Stakeholders that should have input into the feature. i.e. two-way dialogue |
Informed | Stakeholders that should be kept up to date, but who don’t need input into the feature. i.e. one-way dialogue |
Context
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.
Scope & Constraints
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.
Risks
The key risks that the team has identified and is working to reduce.
Solution Definition
User flows
Diagrams showing the states and screens that the user can move between. Ideally these can be embedded Figma / Miro / etc. files that are automatically kept up to date.
Designs
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 automatically updated.
User Research
Insights from user testing and key stakeholders on how well the solution solves the problem.
Analysis
Quantitative insights that guide the development of this feature
Competitor references
Screen shots from competitors and other products that are useful references for the development of this feature
Decision log
Question | Decision made | Decider | Date |
What is the question or alternatives we need to decide between | What was the decision made, and why | Who made this decision | When was this decision made |
Launch Readiness
Testing plan
Details of how you are planning to test the solution. This might include stages such as an internal release, external beta, staged roll-out or AB testing.
Tracking & analytics
Details of the tracking in place, and dashboards or reports that are needed to assess the performance of the solution.
Marketing plan
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.
Customer service plan
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.
Legal checks
This should ensure that any legal implications of launching (e.g. updating T&Cs, partner contracts) are dealt with before the feature goes live.
FAQs
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.
Timeline
This should give an overview of upcoming dates and milestones, and confirmation of where the team is in roll out, especially if things have been delayed.
Impact
Success
How much the release moved its success metrics. How much it contributed to the team's objective.
Quantitative analysis
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.
Qualitative analysis
What feedback we saw from users both direct to customer service, and indirectly via forums, social media and so on.
Next steps
Any follow up actions arising from the release. Whether AB tests will be rolled out or rolled back. Further phases of developing this solution.