User story mapping for product managers

As a skilled product manager you know how to move between identifying the right problem and creating the right solution. Here we’re going to talk about ways that we create really great solutions. The center piece of this activity is the Agile User Story. There are there are schools of thought that these are just sort of stories that can be in whatever format. But I generally disagree with that. When I see a story that’s missing some of these clauses, I see a story that could be better thought out, and better elaborated on, to the people that are going to consume it, and work on it, as developers, testers, and so forth.

What’s good about these three clauses you see here is that the first one, you have to declare who is this user. And hopefully, you’ve done some really thoughtful work on personas, so you really know who this person is, you know what makes them tick, and you’ve introduced that to your team.

Rarely is there a problem with clause, I want to do something, because that’s relatively self-evident. But then so that I can realize the reward. Well this is where if you remember from the hook framework, rewards matter a lot even if they are little. We have little micro rewards, I’m walking down the streets I’m a sales person, I just finished a sales call. I type in a note that I just saw this customer. What’s my reward? It’s just that, hey, saved successfully, you’re all set, or know there’s something wrong here, please try again. So, we always need to know what is the end of the story? What is the reward we’re giving to the customer? It matters a lot.

It makes stories that are better, more thoughtfully executed, and more testable, both from a usability, as well as a functional standpoint.

We start with epic stories. These are, if you haven’t written a lot of stories, it’s important to understand that these are still relatively specific things that are going to happen in software. So for example, as the HR manage, I want to create a screen quiz so that I make sure I’m prepared to use it when I interview job candidates. This is good. The litmus test that I like to apply to this third clause, the reward clause, is well, how would we prototype this story in Balsamiq or some mock up tool? Put it in front of a customer and say, hey can you do this?

And then ask them, all right, is it ready to be shown to candidates now, or not? And we can see whether they think they’re ready or they’re not ready. That is a great litmus test for the testable reward. The other thing I’d like to do is when I create epics rather than just writing more detailed stories, child stories underneath them which is how we detail stories out. I like to take the epic if it’s important and storyboard it. kind of helps you step back from the epic and think about all the different things that might happen between the beginning and the end of that epic. Let’s storyboard this one.

Our first step is Helen gets a note, a trigger if you will, from Frank the function manager that says, hey, we have a new job description we need to fill. How do we quiz candidates? Or how do we get candidates? Helen creates the quiz and then maybe we’re going to hypothesize that she wants to double check it with Frank. Frank gets this note. And a big product design question is how this happens that we need to master. Frank gets the note that says, hey, this is the quiz I want to use for the new position. What do you think, is it okay or not okay? And if it’s not okay, what do you want to change about it?

Then Helen, maybe designing for error, designing for the other things that can happen is important. So maybe Helen wants to use more than three quiz topics. And so she has to upgrade her tier of service on the platform. Well how does that happen? Does the whole thing break or can we get Helen to do that and then put her back on the happy path?

And then maybe she finds out, my gosh, Frank wants to add some of his own questions that he thinks are important for our particular position. How does that happen? And then finally okay this looks good, I’m ready to use the quiz, how do we help Helen ascertain that? And with this storyboard, we’re not trying to sketch, it’s on a prototype of the interface. We’re just trying to think about how the user or users are going to relate to the story, what’s going to happen. And then I think that’s a good backdrop to use a story writing workshop or the seat down and write child stories to detail this thing out.

You could see a few from here, there’s a user’s story reference in the resources section you can go and look at all this. But, an example of a child story is as a manager, I want to browse my existing quizzes so that I can recall if I have something in place. And figure out if I can just reuse or update an existing quiz for the position I need now. And then the rest of these, just take you from the beginning of that epic to the end. Not necessarily in a straight line as you saw with the service tier upgrade. There could be little detours from it.

This is kind of how stories relate to the stuff we’ve talked about so far. We have personas, we have problem scenarios. We design propositions and see if they’re really motivated. And if they are, then the stories help us figure out how we’re going to create something and deliver well on this dimension of usability. A wonderful tool for doing this and making all this material visible and discussable with your team is the story map. This is the point where I will highlight the number one most important thing about user stories, they are not a specification. They are a backdrop for discussion with your development team.

If you’re writing all the stories, you’re going to get a much weaker performance from your team. Because they’re just not going to be as involved, and they are not going to understand these stories nearly as well as you think they do. And it’s nothing wrong with them. It’s something wrong with you. You haven’t been a good explainer, if you co-create these believe me you will get such a better result from your team in terms of the depth. And of their understanding and their interest in these frankly. The story map has on its top stripe here, stripe number one, a kind of excerpt of your story boarding squares that tell the larger arc.

The general story of everything you want to have happen with the product or feature you’re working on right now. And then you have these prioritized stripes. These are the highest priority stories. And this really brings to the foreground another key skill for product managers or really product owners which is that, you want to make sure you prioritize and then you implement in long horizontal slices. So if the arc of your product is let’s say search, select and purchase.

A really typical failure mode is to implement all the search stuff and then be at the end of your deadline. And now you just have a product or a prototype or a proto-product that you can’t release to anybody because there’s no meaningful experience for just searching. Instead, what you want to do is implement in thin slices. So this is our priority one and we have a complete experience. So even if we think we’re going to get down to like priority three in our iteration. If we only get priority one, at least we can roll out the highest priority version of search select and purchase that we can.

And that way we have working software that users can interact with and show us things. So that will help you do that and it’ll also help you get those stories on the board and have what we call an Agile information radiator to the rest of your team. So that the stories aren’t just specifying what to do but they are helping people ask the right questions and have the right discussions to drive to valuable usable products for the user.