A simple guide to the product discovery process
Product discovery is one of my favorite product management activities! I love every aspect of it and think it’s the best process for figuring out the right products and features to build.
Follow this simple guide to product discovery and make a tremendous positive impact on your company’s business.
Step 1 — Empathize
The first step in effective product discovery is empathizing with your users and customers. I distinguish between the two because customers may be paying for your product but not necessarily using it. And vice versa. It’s important to consider both constituents when conducting the discovery process.
This important step in the process is one that a lot of product teams overlook. To empathize with your customers, you need to put yourself in their shoes. Get to know them and understand what their challenges and joys are by talking to them. If you can visit them in person, that’s the best way. Thankfully, it’s easy to also interview users via video chat tools like Zoom and Google Hangouts.
Before you meet with your customers, though, create a script that includes the purpose for your visit along with a list of questions that you will ask each and every one. It’s important to do this so that you can establish a solid baseline for understanding what’s working for them today and what their problems are. Identifying patterns and trends in these problems is how you will succeed in the next step. Before we move on, though, it’s important to stress that you should be talking to your customers and users at least once a week. This shouldn’t be a one-time activity, but rather a continuous process.
Step 2 — Hypothesize
Now that you’ve talked to your users, you probably will see trends quickly emerge. In my experience, it doesn’t take too many customer visits for patterns to emerge. Before jumping into solution mode, though, it’s critical to formulate a number of hypotheses based on the data you’ve gathered.
What does a hypothesis look like? I’m going to use a hypothetical (no pun intended!) example. Let’s say you’re a product manager for the Domino’s Pizza app and you’ve talked to several customers.
You realize that the majority of them are not completing their order with the app and, instead, are placing an order by phone. You could then look at your app data to see where people are dropping off to formulate a hypothesis such as “If the app made it easier to see what specials and coupons are available, more people would place an order within the app.”
Before moving on to the next step, you should prioritize your list of hypotheses so that you can focus on the most important one. Once you’ve determined the hypothesis you think could have the biggest impact, it’s time for step 3.
Step 3 — Ideate
Do your engineers or marketing peers ever complain that they don’t get to come up with ideas for what products, features or services to build? This is the perfect time to get them involved. Actually, if possible, you should include them in the previous phases, too, but that is often not feasible for development teams that are in “delivery mode” (more on that in a future post!). Teresa Torres recently wrote a great article about why engineers should participate in the discovery process and it’s a good read.
Schedule a half-day meeting, call it a workshop for bonus points, and invite a member from each of the functions that are involved in bringing your product to market (marketing, design, engineering, customer support are good starting points) and you may just find that the energy produced from everyone working together could light up a room.
The goal of rapid ideation is to quickly identify a number of solutions that would allow you to test your hypotheses.
I’ve done this exercise with teams before and we’ve timeboxed the entire process at 90 minutes. You can do this quickly. There’s no excuse not to be using rapid ideation on a weekly basis with your teams!
Here’s how to ideate rapidly:
- Break out and work individually at this point to generate the most ideas.
- Give everyone some post-its and colorful sharpies and have them start writing or sketching ideas, one per post-it note. I prefer to use extreme post-it notes because I’ve found that the basic ones don’t always stick to whiteboards and you could come back the next day to a pile of post-its on the floor.
- Limit the amount of time to this activity to a short period like 10 minutes.
I find it’s useful to have a simple, visual timer available that everyone can see that they know how much time is left. - Have everyone cluster their post-its on a whiteboard. There will inevitably be some duplication and overlap… this is good. Great minds often think alike!
- Give everyone colored dots (no more than 3) and have them vote on which idea resonates based on the likelihood for proving your hypothesis.
- Select the idea with the most dots. If there’s a tie, this is where you can use your product management experience and instincts to select the one you think is the best.
- Make a list of the ideas, especially the top ones so that you can come back to them later.
You’re now ready to prototype based on that top idea.
Step 4 — Prototype
Based on your hypothesis, what is the simplest, quickest prototype you can create to validate your idea? It could be as simple as a sketch on a piece of paper. It might be a black and white digital image you can show customers on their phone. It could be a low-fidelity prototype using a tool such as Balsamiq or Proto.io.
It should be something you can literally throw out when you’re done testing it. In other words, it should not be something written in code that could be tweaked over time. This is to prevent teams from becoming too attached to their ideas. A big mistake teams often make is continuing to invest in something once it’s created even if it didn’t test well (or, even worse, wasn’t tested at all)!
You or someone on your team should be able to create a prototype in less than a day. If they’re taking longer than that, they are likely getting bogged down in details that can be figured out later.
Step 5 — Test
Validating your prototype is also something you should be able to do in a day. Find a few target users and have them attempt to use it. If it’s a paper-based mock-up, ask them to tell you what they would tap on, what information they would need to be able to perform their job, etc. Collect feedback on your prototype, from usability issues to whether or not the prototype helps them do their job easier. Find out what’s working and what’s not working and then go back to the drawing board to refine your hypothesis until you’ve reached the desired outcome. You can do this by tweaking the original prototype or you can take one of the other solutions from your ideation phase and mock that up for testing.
Ultimately, you should be working towards the smallest, shippable “thing” that achieves the desired outcome. From here, I encourage you to create a small backlog, not of features, but of hypotheses you’d like to explore and experiment with. Developing an experimental mindset that focuses on delivering upon outcomes and not features is the key to having the most impact on making your customers happy (as well as growing your company’s business).
Have you tried using the discovery process before? Have questions about how to do this? Get in touch. I’d love to hear from you!
* Before I came up with the hypothetical Domino’s Pizza example to show what a hypothesis is, I had no idea there was a company that had done work for Domino’s to improve their user experience for coupons and specials. Credit to Appinventiv for the mock-up shown above.
Originally published at jonihoadley.com on January 13, 2019.
