In User Story Mapping, Jeff Patson delineates the role of effective communication in user story mapping, the importance of storytelling before even starting to build new products, and the beauty of documenting the brainstorming process. This, Jeff argues, is what is crucial for any product manager.
Effective communication in user story mapping is so much more than communicating back and forth in an email thread or PDF file. “Shared documents aren’t shared understanding,” Patson claims. He brings up the humorous example of how numerous birthday cake orders have been decorated incorrectly due to a misinterpretation of the decoration request that the customer submits online in a form. For instance, if the customer were to write “please put stars around the words ‘happy birthday’”, it’s not entirely impossible that the bakery quite literally writes the word “star” repeatedly around the words “happy birthday”, rather than the symbol of a star itself. Patson refers to this term, “shared understanding”, as “when we both understand what the other person is imagining and why”. I believe the most important part of this definition is “what the other person is imagining”, especially since a person’s imagination and complete thought process cannot possibly be encapsulated in a shared document, such as a cake online order form. When considering this from the lens of my own project team for CS 177, we have been ensuring that we always meet in-person when working on our project because we all recognize that ideas can get misinterpreted if we were to just text in our group chat, rather than have a back and forth, in-person conversation. I especially like Patson’s emphasis on asking “Do you all agree with what’s written there?” to your team because rather than assuming that everyone is on the same page, we can externalize our thoughts and make sure that everyone has a voice in the discussion.
Moreover, in Chapter 1, Patson discusses the importance of storytelling before even thinking about building a new product. One of my favorite quotes from Patson’s work is “Mapping your story helps you find holes in your thinking.” My team and I did this when we were planning out our project because we wanted to make sure that there weren’t any gaps in our idea before moving forward. Patson also suggests focusing on identifying the problems that people have in their day to day life; he proposes the question, “What problems does it solve for those people and for you?”. I can see this applying to my team’s project because initially, we had started off by thinking about solutions when in reality, we should be mapping out problems that we notice in people’s lives and then thinking about ways that we can find solutions to those problems.
Beyond that, Patson also argues for the importance of documentation. However, there’s a caveat to this argument in that while Patson is an advocate for documentation, he doesn’t believe in making the document a perfectly-formatted document. Documentation is more for creating a centralized location where the discussion ideas can be saved; the format and aesthetics of the document are not nearly as important.
Overall, I think that Patson’s article shows aspects that align with my understanding of other design processes, while also containing elements that differ. One aspect that I’ve found to overlap with rapid prototyping is the idea of not trying to perfect the presentation of the brainstorming process. For instance, Patson talks about not worrying about making the brainstorming document perfectly formatted.
