The Rise of Modern Product Discovery

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

I love that Marty Cagan and Jeff Patton have long been advocates of dual-track development. Their efforts have helped to shape the ongoing conversation about the evolution of product discovery.

If you aren’t familiar with dual-track development, it’s the separation of product discovery from product delivery.

Cagan defines discovery as “figuring out what to build” and delivery as “then building it.” – Tweet This

Obviously, both are required to ship a product.

Delivery, in particular, has matured over the past fifteen years.

The adoption of Agile has helped us deliver iterative chunks of code rather than waiting for the big reveal at the end of a long project.

Agile rituals like daily stand-ups help us remove obstacles in the development path, increasing our velocity, and reducing our time to ship.

Continuous integration reduces the risk of large code conflicts that used to take days or sometimes weeks of testing to resolve. Continuous deployment allows us to deliver value to our customers faster.

User stories and user story mapping help a team align around the top priorities and get clarity around what they are delivering.

Strong delivery practices are spreading throughout the industry.

Even teams that are struggling to adopt these practices have a clear picture of what good delivery looks like. They may struggle to get there, but the target is clear.

Challenges with Product Discovery

Product discovery, on the other hand, has been much slower to mature.

We have seen a rise in product discovery philosophies—the increase in popularity of customer development, design thinking, The Lean Startup, and so forth. Each of these are designed to help us decide what to build.

But the adoption of the associated practices has been slow and uneven. Even  the teams who are trying to put these philosophies into practice are bumping up against challenges with the nuts and bolts of how these philosophies are executed.

There isn’t a clear picture of what good discovery looks like. It’s still evolving. – Tweet This

Although I do love these two examples:

• Tom Chi on Rapid Prototyping at Mind the Product
• Nordstrom Innovation Lab: Sunglass iPad App Case Study

Despite a shortage of examples, modern discovery practices have developed further than where most teams operate. – Tweet This

These practices simply aren’t being adopted. Or, as we will see, aren’t being adopted well.

The Traditional Way of Doing Product Discovery

For many companies the traditional way of doing product discovery is some variation of the following:

• A long list of ideas, initiatives, or projects is collected from either senior leadership and/or throughout the organization

• A group of people (sometimes senior leadership, sometimes a budget oversight committee, sometimes a product team) prioritizes and funds those ideas, initiatives, or projects

• Funded projects get assigned resources and a product manager starts gathering requirements

• The product manager interviews key stakeholders to understand what they need, documenting what they find

• The requirements go to engineering for delivery

The Limitations of the Traditional Product Discovery

This worked reasonably well when the role technology played within an organization was to service the business. The focus was on building internal tools that supported the day-to-day of running the business. The business was the customer.

I say reasonably well because there were still problems. Miscommunication led to delays. Requirements changed throughout the project leading to scope creep. Technology teams did little to test their assumptions about what the business needed, which resulted in solutions that didn’t quite work. Deadlines were missed. Quality was a challenge.

These challenges arose from faulty assumptions throughout the process.

First, we assumed that software initiatives were simple and could be directed by non-technologists.

Software projects were (and in some cases still are) defined and farmed out to software teams by business stakeholders with little knowledge of the medium.

In the best of cases, we let the customer dictate the solution, and in the worst, we built solutions that matched the business leaders’ perception of the customer’s challenges rather than solutions that matched the customer’s actual challenges.

In short, we were business-centered, not customer-centered.

Second, we assumed that we could predict the future. We kicked off each year and each quarter committing to features and delivery dates, assuming that software development was a predictable process.

Third, we assumed our future was certain. We were certain that our projects would have the intended impact and that nothing would go wrong.

History has shown us that all three assumptions were (and still are) wrong.

The Internet industry has pushed the limits of traditional product discovery. – Tweet This

As the customer moved beyond the walls of our own business, we quickly learned that these limitations flourished. Our deadlines got pushed further and further out. Our businesses lost faith in our ability to deliver. Our customers were frustrated and confused by our products.

This is why we see the best Internet companies developing completely new ways of working.

The Assumptions Behind Modern Product Discovery

We see a new form of product discovery emerging with the rise of design thinking, The Lean Startup, customer development, and the jobs-to-be-done framework.

Modern product discovery philosophies come with a different set of assumptions. – Tweet This

They assume that the focus should be on the customer’s needs and not just on the needs of the business.

