I introduced this template to the team around 2020 or 2021. There were a few reasons why. The biggest was that a lot of time you don't build 0 to 1 products– sometimes you have a stakeholder requesting something or the company is really excited to build something. In those situations, I found that PMs were taking on more of a Project Manager hat than a Product Manager hat. I saw PMs jumping into execution. This template makes the PM think about the problem in the right way and note it down. Taking this step also helps to pitch the project to the team versus just saying "senior leadership decided we're doing this."

We were also struggling with information living in different places. We ran our quarterly prioritization from Google Sheets. For each item, the team felt there was not enough information provided during the planning sessions. The short summary in Google Sheets was not enough, and the information from research, workshops, presentations would be in separate tools and documents. This document brings everything together in one living and breathing document.

This template is very specific to my team: the growth team for Clover, which is a startup that was acquired by a much larger organization, Fiserv. Growth's scrum process and release process is the same as the broader Clover product team's, but the product brief was heavily curated for my team.

The broader Fiserv org typically uses PRDs. Fiserv is a big financial company, so they have a lot of processes in place due to regulatory environment. They're very waterfall because product changes need multiple layers of reviews.

The initial version of this template actually was still a PRD. It had all of the problem definition material plus the requirements, plus the execution plan (e.g., AB test, launch with feature flag, etc.). Having all of that in one document made it too long for anyone to read through. It also felt a bit waterfall because you had to make a lot of assumptions to create requirements upfront. By splitting the doc up, it forces you to be more iterative. You're not just working backwards from an execution goal.

Breaking up the PRD into briefs really helped get the team to collaborate. It's easier for the team to engage and give feedback when the product brief is broken up into different stages. A lot of the ideas and solutioning comes from the team.

This template is meant to be collaborative, and it's really important to empower the team to own this doc. That said, I've found that it's helpful for the PM to have a perspective and take the lead drafting the doc, and then hand it over to the team for feedback and collaboration. Ideally, you involve your engineering team during problem definition, but some engineering teams aren't interested in engaging at this stage. Ultimately, it's flexible with who on your team owns the problem definition stage. The whole team can own the discovery phase together.

After Part 1, we move to the solution phase. However, there have been cases where we don't go on to the solution phase after writing the problem brief. That's not a huge loss because the effort is to write the problem brief is low. Even if we don't end up prioritizing the problem in a quarter, it's handy to go back to the brief. A lot of times, a brief was created, then left alone, and then we prioritized that particular problem and took the brief back and reworked it.

We integrate this template into our quarterly planning process to make sure the cross-functional teams are aligned on the problem space. In our org, we have marketing, sales, and lots of stakeholders with competing goals. Each PM works with leadership to align on goals. We have a readout of the prior quarter's goals and come up with key goals for the upcoming quarter. These are generally high-level business goals, but are still specific enough to provide direction.

These goals are then broken down into initiatives and opportunities. For each opportunity, we use this template to create a one pager, which drives prioritization for what you do in the quarter. We try to use a sand, pebble, and rock method for quarterly planning (three big initiatives, then smaller projects to fill in gaps). Context switching is a big challenge for growth teams, so this goal prioritization process helps people assess initiatives and avoid too much thrash. These problem definition briefs help drive those conversations.

If you have a very simple or small project, it can be up to the team whether to invest the time into creating this doc. For big bets, this doc works very well.

The first time I used this doc was actually right after Clover was acquired. We had an initial kickoff to align around the problem we were approaching (monetization) and to figure out our DACI framework. Then I had lots of 1-1s to really understand the goals and who owned different things. I then created my one pager using this template and had a meeting to align on goals and the high level execution plan. We ran through each section make sure we were aligned with senior leaders. The senior leaders were very excited to provide feedback. What works well is sending this doc as a pre-read and then getting feedback in the alignment meeting.

For simpler projects and problem spaces (e.g., "improve conversions"), you may just have a brainstorming meeting instead of a kickoff, and the kickoff may just be with your triad. It happens a little bit differently depending on the source of the initiative; this template is agnostic as to whether you do a kickoff.

We have a user research team that facilitates research for all teams. They have a separate template to define the goal of the research, the questions you're trying to answer, etc. The user research team acts as an advisor and facilitator. Design leads the research and the PM participates. That work is then summarized and added to this document.

Ultimately, the PM owns defining the problem. Along with their design and eng leads, they decide what needs to be done.

I was debating whether the "vision" section of this template should come before the "customer problem" section. Ultimately, I went with "vision" first because a lot of times when we bring in engineering, they often ask "what's your vision" for a guiding principle. They're not as involved in the user research and instead just want us to start with the vision for the product.

You can go back to the document at any time to update the vision. When I'm starting the initiative, the vision is typically very rough. As you define the solution, you go back and improve the vision statement. You're expected to refine it over time.

A lot of stakeholders don't know how to work with ambiguity. If they don't have a perspective from the PM as to where we're going, they don't like that. They need the vision to feel more grounded.

The discussion of which customer problems to prioritize happens in yearly planning. The VP of Growth and the executive team prioritize the goals for the growth team and stack rank them. Every quarter we assess whether to focus on the same goals or shift them.

The customer problems evolve over time as your understanding and your product mature. When you have a new product, your customer problems look different, especially for growth teams. As you get more users and more data, you have to keep iterating over time and solidify your understanding of the customer. Your team goals, metrics, and the customers you focus on will all change over time.

