Product Leaders: Getting Teams Started with Product Discovery
“Start somewhere, anywhere.”
The first Product Discovery effort for a team doesn’t have to be perfect.
It’s a stepping stone to getting better.
Product leaders don’t have to be experts in Product Discovery to get their teams started doing Product Discovery.
Use these guidelines to get your teams started doing Product Discovery today:
Timebox Product Discovery
Pick a small concept
Buy them time
Help them recruit users
Hold just a few concepts sacred and nothing else
Scrutinize their learnings
Reflect on the process
Leading without having the answers
Timebox Product Discovery
Strive for velocity, not perfection.
A team’s first discovery cycle should be short.
Optimize for “time to customer contact,” not pixel perfect prototypes or perfect interview scripts.
But don’t rush it and jump into a design sprint that finishes in 4 or 5 days.
Design sprints are useful but too disruptive to be a repeatable practice.
Try to finish the first cycle within 21 days… fast enough and at a more sustainable pace.
I regularly coach teams that are new to Product Discovery to complete their first cycle within 21 days.
Pick a small concept
Pick a smaller feature that needs to be derisked and get started.
The team must genuinely not know the answer before they start.
Examples of small but risky concepts:
Instead of testing an entire ecommerce experience, test variations on one step in the flow (e.g., Add to Cart)
Instead of testing an entire analytics dashboard, test variations around one data visualization
Instead of testing a one-size-fits-all chatbot, pick a specific use case used in human-to-human chats and try to automate it
Buy them time
The first Discovery cycle or two will likely disrupt the flow of shovel-ready tasks that the Product team has been creating for the engineers.
So while teams get good at doing Discovery and Delivery at the same time…
…is there technical debt the engineers can work on?
…are there performance improvements which don’t require a lot of Product and Design involvement?
Over time, teams will create a deeper backlog of Discovery-validated ideas that keep the engineering flow going while they are working in the non-linear world of customer feedback.
Help them recruit users
It’s hard enough putting all the pieces of Discovery together.
Then add the messy process of finding and scheduling outsiders to be your user testers.
Recruiting users always takes longer than teams think.
Push them to start recruiting immediately and ask for day to day status.
As a leader, you may need to do the following:
Find budget dollars to support recruiting fees and incentive fees
Convince reluctant stakeholders to allow access to users (usually Sales and Marketing)
Personally introduce teams to potential users in your network of client contacts
Personally introduce teams to internal colleagues that can find users for them
Allocate time for someone (not on the team) to coordinate, schedule (and reschedule) user interviews
Contract an online self-service recruiting agency
Contract a high-touch full service recruiting agency
Read my advice on how to recruit users.
"Pick your battles"
The initial Product Discovery cycles for any team are learning opportunities for the process, not just the product.
Every successful team has to practice.
Every successful team has a coach who figures out what advice to give at which moment. You can be that coach.
Use the tips and techniques below to guide the adoption of Product Discovery within your teams.
Hold just a few concepts sacred and nothing else
If you criticize every aspect of their process, it will slow them down.
Getting good at Product Discovery takes repetition.
These are the bare minimum principles to focus on for giving direction to teams that are new to Product Discovery:
Pick a small concept so they can finish quickly
Start recruiting immediately to avoid the predictable hurdles
Prepare multiple solution options for the interview to force the team to be more innovative and give the customer a compare and contrast moment
Put the solution options into an interactive format (usually a clickable prototype)
Limit the prototype to a “happy path” (saves prototype production time)
During the interview, the customer should control the experiment (send them the link… have them share their screen)
Talk to at least 5 users (you will have to schedule 6 users to get 5 to show up)
Ask each user the same survey question to be clear which option they prefer
After you’re finished, do a retrospective on the Discovery process itself
Scrutinize their learnings
As a leader, you need to coach your team to get better.
Even if you don’t know their exact process and aren’t intimately familiar with the product itself, you can guide them.
Start by scrutinizing their learnings.
This prevents them from just going through the motions of Product Discovery.
What have they learned that they didn’t know before they started?
What changes will they make to the product as a result of customer feedback?
Do they report these narrow learnings:
Changing placement of buttons/call to actions
Tweaking copyediting
Different color preferences
Or do they have deeper learnings:
The flow of the experience is flawed
Interviewed a non-customer (e.g., talked to a buyer and not an end user)
Targeted the wrong end user (e.g., product would be better used by someone else)
The problem is much less painful that previously thought
If they have mostly narrow learnings, they likely didn’t take enough risks in their experiment.
They may have settled for getting usability feedback and stopped short of asking harder questions.
Read more about creating a high quality design experiment.
Reflect on the process
Learning happens with failure and repetition.
Teams that proactively make time to honestly reflect on their recent experience learn faster.
Require your teams to meet and do a retrospective within one week of finishing their Product Discovery cycle.
Use this simple Product Discovery retrospective template. (The silly graphics make it fun.)
Leading without having the answers
Without being an expert at Product Discovery, a Product Leader can still facilitate their teams into getting started with Product Discovery.
Create the time and space to learn Discovery knowing that they won’t get it right the first time.
Focus on teams getting better, not being perfect.
Don’t wait for the “right” time to get teams started with Product Discovery.
We expect discovery to eventually be an everyday part of a product team’s work.
After the first few Discovery cycles, they will be able to conduct both Discovery and Delivery during every development phase.
At some point, you may get frustrated with their progress or with a company culture that works against Product Discovery.
That’s a great time to reach out to an external coach like myself to accelerate the team's skill development and jumpstart organizational culture change.
Jim coaches Product Management organizations in startups, scale ups and Fortune 100s.
He's a Silicon Valley entrepreneur with over two decades of experience including an IPO ($450 million) and a buyout ($168 million). These days, he coaches Product leaders and teams to find product-market fit and accelerate growth across a variety of industries and business models.
Jim graduated from Stanford University with a BS in Computer Science and currently lectures at UC Berkeley in Product Management.
