PM Handbook @jabondano

Explore

Ideation

Project Brief

Steve Morin - ProductiveGrowth

Project Name - Template

September 04, 20XX by Steve Morin

If you like this template join my newsletter ProductiveGrowth for more on Leadership, Management, Productivity, and Growth:

https://productivegrowth.substack.com/⁠

⁠

Template Purpose

Introduction to a new project should use this template. It’s used to give people an introduction to why a project is being pursued, what a project 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 short summary of the project.

This should be no more than one paragraph.

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 that have been encountered. For example context for an Onboarding experience project might be that there have been ongoing issues and complaints that it’s 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 is a feature or project doesn’t increase a metric it should cause it to go down either. For example, adding a feature should cause signups to go down, revenue to drop or churn to go up.

Assumptions & Risks

Platforms

Web

iOS

Android

Backend

Assumptions

In-Scope:

Activities, behavior, or outcomes that are assumed to be part of this project.

Costs, estimate, 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.

Skills that are difficult

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. If it’s not known, a list of assumed features and functionality should be added.

Feature 1

Functionality 1

Features and Functionality (Optional)

What features and functionality will be in the project. If it’s not known, a list of assumed features and functionality should be added.

Feature 1

Functionality 1

Dependencies

Dependency

Link to Execution Tracker

Owning Team/Person

Why it’s a dependency

When is it needed by?

There are no rows in this table

⁠

Technical Design (Optional)

If your project is mostly technical or back end this section should definitely be filled out. Otherwise, it’s optional for more consumer-facing projects.

i.e., we need X client work, Y server work, Z XFN

Reference Documents (Optional)

Document 1

Document 2

Open Questions

Identify anything that is unknown, unclear, undecided, and/or risky:

<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

There are no rows in this table

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.