A product detective diary: how to discover the right product
Who else loves thriller TV shows? Those in which a detective investigates a murder while observing a big wall full with pictures, pins and connecting lines. This board is called an evidence board.
Detectives usually base their investigations on them. Using scientific models such as hypothesis validation to start connecting dots, to see what’s missing and what doesn’t fit where, all in order to come up with a prime suspect.
When discovering our product, we can think of a similar approach. A product detective, but instead of a suspect, we will be looking for the riskiest assumptions to test, and learn from them. The process is quite similar. We will be setting our hypotheses as part of our investigation, and produce experiments to test and learn fast. That way we will discover a product that will be used.
Two weeks ago I attended one of Jeff Patton’s workshops, in which Jeff mentioned the evidence board approach for product discovery. I immediately felt in love with that approach, because it is not only interesting but it is FUN! And it is easy to generate a buy-in too, because everyone has seen these kinds of cork boards before. I had the chance to implement it, and I must say you kinda feel like you’re in a sherlock holmes scene.
How to generate the buy-in
So, once I had the idea, I put together an evidence board following Jeff’s instructions in a collaboration tool (Miro or Mural can be used). Then, once it was all in place, I contacted my product team to generate the internal buy-in. This is a process that should be executed as a product team, not by yourself, because it may include the effort of different cross-functional roles (such as product designers or engineers) working together pursuing the same goal, to hunt the riskiest assumption. BAM!
Everyone loves stories. So, a good technique to generate the external buy-in could be to get people comfortable thinking about non-related work. — Why not drive them to the most comfortable moment of their week, when they finally sit, grab the cellphone and put Netflix on. So I start “Let me tell you a story. Who loves crime series/movies here?…”, and I start explaining the parallels between our role as product team and a true detective. Two quick wins here, clients start understanding the interactions needed (communication, co-creation), and they realize that it is FUN!.
The board
The board is divided into a series of sections that I’ll describe below.
Hypothesis
This is the entry point of the board. List one or more hypotheses for the product or idea. A suggested way to write them could be:
We believe that: [these customers or users] have [this problem or need], and if we build/make [this solution/feature/capability] they will [observable and ideally measurable behavior] resulting in [measurable business benefit]
Problems
In a conversation with the product sponsor, be sure to capture all the user problems in post-it notes, list all the user problems you can list (don’t worry, after listing them, you’ll prioritize). This part is important to understand the problem space.
Solutions
Solution space. Possible solutions can be, storyboards or sketches, user personas, user journeys, assets to use as inspiration from competitors.
Discovery Tasks
A mini-kanban board to track where we are, and what we still need to complete.
Research notes
After a user interview, we can collect any important info to have at the top of our mind, whether it’s a note on something that it is still missing or something that must be included in a prototype for the next interview.
Next big thing to learn
You’ll create experiments to validate hypotheses. This is the place to prioritize experiments and give them a narrative.
Ideas backlog
When prioritizing ideas to test, some of them will be nice to have, but it is important to have them registered in case at some moment the prioritization changes and we can have some inspiration to go back to.
Deltas
This area refers to registering the deltas that can exist between the hypotheses and the insights collected from the interviews. It’s important to keep track of how a hypothesis was invalidated or changed based on evidence.
The process
I divided this process in three iterations (three weeks). During the first week we define problem hypothesis, solution hypothesis, and test them at the end of the week (iterations) with real users, so we can collect feedback to feed the next iteration. It is important to start discussing how we can get real users from scratch, because time flies, and real feedback is key in this process.
At the very end of the process (end of the third iteration), we can prepare an estimated and prioritized list of features, and a backlog of ideas to start feeding a dual track process during the delivery.
Key take aways
Detective point of view — To position yourself as a detective, immediately put yourself in a position of analytical thinking, not taking assumptions as valid, until they are proved. Proven assumptions turn to facts (and that pushes you to not make decisions based on your own assumptions but instead validated hypotheses turn to learning facts.
To obtain different results, try something different — Challenge the status quo. When I was preparing my mind for the product discovery kick off, I said to myself, I don’t want to do the same as I did before, but change the approach to learn something new. And to add new, unique value to the proposition. Try different approaches to obtain different results. Experiment and learn.
Everyone wants to be involved in a process that is fun — This is a really important part of it. The process itself requires a lot of commitment from everyone. When every person involved is part of the process they share the outcomes. Everybody can be trusted to execute tasks daily. Communication and transparency are key from the outset in a kick off meeting.
Come on, do something different, experiment to learn something new.
Reference of the evidence board technique: https://www.jpattonassociates.com/product-discovery-recipes/
