11 lesser-known mistakes PMs make during discovery
+ top 3 content pieces from the world of PM, PMM and AI
Hey BPL Fam,
The world is changing fast, isn’t it?
Twitter is now X, Meta rolled out Threads, Netflix is posting $900K salary AI Product jobs and NASA is launching it’s own streaming service.
But in this edition of Behind Product Lines, we’re keeping things simple. We will:
a quick poll on what topics you’d like me to cover next
take quick dive into the top content pieces that have been on my mind.
explore 13 mistakes that Product Managers continue to make during discovery.
Let’s go.
Lines of three: What’s been on my mind?
Product Lineup
After months of speculation about how AI will replace jobs, things are becoming real. Netflix published a $900K salary AI PM job that’s threatening the livelihoods of TV & movie writers/actors.
Tim Herbig succinctly explains how Product Managers can go from Product Strategy to Quarterly OKRs in 3 simple steps.
Lenny Rachitsky shared how Shopify’s product team has a framework called AAA to clarify responsibilities in projects.
AI Lineup
I’ve personally been using ChatGPT’s Code Interpreter to analyze my marketing funnel in amazing ways. But Chase Lean’s explanation of how it can be used to turn images into videos blew me away.
Till now, Midjourney was like a party trick that could generate interesting images. However, this tutorial-like carousel from Drew Bucker took the possibilities to a whole new level. Mind-blowing.
I’ve also wondered how much time video editors spent on putting up fancy captions for their cuts. Well, Submagic’s AI-powered captions will remove the need to delegate this altogether.
Marketing/Growth Lineup
I know how many marketers scratch their heads when it comes to devising a demand generation program. Stapho T has got you with this 10 step model.
You must have seen the phrase “Link in comments” a lot on LinkedIn. Rand Fishkin’s latest 5-minute whiteboard video digs into content creators are forced to do this and shares insights on a new paradigm: zero-click marketing.
Attribution and incrementality are popular but super tricky topics in marketing. Michael Kaminsky & Mark Taylor co-authored a stellar piece on Lenny’s newsletter to deep dive on the topic.
And in case you’re new, here’s what you missed in the last 2 editions of BPL:
11 Product Discovery Mistakes PMs learn the hard way (+ a Bonus)
Product discovery is critical for a PM’s execution stack because:
it’s a strong research tool to decide what opportunities to explore next
it offers validation of solution models & prototypes before code is written.
However, product discovery efforts can lose efficacy fairly easily.
Some symptoms that product discovery is missing the mark:
The product consistently fails to meet it’s engagement and retention goals.
Fresh features have low adoption and satisfaction rates.
Competitors start winning more deals because of product-related deficits.
You find yourself regularly pivoting on strategy due to low internal alignment.
Let’s dig deeper into some of the oversights PMs make in this endeavor.
Trigger Warning: Some of these might be hot takes for some. Proceed at your own risk.
PLANNING TO UP-SKILL ON DISCOVERY?
If you’re looking for some structured learning on the topic, consider looking into David Pereira’s course on the topic. David’s a highly seasoned product leader and acclaimed Product Coach and his course has recently been racking fab reviews.
Course Link:
https://maven.com/david-pereira/product-discovery-done-right
Bonus: David was gracious enough to give the BPL fam a 15% discount on the course. Use behindproductlines15 as the voucher code.
#1 Conducting discovery without building the culture to support it.
Many product organization still have a top-down culture. This means leadership arbitrarily sets the direction of the product and product teams are left disenfranchised from pursuing their initiatives. Several PMs complain about how their discovery efforts go in vain because there’s no executive buy-in or culture to support it.
In such scenarios, I recommend the following:
Divide and conquer: Find one person in the leadership team who you can influence. Educate them on what you’re attempting to accomplish and bring them along into a few customer calls. Advertise the benefits. With one champion on your corner, you can leverage them to start to convert others.
Educate the larger team on why discovery is important. This doesn’t just mean sharing videos and articles. Conduct a discovery effort against one product theme and float that as a document with insights that enlightens stakeholders.
Don’t stop discovery regardless. I’d recommend to continue to engage your consumers. At the very least, leverage discovery for solution validation, while the culture is cooking.
Spotify, Slack and Clickup are examples of the right culture for product discovery.
#2 Attempting discovery without a strategic vision
The common perception is that product discovery is an input to strategy. Sure.
But when you conduct product discovery without any strategic vision in place (conscious choices on where you’ll play in the market), you’re bound to:
you’ll ask questions that are all over the place
struggle to prioritize feedback received
fail to gather insights on what will deliver the highest impact for the product
Image credit: Productboard (originally adapted from Kevin on Code)
Ex: If a bank plans to strategizes to win the Gen Z market in their next 3 quarters, the PM needs to focus discovery efforts on learning about their unique financial management habits.
If you need help with building strategy, check out Gibson Biddle’s content on strategy.
#3 Working on discovery reactively
The average Product Manager conducts discovery as a reaction to a stimulus.
It could be peer or leadership pressure, desperation to validate a specific feature or some external inspiration.
The problem with this approach is Product Managers constantly stay behind the curve. We under-estimate how quickly our customer needs and the market is evolving.
I know it’s hard. Carving out time among all the chaos we’re going isn’t easy, especially when the team is lean and delivery is both applauded and incentivized.
To help with this, Teresa Torres’ book “Continuous Discovery Habits” sheds light on how to automate sourcing of customers.
Image Credit: Gerard Chiva (Activia Solutions)
#4 Talking to customers only
If you ignore talking to prospects and churned customers, you’ll have a one-dimensional view of the market.
Customers can only speak to the existing product and their current needs. Churned users, however, will spotlight the broken shards in your product that aren’t often talked about. High-fit prospects can share how they’re solving problems today and where alternatives perform well.
Sure, it’s hard enough to talk to customers, let alone find prospects and churned users. Thus, you need to create workflows that assist you. If you’re in B2B, joining relevant sales demos can give you an opportunity to probe mindsets of prospects and establishing incentivized exit interviews (or surveys) can get you in front of users that cancelled on you. Also, point #8 might help.
#5 Talking to EVERY kind of customer
This might be a hot take but “Talk to all your customers” is poor advice.
Not every existing customer is the best fit for your product vision. Some customers are poor-fit as their needs fall on a tangent to your ultimate vision. PMs need to have qualifying filters in place to quickly identify them. Otherwise, the dispersion in ideas can be chaotic.
For example, while building a recruitment software, we wanted to focus on serving HR departments of large corporations. Every now and then, we’d bump into recruitment agencies that were using our product. Their needs were wildly different and while the cohort had potential, our product strategy mandated us to serve the needs of enterprise organizations. Thus, talking to agencies was counter-productive at times.
Know your target audience.
#6 Failing to frame the problem correctly
This is where asking the right questions becomes critical. If you don’t get to the job to be done, you’ll frame the problem incorrectly and in turn, you’ll swim in the wrong solution space.
For example, HR personnel that used to use our recruitment product often asked for enhancements on our reporting module. In our discovery calls, several would cite the need for different visualizations on the dashboard.
In response, we decided we’d create a super powerful reporting engine allowing them to generate any report. The endeavor was going to take months to build.
However, taking a leaf from the 5-Whys method, we dug deeper.
We learnt many were taking screenshots of our dashboard and putting them into their presentations and Excel sheets. They didn’t need new reporting views. They needed striking visuals to explain their recruitment efficiency to leadership.
The original problem frame was: “How do we enable recruiters to generate any kind of reporting view they want?”
The reframed problem was: “How do we enable recruiters to tailor the visualizations of existing reports?”
PMs need to be careful with what trajectory they take.
Here’s another example for reference:
#7 Being over-sensitive to intriguing feedback
Every now and then, you’ll come across customer feedback that’ll raise an eyebrow. It’ll feel exciting, anomalous and like a secret that was hiding in a tomb.
This creates a buzz in a product team and they jump straight to solution mode.
It’s important to isolate emotion from the feedback received. Anecdotal feedback, although not irrelevant, needs to be taken with a grain of salt and cross-validated.
I made this mistake with an auto classifieds platform I worked for.
I was interviewing one of the elite auto dealers in town. He told me about a problem that “every” dealer faces. They’d get several phone calls from potential leads who would place offers. However, dealers weren’t writing these down and there was no easy way to follow up. They needed an offer repository.
It sounded like fascinating advice. As a young PM, I jumped on solutionizing.
The solution bombed.
We eventually discovered that while dealers did receive a lot of calls, most were able to sell off their cars to walk-ins as foot traffic was high. Moreover, none were savvy enough to even understand a CRM.
When you receive seemingly surprising intel, pause and think. Find out if the problem scales.
#8 Limiting discovery to live interactions
When we talk about “discovery”, PMs think in-person interviews and Zoom calls.
But that’s no longer the only way. You can supplement that activity with other evidence areas. I mean, there are several conduits to explore:
In the B2B world especially, tools like Gong record all your sales and customer success calls in one place. It allows PMs like me to hop on and search transcripts of these calls. I’m able to mine a lot of golden insights from prospects, churned customers as they’re exiting and active customers - all by searching by keywords.
In fact, AI products like Otter.ai go one step further by allowing you to prompt a chatbot to retrieve those insights instantly. It’s only going to get better.
The reality is that PMs can’t take every call. Therefore, leveraging technologies that consolidate evidence pools will enable them to cover a larger surface area.
#9 Not spending enough time distilling information
This point probably deserves it’s own post.
Talking to customers and gathering data is the easy part.
Distilling that information into actionable insights? Not so much.
Here’s where most Product Managers struggle. A workflow to process the intel received from a customer is almost non-existent in product teams.
Here’s what a sample workflow can look like this:
Consolidate customer problems in a Google sheet.
For each point, log the frequency and intensity of occurrence.
Log customer meta-data like segment, subscription tier, tenure as well.
Tag each point with a theme.
Group the themes together and mark out patterns.
Identify outliers and anomalous feedback and set them aside for further probing.
Cross-match these findings with analytics where applicable.
Prioritize the problems in each theme. Prioritize the themes too based on strategy.
Develop a hypothesis. Aim to validate via prototypes.
It takes a systematic effort to juice out something actionable from customer interviews.
I also like Petra Wille’s idea board solution:
#10 Using discovery to market the solution
There’s a tendency in Product Managers to mix discovery with evangelizing their solution.
Discovery of problems needs to be solution-agnostic. If you follow up a discovery question with leading questions that relate to your solution, you’re biasing their responses.
A classic example of this is:
“How often do you face (said problem) in your daily work?”
(customer answers)
“Great. Do you think if you had a (solution capability), that would reduce your (problem)?”
The challenge here is that you’ll almost always hear a “Yes” because of the shiny object syndrome.
Stop mixing discovery with marketing.
#11 Using discovery to explore just function and not messaging
This may not be a grave mistake as much as it’s a missed opportunity.
While messaging is thought to a be a Product Marketer’s concern, a Product Manager can learn a lot by learning how customer describe their problem. That same verbiage can be used in further discovery endeavors.
Similarly, when you’re validating your prototype with them, the way customers articular the benefits can be important clues to even arrive at your actual value proposition.
For example, assume you’re a PM of Calendly. You may hypothesize that enterprise teams have trouble “manually coordinating meeting schedules and resolving conflicts”.
That’s how you describe it.
However, when you interview customers, they may describe it as:
“Oh my. It is a huge headache, trying to align calendars with multiple team members across different time zones. We were constantly sending back and forth emails just to find a time slot that works for everyone.”
See the difference? “Calendars”, “Time zones”, “back and forth”, “time slot that works for everyone” - these give you clues as to how you can work with the product marketing team to position solutions better.
Bonus: Failing to articulate & democratize discovery findings
Product Managers often attempt to conduct discovery as lone rangers. In many cases, the only time other team members hear about what was found from discovery activities is in a verbal kickoff session or a detailed PRD.
PMs need to document their findings in one place and then circulate insights. Even a 1-pager around what they’ve found or an update in a townhall or team huddle can be useful.
Here’s Farbod Saraf from Miro:
It’s bad enough not to involve your engineering and design teams in discovery efforts (topic for another day). But if you’re not sharing and making your findings public with the team, you’re doing yourself a disservice.
Conclusion
The process of discovery goes well beyond data collection and input from users.
It is part art, part science and it’s a thoroughly iterative process of understanding your audience. It involves getting better at problems correctly and most importantly distilling information into actionable insights.
I’m not saying avoiding these mistakes are easy. It might seem like a lot to work with. A lot depends on the culture of the organization. However, the more your practice in culling your biases, the more the process will become second-nature to you.
Stay cool, BPL Fam.
Till next time,
Aatir
Such a great post. And definitely triggered. In part because like I'm assuming happens to many of us - you really want to feel like you're doing work for good/doing the right thing but you just don't have the support system or reside on a product team that is ready to build on your findings.
As mentioned, I have taken the "don't stop discovering" approach. If anything, you really get to build up your knowledge and can speak to problems of your users in any scenario which helps with trust across the org.
I've experienced mistake #10. It still evokes recurring guilt trips. It was related to scheduled booking feature in the mobility industry. We didn't research deep enough to understand that customers weren't looking at scheduling as a feature for convenience; rather they were assuming that "scheduling = an assured ride".
The conversation was something similar to the example given in the post. "Do you think you'll scheduled booking to plan your day better? Makes your life convenient?" "Yes!"
Loved the post.
(Small typo in that #10 paragraph. Here vs hear*)