Understand It Brief [Template]

Problem/Opportunity

A short description of the problem/opportunity

Who are we hoping to benefit?

Define who is the main user(s) you are hoping to benefit.
E.g. New users, Kids (3—8), Account sharers, CS advisors

What outcomes?
A top-level description of how users will feel and what they will do if that problem/opportunity is addressed.

Why do we believe this will help them?

The hypothesis of what will be the outcome when the problem/opportunity is addressed. When data is not
available it is OK to state an assumption.
E.g. We believe that [doing this/building this feature/creating this experience] for [these people/personas] will
achieve [these outcomes]. We will know this is true when we see [this market feedback, quantitative measure,
or qualitative insight].

Business case
Short description of how this feature will impact the business.
Link to business case if necessary
How do we know we are successful?

Define how you are going to measure success for the hypothesis/problem/opportunity. This should be a
combination of qualitative and/or quantitative goals. Think about what you are going to be able to measure at
different stages of the process.
E.g.
• Quant: Increase in target metric by X%
• Qual: Users can confidently perform a task

Stakeholders
Define the core team and stakeholders that should be involved in the process. Stakeholders: People who have
an active interest in the result of the project.
E.g. @teammember1 — Editorial Team, @teammember2 — Content team

Dependencies
Issues that block you from moving forward with the work.

Problem size / Next steps

Agree on the complexity of the problem and size the ‘Think it’ phase.
E.g. Low complexity, Tweak it or medium complexity, design sketches, user tests or high complexity, design
sprint/more research