⭐️⭐️⭐️
Steve Morrin
Template Purpose
You should use this 1-Pager Project Brief template for an introduction to a new project. It’s used to introduce people to why a project is being pursued and what it is about, including context, how it’s being measured, strategy for implementation, and initial design/features if they exist.
Project Introduction
Answer the question of what you will be working on:
- Author: <name>
- A summary of the project.
- This should be one paragraph at maximum.
- Designs (Optional if they exist)
- Milestone 1: <px link>
- Milestone 2: <px link>
Vision / Why
1 sentence description of why you’re pursuing this project.
Context:
Provide background information about the project. Answering questions like “What’s broken?” or problems encountered. For example, the context for an onboarding experience project might be that ongoing issues and complaints make it hard for the user to onboard, so this is important to help users onboard.
Objectives (What) / Key Results (How to measure)
Objective:
- What are we trying to accomplish?
Key result(s):
- What is a specific time-bound measurement to indicate success?
Strategy / How
Name of the first strategy
- How to implement the first strategy. Details about what will and won’t be done for this strategy.
Goals
- Operational Success Metric
- A measurable number to determine if the project or feature of the project is succeeding.
- Counter Metrics
- A measurable number to determine if things aren’t regressing. So, even if a feature or project doesn’t increase a metric, it shouldn’t cause it to go down either. For example, adding a feature shouldn’t cause signups to go down, revenue to drop, or churn to go up.
Assumptions & Risks
Platforms
- Web
- iOS
- Android
- Backend
Assumptions
- In-Scope:
- Activities, behaviors, or outcomes that are assumed to be part of this project.
- Costs, estimates, or inputs into planning that are part of the project.
- Add questions about the assumption below in open questions and reference that here.
- Out-of-Scope:
- Things that are explicitly being left out of the project.
- Outcome or non-goals of the project.
Risks
- Call out unknowns.
- Difficult skills
- Known risks in the market, execution team, or parts of the project.
Risk Mitigation Strategies
- What will be done to reduce risks?
Features and Functionality (Optional)
What features and functionality will be in the project? A list of assumed features and functionality should be added if it's unknown.
- Feature 1
- Functionality 1
Features and Functionality (Optional)
What features and functionality will be in the project? A list of assumed features and functionality should be added if it's unknown.
- Feature 1
- Functionality 1
Dependencies
Dependency | Link to Execution Tracker | Owning Team/Person | Why it’s a dependency | When is it needed by? |
Technical Design (Optional)
If your project is primarily technical or backend, this section should definitely be filled out. Otherwise, it’s optional for more consumer-facing or business projects.
i.e., we need X client work, Y server work, Z XFN
Reference Documents (Optional)
- Document 1
- Document 2
Open Questions
Identify anything unknown, unclear, undecided, and/or risky:
- <question/statement> → <owner of this action item> to <take action X>
- <sub-question/item> → <owner> to <take action Y> by <date>
- <sub-question/item> → <owner> to <take action Z> by <date>
Next Steps and Action Items
Action | Status | Owner |