Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Discovery Brief Template

Project: [Project Name]

Status: [Productboard Status]

Last Updated: [Current Date]

Product Manager: [@Product Manager]

Part I: The Opportunity Proposal

Purpose of this section: To quickly propose a candidate for the roadmap. It should be high-level and compelling enough to justify spending more time on discovery and validation. It proves the problem is worth exploring.

Problem Statement

What is this section for? This is the most critical section. It clearly defines the problem you are solving and justifies why the company should invest time and resources into this project. A strong problem statement ensures everyone is aligned on the "why."

How to write it: Start with a single, crisp sentence. Then, break it down from the customer and business perspectives. Include at least one key data point or user quote to make it tangible.

  • Core Problem: [A one-sentence summary of the who, what pain, and why it matters.]

  • For the Customer: Describe the pain points, frustrations, or unmet needs our users are experiencing. What is difficult, slow, or impossible for them to do today? Include a powerful user quote if you have one.

  • For the Business: Explain how the customer's problem impacts the business. Does it affect revenue, increase operational costs, hurt retention, or prevent us from hitting strategic goals? Quantify this where possible (e.g., "estimated X% in lost efficiency," "25% of support tickets," etc.).

Vision

What is this section for? This is the North Star for your project. It's a brief, aspirational statement that describes the ideal future state after your project is successfully launched. It should inspire the team and clarify the long-term purpose.

How to write it: Keep it to a single sentence. Focus on the customer and the value you are creating.

To [verb describing the core user action, e.g., "empower," "enable," "provide"] our [user persona, e.g., "administrators," "end-users"] with the ability to [the ideal outcome for the user] by [a very high-level description of the solution].

Proposed Solution

 

What is this section for? A high-level summary of the approach you're considering. It is not a list of requirements. Its main job is to define the scope and manage expectations early.

How to write it: Briefly describe the core components of the experience. Be explicit about what is out of scope for the first version to prevent scope creep.

We believe we can solve this problem by [building/designing/integrating] a [name of the feature] that allows users to [describe the core functionality].

This will likely include:

  • A high-level component (e.g., "A new dashboard view...")

  • Another high-level component (e.g., "A self-service configuration panel...")

Out of Scope for this version:

  • Be explicit about what you are NOT building right now (e.g., "Mobile support," "Integration with X," "Advanced reporting").

Initial Goals & Success Metrics

 

What is this section for? This defines what success looks like in tangible terms. These are initial thoughts that will be refined in Part II.

How to write it: List 1-2 primary goals. For each, define a specific Key Performance Indicator (KPI) you believe will prove success.

Goal

Success Metric (KPI)

Example: Improve user self-sufficiency

Decrease support tickets related to [topic] by X% within 3 months of launch.

Example: Drive expansion revenue

Achieve $[X] in new MRR from this feature in the first 6 months.

Example: Increase user engagement

Increase the adoption rate of [feature area] by X% (measured by Weekly Active Users).
 

Phase II: Discovery & Validation

Purpose of this section: To be completed after initial discovery work (user interviews, data analysis). It de-risks the project by validating the problem and proposed value. This section provides the evidence and confidence needed to move from "Candidate" to "Ready for Design/Build."

Deep Dive: Users & Context

What is this section for? To ground the project in reality by deeply understanding who we are building for and the context they operate in. This prevents ivory-tower assumptions.

  • Primary User Persona:
    How to write it: Summarize the target user in a few bullet points. Include their role, main goals, top frustrations, and level of tech-savviness. You can link to a more detailed persona document if one exists.

  • Core Job(s) To Be Done (JTBD):
    How to write it: Use the "When..., I want to..., so that..." format to describe the user's underlying need. Focus on their motivation and desired outcome, not on features. You should have 1-2 core jobs for a well-scoped project.

  • Environment & Context:
    How to write it: Describe where and how the user works. Are they in a noisy office or a quiet remote setting? Are they constantly interrupted? What devices do they rely on? This context is crucial for making good design decisions.

Deep Dive: Problem Validation

 

What is this section for? To provide overwhelming evidence that the problem is real and painful. This section details the "why now" with qualitative and quantitative data.

  • Detailed Pains & User Quotes:
    How to write it: List the top 3-5 pain points you've uncovered in your research. For each pain, add a direct, impactful quote from a user interview. This makes the pain feel real. If possible, add a data point showing the business impact (e.g., "This leads to an estimated 5 hours of wasted work per week.").

  • Current Workarounds:
    How to write it: Describe the "hacks" or inefficient processes users have created to solve this problem today. Mentioning things like spreadsheets, sticky notes, constant emailing, or using multiple different tools are strong signals of an unmet need.

  • Secondary Stakeholders:
    How to write it: Think beyond the primary user. Who else is affected by this problem or will be affected by the solution? List them and what they care about (e.g., "Operations Manager - cares about team efficiency and cost reduction."). This helps prevent blind spots during rollout.

Deep Dive: Hypotheses & Risks

 

What is this section for? To explicitly state our core beliefs and identify the biggest risks that could cause this project to fail. The goal of discovery is to validate these hypotheses and mitigate these risks.

  • Opportunity Hypothesis:
    How to write it: Frame your core bet in a single statement. A good format is: "We believe that by [building the proposed solution] for [our persona], we will achieve [a desirable customer outcome], leading to [a measurable business impact]."

  • Key Assumptions to Validate:
    How to write it: List the 3-5 most critical things that MUST be true for your hypothesis to succeed. These are your leaps of faith. Frame them as statements to be proven (e.g., "We assume users are willing to share their data for optimization.").

  • Key Risks & Mitigations:
    How to write it: Identify the biggest known threats to the project's success (technical, business, or user-related). For each risk, propose a concrete mitigation (a plan to reduce the risk) or a spike (a time-boxed investigation to learn more).

Validation Plan & Next Steps

 

What is this section for? To turn discovery into an actionable plan. This lists the specific activities you will undertake to learn, validate assumptions, and mitigate risks.

  • Learning Goals:
    How to write it: Turn your "Key Assumptions" into questions you need to answer. What are the most important unknowns we need to resolve in the next 1-4 weeks? (e.g., "Can users easily understand our proposed workflow?").

  • Activities & Experiments:
    How to write it: List the concrete tasks you will perform to answer your learning goals. Be specific: "Conduct 5 interviews," "Test a clickable prototype with 8 users," "Perform a technical spike on the X API." Assign an owner and an ETA to each.

  • Success Signals:
    How to write it: Define what "good" looks like for each activity before you start it. This helps avoid confirmation bias. For example: "We'll consider the prototype successful if at least 4 out of 5 users can complete the core task without assistance."

Discovery Partners & Interested Customers

 

What is this section for? To demonstrate a ready "lab" for interviews and a potential list of beta customers. This builds confidence that we have a path to getting feedback.

How to write it: List the companies and specific contacts who have expressed interest or agreed to help. Include their status (e.g., "Contacted," "Interview scheduled," "Expressed strong interest for Beta"). This shows you've done the legwork.

 

Project Documents & Links

 

What is this section for? A centralized hub for all project-related artifacts. Keep this updated as the project progresses.

How to write it: As you create new documents (research notes, Figma files, technical docs, Jira epics), add the links here. This turns your brief into a true and lasting project hub for anyone who joins the project later.