Directed discovery: why your product team needs it

Learn something new. Take control of your career.

Sign up

Today, right now, how is your product development team operating? Are they working in waterfall? Is your team given an idea and then told to execute on it? Probably. But that’s not the way product development works anymore—or at least it shouldn’t. Allow me to enlighten you. There’s a whole new way of developing products, and it’s called directed discovery.

What is “directed discovery?”

Directed discovery is our version of how we work every single day, and it puts the user at the center of everything we do. We use ethnographic techniques, which means we try to understand how people live their lives and interact with our product from their point of view, not ours.

Using these techniques, we spend a lot of time with users. Because to solve problems for customers, you actually have to know what the customer is doing—but customers aren’t going to tell you how to build something; they tell you how they use something. So, we have conversations. We ask them questions. We ask them about their day. We ask them what they do. We listen. And we take what they say to heart.

We’re not looking to hit a requirement. We’re not looking to build a feature. We’re looking to try to build an experience that almost perfectly lands in the way that the user’s daily fabric is woven. So we have to find these really natural points to intersect with their daily life in order to build a quality product.

And it’s here that we’re able to comb through all of this genuine customer feedback during four different phases. We then collect all of those qualitative responses from voice of customer sessions to customer confirmation testing to define the next path forward. A deep review of quantitative data is also needed once the product has hit the streets at scale. So, where do we start? Let’s dive into the four phases that make up directed discovery.

4 phases of directed discovery

**VOC: Voice of the customer
**As our first phase, VOC is all about exploration. We interview our users around ideas we have. It’s a way to explore what they’re looking for or how they think something should work. We ask four specific questions in this phase, and we’re very careful not to guide the user to answer a certain way:
    1. What do you think about this feature? Does it solve a problem?
    2. What should it do?
    3. What it’s competing with? (Not just other products, but your time, interest,     etc.)
    4. How do you want to be made aware this feature exists?

**CPT: Customer preference testing
**In the second phase of directed discovery, we present designs to the user that we built from the customer narratives. However, they’re wire frames, which are high fidelity comps or mocks since we’ve learned we can move a lot faster and change things a lot easier. This phase is all about the customer: What do they think about the page in front of them? If they ask us a question, we throw it right back at them so we get raw, authentic feedback. These conversations are less structured than VOC calls and we come prepared with a handful of items, not necessarily a list of set questions. First call and last call are completely different because topics evolve as the product does.

**CCT: Customer confirmation testing
**The third part of directed discovery is about measuring qualitative and quantitative customer data. Here is where we get validation on our more concrete designs and features.

**Launch: Full product deployment
**And as final phase, we release alpha and beta versions of features. But, we still continue review customer data and adapt the product and its features continuously.  There is this process of continuous discovery and continuous delivery, which creates dual track product development instead of just this silo waterfall process dictated from the top down.

Directed discovery & your product development team

It’s important to note that directed discovery does not replace user experience design, which embodies much different techniques. But instead, couples itself even tighter to product processes, such as task flow diagrams, journey maps, hot spots drills and user story mapping practices. This also includes our development teams at a very significant level. We don’t think of development and product as different groups sitting on the opposite sides of an aisle. Developers are all part of the ethnographic research with product experience manager (PXM) and UX design in daily work—or they should be.

So how can you get your team on board with directed discovery? Start by building product teams around experiences, not features. In my last post, I went into detail about how to do just this, and how to create a product experience team or PXT. Essentially, if you’re using directed discovery, your product development team should evolve into a product experience team.

So now, with a PXT who operates using directed discovery, 85% of that work is research and using those ethnographic tools. You and your product team should strive to put an empathy of enjoyment around the different experiences you deliver through your product. How much happiness, gratification and satisfaction does it bring your customers? Those are the things that are really meaningful. And until you interview a series of folks to find out and dive deep into research, you don’t know. Your product team only finds those oh-so-natural points once they become discovery driven. So, what are you waiting for? Go discover.

Learn more about directed discovery by joining our discussion on Slack here, or hear one of our cross-functional teams talk in-depth about user-centered design in this video.