Scope typically changes as you think through technical tradeoffs and conduct research. When you start the problem brief document, your scope is pretty high level and we expect it to evolve. It should be based on what you know (and don't know); you don't need to do weeks-long research spikes at this point. It's totally normal for an initial product brief to break up into smaller briefs as your understanding of what's feasible evolves.

If you have high-level principles around how you make product decisions (like Amazon's tenets), that's great, but every company should define their own since every product is different. Articulating your decision making principles in this doc works really well because when presenting to leadership, they will want to know why you're doing things a certain way.

Two great things happen when you define your decision making principles upfront. First, there are fewer conflicts within the triad because you can always go back to this. It leads to much easier conversations within the team. Second, when I'm doing a walkthrough of an initiative with external stakeholders, all you have to do is remind people about these principles and no one will be surprised later on.

The teams really appreciate when a PM sketches out the current state to bring them on the same page. When possible, it's great to have this as a visual.

Monil Shah

My growth team at Clover used this template to define and align on product problems, helping to drive prioritization for the quarter. After completing problem definition, the team moves to defining the solution space and execution plan.

 with your triad (Product, Design, Engineering) to build amazing products. As a product manager, your job is to ensure that your team builds a product that solves the right problems, is well-designed, and is executed effectively. To achieve this, you need to work distinctly in three key areas: the problem space, the solution space, and the execution space.

Clearly articulate and document the problem space in collaboration with the team.

Empower your team to come up with creative solutions to solve the problem.

Easily get buy-in and keep your stakeholders informed.

This document assumes that you have conducted the 6 steps below and are ready to use this document template to define, document, and communicate the problem space to kickstart collaboration on the solution space:

: Talk to your users, observe their behavior, and understand their needs and pain points. Use this information to identify the most significant problems your product can solve.

Analyze data: Analyze data from your product and the market to understand trends and identify areas for improvement.

Understand the competition: Research your competitors to understand their strengths and weaknesses and identify opportunities for your product.

Prioritize problems: Prioritize the problems you’ve identified based on their impact on your users and the business and are ready to tackle the most important one.

Define Business Value: It is crucial to have a clear understanding of the business value of your product to ensure that it aligns with your company's overall strategy and goals.

Set SMART Goals: This will help ensure that your team can track progress and measure success. Make sure to involve your team in the goal-setting process to ensure that they have buy-in and ownership of the goals.

Guide: Come up with an initial vision of the product to bring it to the team but be flexible for evolving it as you detail out the solution with input from the triad. This helps the team get high level context.

We are thrilled to introduce our new subscription product, designed to provide a unique and personalized experience to our customers. Our subscription plans are tailored to meet diverse needs and offer competitive pricing and customization options. With a user-friendly interface, sign-up and service access are easy. We also offer a range of features that are unique to our product, such as exclusive content, personalized recommendations, and priority customer support.

Guide: This template works to well to be specific about customer and problem

where managing multiple service subscriptions is becoming increasingly complex and time-consuming.

overwhelmed and stressed, as I struggle to keep track of all my individual payments, contract terms, and service renewals.

I often miss out on important updates and exclusive content that I have paid for, and I waste a lot of time trying to manage my subscriptions.

Guide: Provide a summary of insights which you have gathered to make a business case for this product. Link out to documents for more details on the insights.

Sales data analysis showed that customers who purchased our product on a recurring basis accounted for 40% of our total revenue over the past year, indicating a potential revenue opportunity for a subscription product.

Competitor analysis revealed that many of our competitors were offering subscription-based products, indicating a need for us to remain competitive and meet customer expectations.

PM can to the best of their judgment come up with some high level scope based on understanding of customer, product, business and stakeholder conversations.

Be ready to explain how you came up with scope and the prioritization, as well as brainstorming and getting feedback from the team to adjust the scope.

Subscription management dashboard: A centralized platform that allows users to easily view and manage all their subscriptions in one place.

Integration with popular services: The platform integrates with popular services like Netflix and Spotify, allowing users to easily add their existing subscriptions to the dashboard.

Notifications and reminders: Users can set up notifications for upcoming renewals and failed payments.

Exclusive perks and content: The platform offers exclusive content or discounts from partner services to incentivize users to sign up.

Customizable settings: Users have control over their account settings, including the frequency of notifications and which subscriptions to prioritize on the dashboard.

Guide: Work backwards from your North Star metric and come up with qualitative and quantitative measures. Consider what can be measured and cannot. Consider metrics which demonstrate truly the value to the customer and value to the business. Consider tradeoffs with other metrics which may be impacted.

Increase conversion rate by 15% within the first 6 months of launching the subscription product

Achieve a customer satisfaction score of at least 8 out of 10 within the first year of launching the subscription product.

Guide: These principles will serve as a guide for making decisions with the triad. In case of multiple options or conflict, you can use the principles to help with decision making.

We will prioritize maximizing conversion and revenue from a broad customer base over focusing solely on increasing revenue per user (ARPU) in our subscription pricing strategy.

We will incorporate our existing design of three packages (good, better, best) in our pricing system to maintain consistency with our brand and ensure a seamless customer experience.

Our pricing system will be designed using a microservice architecture approach for optimal technical performance and scalability

Guide: Create a user flow diagram or sketch to provide context to the team about the customer journey or situation.

Product Problem Definition Brief Template at Clover

Problem Definition Brief Template

Template Overview

Sign up to see more