This is the fourth part of our Illustrated Guide to Product Development series.
Part of product development is understanding your customers. Customer Journey Mapping is the process of looking at the end-to-end series of events that make up the entire story of before your product/service, using your product/service, and after.
These maps can become quite long and involve many actors or personas. They may not even be linear. By examining these different customer journeys, it is possible to identify key use cases that your product/service needs to do incredibly well. This should include anything that is currently causing a lot of customer grief (often for no good reason), and use cases that really improve the core product offering.
There may also be some terminology shifts between sales, marketing, UX, project manager, product managers and developers. No matter the scope of the story or your phrasing, if you are thinking like a customer, that is a good thing!
Customer Journey Mapping includes looking at both Epic User Stories and Agile User Stories. Epic and Agile User Stories can and should be separated out from the complete customer journey, and considered in greater detail. Epic User Stories encompass a fairly broad story; what is the process that a purchaser goes through to want, find, and purchase your product or service? Agile User Stories are more specific to the primary users of the product or service.
Sometimes Epic and Agile Users may be one in the same, but in many cases, particularly in the corporate environment, decision makers are not necessarily the ones most actively involved with the product or service.
As you begin to get a sense of your journeys, it may make sense to create a customer journey map of where things are today, and a second of where they should be in five years in a perfect world with infinite development resources.
As we began to dig into SoLoMoFoo, we have decided to go with a Business to Business (B2B) business model (see Choosing the Right Go-To-Market Strategy) and have done a detailed persona (Personas for Product Development) for HR Hailey since she is the decision maker who will ultimately decide to purchase SoLoMoFoo.
We will now show a customer journey map starting with an underlying problem HR Hailey has - low company morale - how she learns of SoLoMoFoo, steps to deploy in her office, and ultimately the rewards she has for doing so.
For your first customer journey map, 6-8 cells is a good length, but as you become more familiar with the process, you can add more and more steps to the journey. For example, we could have included a few cells about how the company was informed of this new initiative, or how employees were notified. Start small; get the basic ideas out onto your storyboard and make adjustments and additions over time. You can always go back to make changes, save different iterations separately, and use different layouts for different purposes.
Pro Tip: Here at Storyboard That, we like to break up some of these larger stories into multiple storyboards with a max of 12 cells to make discussion easier and more focused.
From HR Hailey’s perspective, a simple email was sent to Ivan and everything was magically setup. When still trying to figure out if there is a viable business problem, being vague about specific processes is fine, and even encouraged. As we continue to dig deeper into the next layer of key problems to be solved, this particular Agile User Story is pretty important as it sets the direction of some of the technical requirements and business problems.
Although this story shows a fairly clever solution to enterprise deployment by leveraging Google Apps or Microsoft Exchange, the story still remains fairly high level and does not get into the technical details of how to make this happen. This is an important concept to show enough information about a solution for understanding, but not enough to force one and only one implementation.
At a high level, looking at the story from HR Hailey’s perspective shows a marketing strategy of going after HR Personnel via targeted marketing content. To be successful though, there needs to be a very easy way for HR Hailey the decision maker to have IT Ivan setup and deploy SoLoMoFoo, and then the company needs to embrace it. In the next article we will ask if these are good assumptions.
To best illustrate Customer Journey Maps and user stories, we used two stories of drastically different scope and complexity. This was intentional to show that some stories involve a tremendous amount of complexity, whereas others less so. The graph below is by no means exhaustive, but is meant to illustrate that customer journeys / user stories and their matching personas make sense for a wide range of complexity illustrated. We are also included the concept of marketing on-boarding since we feel it is so critical that marketing is a part of these conversations and thinking with a customer-centric lens. This process should be iterative, collaborative, and have various levels of specificity.
For more information, read our article dedicated to User Stories.
For certain trivial activities, like changing the color of a button or packaging, a storyboard is overkill.
Depending on the scope, complexity, and information you have for your customer journeys and user stories, a number of different starter templates might help you start a journey map. You can also simply create a storyboard if a blank canvas is more your style.
Next up, Validating Your Business Assumptions.
Aaron Sherman (@AaronBenSherman) is the CEO and Creator of Storyboard That (www.storyboardthat.com) – the award-winning, world leader in digital storytelling technology. Aaron founded Storyboard That in 2012 after 10 years working the full gamut of product development roles (Developer, Project Manager, Product Owner, and Long Term Strategist) across three continents (North America, Europe and Australia) to fundamentally improve how products were internally prototyped and discussed.
Aaron has spoken as a guest Lecturer to MBA students at Northeastern, and with General Assembly leading workshops on Product Development.