What hidden assumptions might be affecting your product development process? How can you systematically uncover these assumptions to create better products?
Product story mapping is a powerful technique introduced in Teresa Torres’s Continuous Discovery Habits that helps teams visualize and analyze each step of the customer journey. This method reveals crucial assumptions that might otherwise remain hidden, potentially affecting your product’s success.
Keep reading to learn how product story mapping can transform your approach to understanding customer needs and creating more effective solutions.
Product Story Mapping
To uncover your underlying assumptions, Torres recommends using product story mapping. This entails laying out each step users need to take to get value from a solution, which helps reveal underlying assumptions at each step. To do this, note which people or entities need to interact for the customer to access your solution and map these out chronologically. Then note any assumptions you’re making at each stage of these interactions.
For example, if you’re developing a video game, your important people and entities could include the customer, the games store, and the console the customer uses. The interactions could be as follows: 1) The customer goes to the online game store to look for something to buy. 2) The game store shows your game as purchasable. 3) The customer buys the game. 4) The customer plays the game on their console. At stage 1—the customer visiting your online store—you might be assuming that customers want the type of game you’re offering—a desirability assumption. At stage 2, you’re assuming the customer knows how to navigate the game store—a usability assumption. There’ll also be other assumptions for stages 3 and 4.
(Shortform note: Story mapping was developed by Jeff Patton in the early 2000s and was intended to help product teams better understand their customers. Story mapping works best when it’s done collaboratively, with everyone on the team participating equally and challenging or editing wherever they see fit. It also works best when the maps are continually updated in response to new information and customer feedback.)
You may not need to go through the whole story-mapping process every time. Torres explains that, as teams develop their skills at spotting assumptions, they may naturally move away from using formal methods. The key is to use whatever methods help address the team’s particular blind spots, as most teams tend to have biases toward certain categories of assumptions while overlooking others. For example, the product development team in our video game example might be adept at spotting desirability assumptions—knowing what will appeal to gamers—but struggle with viability assumptions, leading them to try to add features that can’t be supported with current technology.
(Shortform note: Expertise development explains why teams may move from relying on the formal story-mapping process to eventually being able to do it informally. As people spend time on certain tasks or skills, they gradually develop greater proficiency, which can eventually turn into mastery with enough practice. As teams get more accustomed to noticing their blind spots, they’ll also get better at fixing those blind spots—eventually eliminating them as “blind” spots altogether. However, depending on the skill, the people involved, and the amount of practice, expertise development can take a very long time, so don’t be concerned if your team is still relying on formal methods months or even years into the process.)
