Discover
The first quarter of the Double Diamond model covers the start of the project. Designers try to look at the world in a fresh way, notice new things, and gather insights.
What you’re looking to do here is learn about the customer in their natural environment. Have you seen shows on Animal Planet where they go out and observe wildlife doing its
thing? This isn’t that different. It’s not the same thing as selling- you’re learning about what’s going to naturally resonate with a particular type of user/company, not testing your pitch. Watch what your customer does with your product when they get their hands on it. Instruct them as little as possible- remember, you’re using these customers as a sample to understand how a much larger population of users will react to what you have.
Four telltale signs you have a healthy Discovery process:
- “Product Savvy” Staff are Logging Observations with Customers
“Product savvy” doesn’t necessarily mean “technical” but it does mean the person in question understands your product well and at the same time can peel back customer feedback and questions beyond the obvious to discover what’s really at the heart of the user’s desire. (Pitch: Reading ‘Starting a Tech Business’ is a great way to get there!). - Those Same Staffs are Packaging Their Observations
These same staff should understand the basics of how to package their observations- describe a user, tell an agile user story, and provide vivid user-driven descriptions. On the high end, they have experience with usability testing. - You have Broad-Based Participation in Discovery
This is a core aspect of lean principles, all the way back to the Japanese concept of Kaizen. Training employees how to look beyond problems towards opportunities for improvement is an inexpensive way to improve performance. - You Have a Prioritized Hit List of What You Want to Learn
While you want to constantly be on the lookout for things you can learn about customers, you should also have a pretty specific list of things you validate that is tied to a) validating/invalidating what you just released and b) validating/invalidating what you’re planning in the next release.
Four telltale signs you do not have a healthy Discovery process:
- Development is Driven by What Breaks
You’re scheduling your development priorities around things that are broken or literal reactions to customer complaints (there’s nothing wrong with responding to customer complaints but there is something wrong with having individual customers design your product). - You Spend Time Pitching Customers and Cramming the Product into a Fit
Instead of observing customers and seeing what they want to do, you’re constantly pitching them the product and trying to cram what they want to do into the existing capabilities of the product. - You’re Quoting what Customers Say
Your customer discovery teams are spending time documenting exactly what customers said instead of analyzing what their statements really meant. Remember, it’s not your customers’ job to design your product and they’re not trained to think systematically about what they really want the product to do. - Your Backlog is Not Driven by Discovery
Your feature implementation priorities are being driven by someone who is not working for hand in glove with the customer-facing teams.