Why PMs struggle with product discovery

Product discovery is an inherently messy collaboration between people, processes, and tooling. Teams that excel at discovery each do so in their own way; discovery practices cannot easily be grafted from one team to another with a different context, even within the same organization. It’s a team sport with layered organization contexts (company culture, product culture, team culture, individual team members) and product contexts (product industry, audience, usage, area).

Beyond messy, it is an innately challenging activity that even the most experienced product teams can struggle with at times. That the success of a product/company can depend on its outcome only compounds the stakes for all involved. And for a PM at the center of both the discovery process and stakeholder management, it can all feel a bit overwhelming.

What's so difficult?

Insights - the fuel of product discovery

While a strategic context guides it, the primary input to the product discovery process are the insights at the team's disposal. The quality of those insights (both qualitative and quantitative), and the team's ability to synthesize them are directly correlated to the outcome.

How does a product team go about collecting those insights?

The struggle for qualitative insights

Today, it is rare for the value of quantitative insights to be called into question by the team or organization. Most organizations would like to consider themselves data-driven. More often than not, product teams find themselves struggling to reduce the scope of the quantitative data they're asked to focus on. They also generally have direct access to both collect and analyze the quantitative data they need for their discovery without cross-org coordination.

Qualitative insights are another matter entirely. For many teams, they require cross-org coordination with sales or marketing to collect, and their value directly or indirectly challenged:

• “We know that already – no need to waste time asking our users.”
• “Just ask our customer-facing teams – they know what our customers want.”
• “This outreach will interfere with our current marketing campaign”
• “Don’t we have a user research team for that?”

If this sounds familiar, you're not alone. Most product teams we've spoken with struggle much more collecting and understanding qualitative insights. Why is this the case?

A rose by another name

Most product managers have not come from user research backgrounds. That means when we talk about qualitative insights in the context of their product discovery process, it’s usually limited to insights from user interviews. Or for some teams, simply “speaking to users”.

The pitfalls of simply “speaking to users”

Let's walk through some of the different reasons something as simply “speaking to users” can be so agonizingly difficult:

Organizational acceptance

As mentioned earlier, some organizations believe they already know what their customers want and don't need to ask. They believe they have enough experts inside the company or that the input coming from sales is sufficient.

Example: Under the guise of “speeding up” discovery, a product team is encouraged to only interview internal SMEs and the sales team, as a proxy for users.

Formal knowledge

Product managers often don't have formal research training. If they haven't already learned on the job, they likely won't know how to ask questions or organize the research in a way that will help them get the answers they need. PMs who come from a research background (of which there is an increasing number), have an advantage here.

Example: Interviewing skills are often assumed for product managers. It is rare for those without experience to receive the training they need to interview effectively. Depending on their level of self-awareness, the PM is left to either self-educate or proceed ineffectively.

Misinterpretation of data

It is hard to avoid researcher bias when gathering qualitative insights as the interviewer's own preconceptions can influence the results they collect. Combined with the lack of formal research training (as above), this one can be especially challenging.

Example: A PM revisits their sparse interview notes from an earlier call, and inadvertently misrepresents a user insight while communicating to their team.

Inconsistency of data

There will always be inconsistencies between customer feedback gathered from different sources, so it is important to try and get a representative picture. Context reigns supreme when interpreting qualitative data, so understanding the interviewee and their personal/professional context is critical.

Example: In an attempt to consolidate feedback, a B2B PM incorrectly associates an insight from a recent user interview with a feature request submitted on behalf of the account’s champion by customer success.

Lack of data

Storing previously collected insights in a manner that is accessible to others, or even future selves, is a common problem for product teams. Most of the time there is insufficient (and insufficiently!) recorded qualitative data to leverage, so new data must be collected, requiring another round of participant recruitment.

Example: An org’s feedback system contains thousands of pieces of feedback and interview notes, but is not queryable in a way to answer the simplest of questions.

Participant recruitment

Recruiting people to participate in user interviews can be hard because it takes time and effort to find the right people. In the B2B case, account information is often central to selection criteria. Once the problem of finding the right users has been solved, it can also be difficult to get them interested enough to agree to an interview.

Example: A PM puts together a screener and configures their calendar with their interview availability, then asks the marketing department to send out an email blast only to realize they don’t know how many users they should contact, and don’t even have the right analytics to properly pre-screen.

And the list goes on…

Ticket to ride

Of all the pitfalls, there’s one that stands out: participant recruitment. Without a steady stream of user interviews with the right users, none of the other pitfalls matter. If insights are the fuel of product discovery, then automated participant recruitment is the rate of intake.

If we were to ask every product manager on the planet “how many users do you speak with during a regular week?”, what do you think we’d hear?

While unsettling, what we’ve heard most often is along the lines of:

• It depends on whether I’m actively in a 'discovery stage'”
• “Another team takes care of user research.”
• “None. It’s just way too painful at my company because of politics.”
• “Sales invites me in to speak to customers regularly, but the expectation is that I present or expedite their feature request.”
• “I'm too embarassed to answer that question”

That’s why we founded Orbital: to accelerate product discovery through automating user recruitment for product teams.

To conclude

If the outcome of product discovery is highly dependent on the quality of insights accessible to a product team, and if most PMs are struggling to collect direct qualitative insights through frequent user interviews, then something is wrong.

As organizations scale and empower more product teams, it is critical that those teams have the access and ability to collect direct user insights – including from first-hand user interviews.

Product discovery is at once incredibly challenging, equally rewarding, and also arguably the most valuable skill for a product manager and their product team to possess.