Wend

Why Most Product Managers Don’t Actively Do Product Discovery

Beau Blinder

Product discovery is a lot like flossing.

It’s something we all know we should be doing more of, but we continuously find excuses and reasons to avoid it – Both are habits which are difficult to form, very easy to break, and often uncomfortable to engage in. The reality though is that teams who regularly engage in customer discovery build better, more valuable, and more customer-centric products than teams who don’t.

So let’s look at the three biggest reasons most product managers avoid discovery.

Reason #1: “I know what I’m building”

There are all sorts of ways teams can fall into this trap.

Maybe you’re working on an idea that has bounced around your company for years. Maybe you did a ton of research six months ago. Maybe you just wrapped up 15 customer conversations and feel great about the direction you’re going. That’s all fair, but the truth is you can always know more about what your building and that a good discovery process not only mitigates up front risk, but it mitigates ongoing risk to the project.

Establishing multiple weekly customer calls means that you have a forum nearly every day (or every other day) to test something. One day it could be the mockups and user flow, but the next it could be live code. These types of interactions not only help build the team’s confidence in what they’re executing on, but they provide opportunities for small fine-tuning adjustments. Maybe that navigation pattern you’re using turns out to be confusing or the text you chose isn’t quite clear enough.

Reason #2: “We’ve done discovery, now we’re executing”

There’s no better time to be engaged in discovery than when the team is heads down on building a feature.

That’s because you can’t immediately jump from having an idea to executing on it and expect to have a successful outcome. Instead, each idea needs to be explored to determine if a usable solution exists, if you can build that solution, if the business can support that solution, and if customers will actually find that solution valuable. And there’s no better time to ask those questions than when the team is heads-down executing.

You should expect that only 20% of your ideas become something actionable, with the remainder being scrapped due to lack of viability, usability, or value. That means that in order to maintain a healthy backlog, you need to be doing a lot of discovery, asking a lot of questions, and testing/validating a lot of ideas. And that assumes that you have a single thread of execution and can get buy-in on the one path you’ve outlined.

In reality, you’ll need to explore a wide variety of areas in order to determine the correct path forward. For instance, your organization may be debating two new paths to revenue. Your input on what a set of solutions along each of those paths is invaluable in that it will help your stakeholders understand the cost, timing, and likelihood of success.

So, while your team is executing, your job is to get way out ahead of them and figure out not just the next project, but the three other potential projects / paths you could be taking!

Reason #3: “I’m busy! I don’t have time to talk to customers”

Of all the things PMs do, ongoing discovery is by far the most important.

Ensuring that you or your team is capturing signal from customers, stakeholders, and coworkers is the foundation of every great product manager and product decision. This signal can be anything from a one hour interview to a slack message or email about a product feature. This data, when managed and groomed properly not only serves as a jumping off point for conducting deeper discovery dives, but it also is the justification for why the company should invest in Project X over Project Y. It underpins the tactical and strategic decisions your team makes.

In other words, it’s a lot more important than most of the other activities you engage in. The challenge is that while discovery is important, it is not urgent. The product won’t fall over if you fail to have customer calls for a few weeks. You won’t miss sales numbers or even necessarily ship bad products, but at some point in the not-so-near future you’ll feel the anxiety of your team wrapping up a project with no clearly defined, clearly justified, and valuable “next” project. Instead, you’ll scramble, come up with a few ideas to keep the team busy and be constantly wondering if you did the right thing.