How to Build the Right Product
Weave product discovery into your roadmap to find the highest impact opportunities
Working on cutting-edge solutions is sexy. But even the most innovative product could be useless if it doesn't solve a real user need. I'm looking at you, Samsung Galaxy Fold...
Finding the right problems to solve is one of the most important roles of a product manager. But unfortunately, we don't spend enough time understanding the problem because it’s easier to build solutions that move our KPIs.
Today, I want to dig deeper into why and how we can weave the process of problem discovery into the roadmap. Doing this effectively will help you:
Find product-market fit: ensure that your building against a real customer need will allow you to find a fit in the market.
Help your team achieve more: you'll have more impact if the problems you're solving are big, nuanced opportunities.
Advance your own career: build a reputation for tackling important problems (rather than being distracted by unimportant ones).
Let’s jump in.
👩🏫 What does understanding look like?
I became the PM of a brand new team recently. We assembled a group of 10+ people to tackle an area necessary for our product's strategy. The challenge: none of us were familiar with the users, problems or opportunities in the space. This made our early feature ideas shallow and unfounded.
We needed to understand the problem before we could identify the right solution. This is exactly what an understand roadmap is meant to do.
An understand roadmap is filled with research projects into specific topics. Like a regular roadmap, these research projects are prioritized against their impact and the effort it will take to complete.
But unlike a regular project, the goal of research projects is to create actionable product insights. These are ideas, opportunities or problems that can directly lead to impactful work for the product team. This forces these research projects to be more actionable than academic studies.
I've observed six types of research projects, each of which is lead by different members of the product team. Use these to inspire you and your team to discover unknown opportunities:
🤷♂️ User Research (led by user research or design):
Understand the user’s interactions with the problem space or your product specifically. If you were a payments company, this could be user interviews with 10 people who don't use digital payments, a survey of "power users" to understand why they use your product or eye-tracking of first-time users to see what they focus on.
📊 Data Research (data scientist-led)
Understand the trends, funnels and lifecycles that are relevant for your product. This may be defining user segmentation, visualizing the checkout funnel or finding the drivers of adoption to your product.
💼 Market Research (biz-ops, operations or product marketing-led)
Understand the market landscape and the challenges of businesses in your space. This may be speaking to partners, enterprise customers or end users. This group often works with sales, customer success or partnerships to coordinate meetings with the relevant parties.
👨⚖️ Regulatory Research (legal, policy, privacy or finance-led)
Understand the restrictions, opportunities and potential path forwards in spaces with considerable regulation. This may be a policy analysis of European antitrust, a legal assessment of digital payment laws in India or the financial analysis of a competitor. This requires expertise in the area you're researching (ex. a lawyer will need to investigate privacy law) to help shape product decisions in scrutinized spaces.
🗃 Internal Research (can be anyone, often the PM)
Find and catalogue the knowledge that teammates previously generated in the space. If you work at a large company, there’s likely a team that has attempted to solve similar problems. It avoids reinventing the wheel and can help you build off past knowledge.
💻 Engineering Research (engineers)
More technical projects may need engineering deep dives. This may include understanding CPU use on complex algorithms or finding problems in a recommendation system.
Each of these projects creates valuable product insights that can inform future roadmaps. But how can we prioritize these projects against features that move KPIs?
🌍 Prioritize discovery
Prioritizing problem discovery requires you to explicitly set aside part of the team's capacity for discovery.
Strong teams that I've observed mandate that 20% of the team’s capacity should go towards discovery. This varies across roles (ex. user researchers may spend 80% of their time researching while engineers spend 5%). Still, it’s healthy to create a culture of discovery where everyone is involved in the process.
By setting this mandate, you won't have to compare KPI-moving projects with discovery projects. Instead, you can compare projects within their respective categories.
This was my experience when I was the product manager for the Memorialization team at Facebook. Our main goal was to support the bereaved after the loss of a loved one. While team members each had ideas of what we could immediately do to address this challenge, we invested significantly in understanding the nuances of the space.
The team’s cross-cultural findings identified shared ideas of stewardship after death, how social connections form after a node in a social graph is dropped, and real testimonials from users who had experienced this grief. We used this knowledge to build features like the Tributes section of a profile where people could commemorate and share stories of their mutual connection.
Discovery projects can lead to a larger impact on long-term KPIs than normal projects because it focuses the team on solving the right problems.
Set a mandate that a certain percentage of your team's roadmap should go towards discovery projects. 20% is a good threshold for an ambiguous area.
Empower the cross-functional team (designers, researchers, lawyers etc.) to tackle the highest impact discovery projects.
Remember that the goal of a discovery project is to create actionable product insights. This prevents the projects from becoming too academic or fluffy.
🖼 Internet Things I’m Enjoying This Week
🧬 Technology Saves the World by Marc Andreesen: a fantastic essay on how coronavirus shows the world what is possible with technology.
🍿 The Carpool Critics Podcast: a new podcast I’m loving with movie nerds talking nerdy about movies. I listened to episodes on Avengers Endgame, Scott Pilgrim vs. the World and The Last Jedi.
🍀 Your Success Probably Didn’t Come From Merit Alone by Ezra Klein: a great conversation with Tressie McMillan Cottom about everything from “smartness” to the dangers of nostalgia.
If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.
Until next time,
Hey, Will! Thanks for sharing that :)
A sentence caught my attention
"But unfortunately, we don't spend enough time understanding the problem because it’s easier to build solutions that move our KPIs."
I agree with that, sometimes we forget the problems and the users just to move KPIs. When this happens I always try to take a step back to understand the situation
This resonates so much with my product journey wrapping up the 90 Days. Thanks for sharing, Will!