ProductFTW #29: The Product Brief

Have you ever lost alignment with your engineering team or struggled to get everyone on the same page? 

Whenever I felt this way, it was likely because I rushed through the Product Development Lifecycle (PDLC) to deliver requirements to my team as quickly as possible. Although well-intentioned, skipping steps in the PDLC can lead to misalignment and confusion. The PDLC exists for a reason, and a core part of its value lies in the artifacts you create along the way. These artifacts help get buy-in from the team, create alignment, and ensure that what you ultimately deliver is the correct solution for your user. The product brief is one artifact that doesn’t always get the attention it deserves.

What is a Product Brief?

A product brief, also known as a product proposal, is a concise (usually less than one page) strategic document created in the earliest stages of the PDLC: the strategy phase. It outlines the key elements of a potential project and, unlike more detailed documents like the product requirements document (PRD), a product brief focuses on high-level alignment and sets the stage for deeper exploration and validation. Essentially, it’s about putting your hypothesis on paper for the team to assess and determine if it’s worth pursuing.

Product Brief Outline

While there isn’t a set template for a product brief, as every product manager has their own style of communication, at its core, a product brief should generally include the following sections:

1. Summary: A high-level overview of the project, including a hypothesis that outlines what you plan to do and why.
2. Problem Statement: A clear articulation of the problem you aim to solve and the audience it affects.
3. Project Objective & Business KPI(s): Specific objectives for the project and the key performance indicators that will measure success.
4. Company Goal Alignment: How the project aligns with the broader goals of the company.
5. Data Summary: Initial evidence supporting the importance of solving the problem, such as research or analytics.
6. Success Criteria: The metrics or outcomes that will indicate whether the problem has been effectively addressed.

Why is a Product Brief Important?

The product brief is important for several reasons:

1. Early-Stage Alignment: At the beginning of a project, teams face a lot of uncertainty. The product brief helps align everyone by clearly articulating the problem, the proposed solution, and the initiative's goals. This alignment is crucial for ensuring that everyone is on the same page before moving forward.
2. Guiding Strategic Decisions: The product brief serves as a strategic tool to help guide decision-making in the early stages of development. It provides a framework for evaluating whether a project is worth pursuing based on the hypothesis and supporting data.
3. Setting Expectations: The product brief outlines the project's objectives, KPIs, and success criteria, setting clear expectations. This clarity helps prevent scope creep and ensures that the team remains focused on the most important outcomes.
4. Efficient Communication: The product brief is a highly effective communication tool. It distills complex ideas into a concise format that is easy for everyone to understand and discuss. This is especially important when dealing with cross-functional teams with different perspectives on the project.

How is a Product Brief Used in the PDLC?

I’ve mentioned the PDLC a few times. The product brief is used during the strategy phase to establish a strong foundation for the project. However, this doesn’t mean you’ll create the artifact and then immediately discard it once you move to the other stages of the lifecycle. The product brief is actually used and built upon during every stage of the PDLC:

• Strategy Phase: The product brief is created during the strategy phase, where the team explores different ideas and concepts. This document helps narrow the focus to a specific problem and solution that aligns with the company’s goals.
• Discovery Phase: Once the product brief is approved, the project moves into the discovery phase, where the initial hypothesis is validated through research, prototyping, and user testing. The brief serves as a reference point during this phase, ensuring that the team remains aligned with the original objectives. This is typically when the brief starts to evolve into the beginnings of the PRD.
• Development Phase: As the project progresses into development, the product brief continues to evolve as the guiding document. It provides the context and rationale behind the project, helping the team make informed decisions as they encounter new challenges and opportunities.
• Launch and Post-Launch Phases: The product brief remains relevant even after the product is launched. It should be used to evaluate the project's success based on the KPIs and success criteria defined in the brief. Additionally, it serves as a historical document that can inform future projects.

As the product brief evolves, it is important to keep an intact version to show the evolution of the project and findings.

How to Compile a Product Brief

Now that we have a solid foundation of what a product brief is and why it matters let’s discuss how to actually create one using the outline referenced above with examples for each.

Summary

The summary is the foundation of your product brief. This section should provide a high-level overview of the entire document and include a well-crafted hypothesis. If you don’t remember the formula for a hypothesis (I immediately forgot this after high school), here is the outline I use:

By [doing this thing/building this feature/creating this experience/building this solution] for [this user/customer segment/customer profile], we will achieve [this business outcome] and solve [this user problem/this gap in the market]. We will measure this by seeing [this quantitative/qualitative outcome].

Then, apply that formula to your product. Example:

By offering a consumer credit card that rewards points on rent payments for young professionals, we will increase card adoption and usage while solving the challenge of low-value transactions among this segment. We will measure this by seeing a 25% increase in monthly active users and a 15% increase in average transaction value.

The summary should also briefly touch on the key points that will be covered in the rest of the brief, such as the problem being addressed, the objectives, how the project aligns with company goals, and the success metrics that will be used to measure outcomes.

Problem Statement

The problem statement clearly outlines the specific issue that your product is designed to solve. This section is important because it focuses your team’s efforts on addressing a real and significant challenge that impacts your target audience.

Young professionals often struggle to earn rewards on their largest recurring expense: rent. This leads to lower credit card usage among renters, reducing their engagement with credit products.

The problem statement should identify who this problem affects and why it’s important to address it.

Objective & Business KPIs

Once the problem is clear, the next step is to outline what you aim to achieve with this project and how you will measure success. The project objective should be specific and aligned with solving the identified problem. KPIs (Key Performance Indicators) are crucial for tracking the progress of your project and ensuring that it meets its goals.

Objective: Increase card adoption and usage among renters by offering rewards on rent payments.

KPIs: A 25% increase in monthly active users and a 15% increase in average transaction value.

This section directly connects the objectives and KPIs to the project’s success, providing measurable outcomes guiding the team’s efforts.

Company Goal

Your project should support broader company objectives. This section ensures that your project is not just solving a problem but also contributing to the business's overall success. Aligning your project with company goals shows how it fits into the bigger picture.

If the company’s goal is to expand its market share among young professionals, this project’s objective of increasing credit card adoption among renters directly supports this by attracting a key demographic.

This alignment demonstrates the strategic importance of the project and its role in driving overall company growth.

Data

To strengthen your brief, include data supporting this project's need. Data provides evidence that your problem is real and that your proposed solution is viable. This can include market research, user feedback, or any other relevant data points. Example:

Market research shows that 70% of young professionals rent their homes, and 80% would be interested in a credit card that offers rewards on rent payments.

Presenting this data validates the problem and justifies the need for your proposed solution.

Success

Finally, outline how you will measure the project's success. Success criteria should be tied directly to your KPIs and clearly indicate whether the project has achieved its objectives. This section is crucial for ensuring that everyone understands what success looks like for the project.

Success will be measured by a 25% increase in rent payments made with the card and a 15% increase in average transaction value.

Defining success in measurable terms allows you to track progress and determine if the project delivers the expected outcomes.

Putting It All Together

Compiling a product brief is about clarity, alignment, and evidence. Each section should build on the last, creating a cohesive narrative that clearly articulates the problem, the proposed solution, and the expected outcomes. By following this guide, you’ll ensure that your product brief is a powerful tool for early-stage alignment, setting your project up for success as it progresses through the development lifecycle.

About ProductFTW

ProductFTW is a weekly newsletter about product management focusing on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.