They assume that our initial ideas, initiatives, or products will be wrong.

They acknowledge that we need a deep understanding of our customers and that we need to invite them to participate with us in the creation of our solutions.

They assume that we need to iteratively test our ideas and that we should only invest further as the data coming back warrants.

And finally, they assume that the only way to test our ideas is to give our customers something to experience—this might mean a prototype to play with or a concierge-style experiment to experience. It doesn’t mean simply asking them what they want.

And these philosophies come with a new suite of tools to help us put their perspectives in practice. They include A/B testing, usability testing, customer development interviews, participatory design, and field observations, to name a few.

The Challenges with Adopting the Practices Without Adopting the Underlying Assumptions

What I see happen over and over again is product teams read about these tools and try to adopt them. But they don’t do the required work to adopt the new assumptions.

They still assume the future is predictable developing feature-based roadmaps rather than using themes, opportunity backlogs, or goal-driven roadmaps.

They still assume that their idea will work. This means they charge ahead with development and only test it with an A/B test after it’s gone live. They learn after all the hard work has been done that it didn’t work.

They still assume that the business knows best about the user needs and only run usability studies when business stakeholders disagree.

They listen to what customers say rather than watching what customers do. So they transition from generating their list of ideas within the building, to generating it from a list of feature requests, rather than experimenting their way to viable solutions.

They feel the need to time-box discovery for two reasons. First, it doesn’t feel like real work—only writing code is real work. And second, they are still assuming they can predict the future by marking a date on the calendar when insights will be gleaned.

And finally, they wrestle with how to maintain authority while giving their teams autonomy to discover and deliver the right product. This struggle is between the prescriptive control of the traditional method vs. the emergent strategy of the more modern method.

The challenge is that these new assumptions are so foreign to us. They are foreign to the world of business.

It’s hard to imagine a world where we assume we are wrong, co-create with our customers, and iteratively test our solutions. It’s hard to imagine in such a world that we still add value as product managers.

For many of us, we tie our worth to our latest great idea. This new method requires that we tie our worth to the practices that we adopt and execute.

Are You Already Doing Modern Product Discovery?

Or maybe it’s not hard to imagine.

Some of you are reading this and thinking you have already adopted this more modern way of doing discovery.

But without clear examples to compare yourself to, it’s hard to really know.

I can tell you that I’ve met many teams who are adopting the tools, but not adopting the new assumptions. It means they are getting a fraction of the value.

Here are some questions you can ask yourself about the way that you work to assess where you are with product discovery.

Do you have a roadmap that lists features and dates?

If the answer is yes, you are (or your organization is) still assuming the future is predictable.

Start comparing what you actually did to what you said you did. It might feel like you are hitting your commitments, but you’ll be surprised at how often you miss when you are diligent about tracking it.

And frankly, our goal shouldn’t be to hit our commitments. It should be to deliver value. If we learn that an idea isn’t working, we should have the freedom to scrap it and move on to the next best thing. Fixed feature lists don’t allow us to do that with ease.

Is your only idea of an experiment an A/B test that acts as a gate on release?

This isn’t an experiment. This is a measure of impact. It’s valuable, but it pushes the learning too late in the process—after you’ve done all the work.

Or a usability test?

Usability tests are great. But usability isn’t the only risk with our ideas. We also need to test whether our customer cares about the value proposition, whether the feature we’ve developed (and its design) delivers on that value proposition, and whether or not it’s technically feasible.

How often do you co-create with your customers?

The best teams do this every week. See Tom’s video above—his teams did it twice a week. It raises the bar, doesn’t it?

When was the last time you scrapped an idea, initiative, or project because you learned through experimentation it wasn’t going to have the expected impact?

If the answer is never, there is no chance you are doing modern discovery. If the answer is more than a month ago, then you aren’t doing continuous discovery. The best teams are exploring many ideas on an ongoing basis, few of which end up worthy of pursuing.

Readjust your time frames. Ask yourself, what can I learn today? What can I learn this week? Move fast and learn things. – Tweet This

Regardless of where you are, my goal is not to criticize how you are working. This work is hard.

My goal is to paint a clear picture of what good product discovery looks like. I don’t pretend to have all the answers, but I’m excited to explore this question. Want to follow along? Subscribe to the Product Talk mailing list.