You've gone out, you've got a persona and a job to be done hypothesis that's been answered by some nice, strong qualitative analytics with real people outside or inside the building as a case may be with Ivan, the inside salesperson. You've got a nice strong foundation for your value hypothesis for what it is that you're going to do for these people. This is all before we even start thinking about how to design the software or build it exactly. Good. Here's a hard problem, how do we keep this understanding of the focal parts of this user journey and the big picture top of mind while we progress to the individual details of our respective jobs, whether we're developer, designer, apps test person, or analysts instrumenting analytics into the code? The reality is that's a very hard problem. It's very hard to keep everyone focused on the big picture adequately while still leaving them the space and the focus to get in and deal with the details that have to be part of building a piece of software. So one tool that's really popular is the story map. You may be familiar with this. The basic idea is that as we're doing our qualitative research, we're thinking about and we're sketching out the user's journey. So what do they do now and what's like the before and the after of their experience when they have our product? This is an example of a storyboard that the team might have made as they were talking to trend and learning what it does. Now, I used a tool to build these. You can sketch these by hand and that's perfectly fine. The idea here isn't that these get credibility from being good pieces of art, they get credibility for being well-researched and relevant. The idea with a story map is that rather than having what's called a flat backlog like this in Trello where we just have columns and we have a Kanban board, which you may be familiar with, there's course resources if you're not and we'll come back to this. We look at our individual user stories. Instead, we have maybe up on our wall for example, a board, a story map where the top stripe, we'll call it stripe A are sections from our storyboard. So we're looking at the larger arc of the user journey up here. This keeps us anchored in the bigger picture of what's going on with our customer, and the job that that does is it helps the team have a glance at the big picture when they look up from their computers and without overwhelming them and distracting them. The story map does a really important job specifically, which is that it helps us think about the different features we're building and how we can instead of building for example with [inaudible] in a hurry, all the different search functions and then all the different ordering functions. Instead, we prioritize in these horizontal stripes. So we make sure that as we're working, we code out, we develop, and we're releasing and getting feedback, iterative feedback from a complete user journey before we flesh out all the different details. Without this, the team has a natural tendency to just say, "All right, we're working on search, let's do all the search stories." The story map is really terrific at solving that problem. Here, I'm going to propose that as agile analytics enthusiasts, you go through and you add a second stripe and we'll call them top-line questions. So for example, what you're seeing here is we have stripe 1, stripe 2, you can see we've got our first search story in strike 1, and then down here, we have the other search stories. So the idea is this, we pick one of these, we do that before we code the other search stories and then we move on to, for instance, coding the story where the technician sees the pricing and the availability and then out here, we can't see it. Then we go and we can code the ordering, we get that out the door and we see what happens. So that's the role of the story map. What I recommend you do and what we're going to focus on as we move to the course areas, I would add a second stripe which is our analytics guide post and big picture where we just ask simple, understandable questions about how we'll know if we're being successful at these different points in the journey. So for example, as we look at the search alternatives, what's a simple question that we want to know to figure out whether this search modality like search by part number, search by making model is working out for the technician. Well, we probably just want to ask, how well does this search type work relative to the alternatives? In other words, when they search by part number versus they search by making model and they filter, which one of those searches tends to be used the most and which one, more importantly, tends to lead to the next step? Which is something that we can easily collect and analyze with any basic analytics software like Google Analytics and a little bit of instrumentation into our code. Here, let's look at another example. How often does this lead to a part order? So for example, as they transition and they find the specific part, are they actually ordering it when we present it, and how does that change over time as we change up the software? Then finally, maybe an end question for this ordering is we want to keep our eye on this storyboard square where Trent talks with the customer and figures out what to do. Let's say, how well do technicians that use this perform in terms of time on-site, customer satisfaction, billable hours, non-billable hours, how well do they do versus let's say a cohort that isn't using this tool? We're going to look at how we might arrange that testing and measure it. So this is an extension of an already popular, I would say, really well-validated, really helpful tool, the story map, where we add analytics into it to help not only stay focused on the overall user journey, but also its testability and making sure that as we code and we execute, we know how to tie that back to analytics, and we don't worry about all the details yet, but we do keep the right questions in mind to help us stay focused and iterate more purposefully.
