This should be completed prior to project kickoff and aligned cross-functionally. The kickoff process will be used to further discuss and improve problem alignment.
Problem overview
Describe the problem (or opportunity) you’re trying to solve.
- Why does this matter to our customers and business?
- What business needs, research, or customer feedback, if any, led to this project?
- Do any previous projects relate to this one and, if so, how did they go and what did your team learn?
High Level Approach
Describe briefly how the team might solve the problem. This should be enough for the reader to imagine possible solution directions and get a rough sense of the scope of this project. For example, if the problem was “discoverability of new features”, then this might be “a notification center for relevant features”.
Goals and success
Describe high-level goals, ideally in priority order and not too many. Include measurable (metrics) and immeasurable (feelings) goals. Keep it short and sweet.
Deliverables and constraints
A list of deliverables that will need to be handed off to engineering. What constraints, if any, exist that the team should be aware of prior to beginning work on the project. This could include Figma files, prototypes, animations, illustrations.
Target audience
Describe the target audience or persona that is critical for project success. Are there any insights into relevant audience demographics in order to produce the best work possible? Define your target audience early can also prevent scope creep.
Project timeline
A project timeline is the best way to give a team a clear idea of key dates and important project milestones. The timeline should include:
- Kickoff
- Wireframe review (if necessary per t-shirt sizing)
- Product review (Med → Large projects)
- Design review
- Handoff
- QA
- Launch
Additional resources and stakeholders
Link any relevant documentation that your team might need to access. As well, include any stakeholders from other squads that need to be included in the project. Consider whether these stakeholders should be at the project kickoff as well.
Please bring to Product Review prior to proceeding for all medium or large-sized projects.
Problem Alignment Approval
List any Shipping Dept member who needs to approve the Problem Alignment. This could be a manager, cross-team PM, or exec. Each person will check their name off once they have approved.
Solution Alignment
Key Features
Give an overview of what we’re building. Provide an organized list of features, with priorities if relevant. Discuss what you’re not building (or saving for a future release) if relevant.
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. This will become more specific over time. Embed the Figma file here, not just links.
Open issues, or decisions
Keep track of open issues / key decisions here. Document these here so people know that the discussions have happened and there’s strong awareness of the tradeoffs.
Launch Plan
Define the various phases (if necessary) 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.
Solution Alignment Approval
List any Shipping Dept member who needs to approve the Solution Alignment. This could be a manager, cross-team PM, or exec. Each person will check their name off once they have approved.