.jpg)
👉 Download our product discovery template for Notion
Advice on product discovery is everywhere, but turning it into actionable steps for everyday work can be surprisingly difficult for product managers. In this article, we will break down the product discovery template we use for every new feature we build step by step.
Before getting into the framework, let's highlight the often-overlooked difference between product and feature-level discovery. While both aim to build something valuable for users, their goals, scope, and methods differ significantly.
Product-Level Discovery
The focus here is on a problem area outside your existing product's scope.
Example: Many of your user base often asks for tools to help them manage client billing and invoicing. This is outside the scope of your core offering, a project management product.
Feature-Level Discovery
Feature discovery, on the other hand, is more focused and iterative. Your job is to find ways to improve or evolve it. The goal is to figure out how to solve a specific problem for your users in a way that aligns with the broader product vision.
Example: Your users frequently ask for a Kanban view to manage projects because they are currently switching to other tools like Trello for this functionality.
Both processes share iterative refinement but differ in terms of scope, complexity, and costs/timeframes involved. For example, spending a couple of months doing product-level discovery on a new feature to sort some data in a table is outrageous. Reference needed
Since building new features within existing products is far more common than creating entirely new products. For this reason, the remainder of this article will focus on unpacking the product discovery template we use for building new features.
In my early career, I managed a mobile mapping app, and at the time, our process looked like this:
For a while, this straightforward approach worked. But cracks began to show when we realized we were building features without clearly understanding the problems they were meant to solve.
The turning point came when we shipped an offline mapping feature. I had a general sense of the need, but without diving deeper into our users' exact pain points, we ended up with a feature that wasn't valuable. It was a hard lesson in how costly poorly defined problems can be. Read more about this experience here.
With this in mind, I knew we had to shift our approach. We started spending more time understanding and defining the customer problem before jumping into solutions. Now, our product planning process follows 3 key steps:
The additional time we invest in the discovery phase is worth it. It ensures that only well-defined ideas make it to design, preventing wasted effort and ensuring that the features we build truly add value.
.jpeg)
Signs that feature-level discovery is broken usually show up in how features are designed, developed, and received by customers. Here are some common red flags:
Symptom: Customers don't use new features or revert to workarounds.
Why it Happens: Lack of proper validation before development or misunderstanding of the customer's real problem.
Example: You add a “Tasks Completed by Team Member” report, but users still export raw data to analyze progress manually across multiple projects.
Symptom: Decisions are made based on gut feelings, stakeholders' opinions, or competitors' actions.
Why it Happens: Insufficient customer research or over-reliance on HiPPOs (Highest Paid Person's Opinion).
Example: A dashboard that tracks the number of tasks created in a project, but customers care more about task completion rates and overall project progress.
• Symptom: Engineers feel they're solving poorly defined problems or building "fluff" that adds little value.
• Why it Happens: Lack of clear problem definition or proper scoping during feature-level discovery.
• Example: Developers spend time building a fancy analytics widget, only to discover it does not fit with the customer workflows.
Symptom: New features require multiple iterations post-launch due to missing requirements or poor usability.
Why it Happens: Inadequate prototyping, usability testing, or user feedback loops during the discovery phase.
Example: Users complain that setting up project timelines involves too many manual steps after the feature goes live.
Symptom: Features don't drive measurable outcomes like retention, revenue, or customer satisfaction.
Why it Happens: Discovery focuses on isolated customer requests without aligning them with business objectives.
Example: You prioritize tracking "tasks created" when your business goal is to improve project completion rates and team efficiency.
Symptom: Features are shipped without prototyping, testing, or validating with users.
Why it Happens: Pressure to deliver quickly or misaligned priorities that favor delivery over discovery.
Example: A reporting feature is added without testing with customers, confusing how to interpret the data.
Symptom: The team focuses on specific customer demands without validating how widespread the need is.
Why it Happens: Listening to the loudest customers without checking if their needs represent the majority.
Example: A feature tracks time spent on a specific project template used by only 5% of customers.
Symptom: No clear KPIs for new features, or the metrics indicate failure post-launch (e.g., low adoption, poor satisfaction scores).
Why it Happens: Discovery doesn't set measurable goals or test assumptions during the development phase.
Example: After launching a dashboard for project task tracking, feedback shows users find it overly complex and avoid using it.
Symptom: Team members don't have a shared understanding of the problem or solution.
Why it Happens: Discovery work is siloed, leaving critical perspectives out of the process.
Example: Marketing assumes the feature will drive conversions, but the design team never validated how users interact with it.
.jpeg)
👉 Download our free Notion template to streamline your product discovery progress
The first step in starting things off is forming an initial hypothesis. Think of it as planting a flag in the ground. "Here's the general problem we're tackling and why it needs to be solved now." You don't need all the answers yet, you need a starting point to focus your efforts.
This is most effective when done collaboratively with stakeholders such as leadership, sales, and other key teams. They can provide valuable perspectives on the urgency and relevance of the problem based on strategic goals, customer insights, or market trends. Engaging stakeholders early ensures alignment across the organization and helps set a strong foundation for the discovery process.
This step involves digging into the data to refine our understanding of the problem and potential solutions. The goal is twofold: first, we gather what customers have already told us about this problem and understand what options are available in the market for solving it.
Where to look for this data:
Now, it's time to pull everything together. The goal is to combine your initial hypothesis with the insights from your research and narrow down a high-level problem to a crystal-clear problem statement. Getting specific here is critical, as this sets the stage for designing the right solution.
Examples:
High-Level problem: Teams struggle to stay updated on project progress.
Problem Statement: Managers can't quickly see which tasks are behind schedule because they need to go to individual task pages for the status.
For this part, we often lean on the 4Cs Framework to further define the problem statement. This framework helps ensure that we're being specific about the issue and understand its implications for both users and the business.
By starting with the Context, we ground ourselves in the background and circumstances surrounding the problem. For example, what trends or user behaviors have led us to identify this issue now?
Next, we focus on the Customer, diving deeper into who is experiencing this problem and why it matters to them. Are they power users of the product? Casual users? Understanding their specific pain points helps us build empathy and tailor solutions.
From there, we move to the Challenge. What's stopping the Customer from achieving their goals? This is where the problem comes into sharp focus, narrowing from broad frustrations to specific obstacles.
Finally, we look at the Consequences of leaving the problem unsolved. This ensures we prioritize problems that matter, focusing on those with significant user or business impact. Will it cause churn? Reduce productivity? Lead to missed opportunities? This clarity aligns the team and provides a strong foundation for decision-making during design and development.
At this stage, it's time to start visualizing potential solutions. The key is to keep it simple. Napkin wireframes (i.e. Lo-Fi) are quick, rough sketches that focus on the concept rather than specific details. The goal is to explore ideas, communicate them to your team, and test whether they address the defined problem.
These wireframes don't need to be polished. Think pen and paper or a basic drawing tool. Focus on:
User flow: What steps does the user take to solve the problem?
Key elements: What's on the screen, and how does it help the user?
Simplicity: Avoid complexityDon't. Stick to the essentials.
Lofi wireframes are a great way to align with stakeholders and gather feedback early without investing too much time or resources. They ensure everyone is on the same page before moving into detailed design.
With these artifacts in place, now is a great time to involve engineering. Engineers bring a unique perspective to the table. They deeply understand the technical possibilities and constraints, making them a fantastic source of creative ideas. Their input helps identify what's feasible, what's not, and where potential pitfalls might lie. Getting their input at this stage allows you to define the problem and its scope more effectively.
Equally important is discussing what's out of scope. This ensures the team stays focused on the most critical aspects of the problem without getting sidetracked by secondary or unrelated issues. Defining what's out of scope early helps manage expectations, align priorities, and avoid scope creep during the design and development phases. It also ensures that resources are allocated effectively, with the team concentrating on solving the right problems without unnecessary distractions.
👉 Download our free Notion template to streamline your product discovery progress