9 User Story mapping tips: forget your product

Credit: Matt Nelson. chalkthoughts.com

User Story mapping is awesome. However I have sometimes found that a story mapping session to put through a revision or improvement to a feature can be painful because it’s so easy to let the how the product currently works cloud the judgement and creative part on how it could or should work.

Product Owners and Product Managers struggle with this if they have a deep knowledge of the products internals, but also I found that technical team members struggle with this in particular, as their knowledge of the innards is often more detailed. If a system is complex, it can be harder to think from the point of view of a blank slate. Some of the problems I have ran into when doing that:

  • “But the system currently works like this”
  • “We can’t do that because currently we do this..”
  • “That wont work because of current limitation in how the database is structured.”

What’s happening here is a conversation that’s sooo easy to fall into, but it simply shouldn’t be happening. When story mapping, even if it’s to improve a current feature in your product, you shouldn’t be thinking about the current limitations or parameters set out by the version you are trying to improve. You should be thinking about everything you want that feature to do, even if you hit on features that are already implemented.

So I have jotted down my ideas to help keep you and your team on track when story mapping for improving your product features:

  • Mapping curator. Every couple of minutes, you or someone in the group should remind the team that the goal is to forget about how the feature currently works and focus on the perfect product.
  • Forget about the product. Forget about everything that’s currently implemented. You should encourage everyone in the session to do that, too. Think about that feature as if you were brainstorming and story mapping it for the first time.
  • Go higher level. If you are struggling to keep things on track then try going higher level. For example, if you’re adding a new feature to the payment process of your e-commerce product — let’s say for example adding paypal integration and a couple of other things — then name the entire story map “Payment Process”; instead of “PayPal integration”. Avoid using the Epic level feature name for the entire story map — that will encourage you to think about the entire payment process, rather than just parts of it. That will help you get most out of that feature, and help you realise any missed interactions between that and other features.
  • As a <persona>. I want <some feature>. So that <achieve something>. Back to story mapping basics. Even if you don’t write it on every card, make sure every card has been thought about from the users point of view — even better if you have a specific persona to work with.
  • Huge user story maps? Headline the existing features. If the map is becoming huge because you are mapping existing features, that’s OK. You could maybe not fill out columns for features you know don’t need to change.
  • Forget about the back-end. Forget about the database. This is User story mapping. Keep reminding yourself that. You are trying to build a plan on what the product should look like from the users point of view.
“Quality in a service or product is not what you put into it. It is what the client or customer gets out of it.” ~Peter Drucker
  • Stick up all stories and ideas. Never don’t stick something. If you hear yourself, or someone else saying “I have an idea but I won’t put it up..” — slap yourself! It needs to go up. Whether it’s part of your MVP or if it’s realistically never going to get put into your product.. it doesn’t matter. You are User Story Mapping to brainstorm and plan your product and you want your product to be as brilliant as you and your team can build it. Once all the stories are up, and you are happy with that — then you can start to slice off versions, and negotiate what’s in your MVP, V1, V2 etc..
  • Keep it lean. If you let the thoughts of the current implementation hold you back, you won’t be able to make progress with {Build, Measure, Learn} loop as taught in Eric Ries iconic book, The Lean Startup.
  • Brainstorm ideas, then prioritise. Like I mentioned before, stick all stories up.. put them somewhere. Do that first — then, and only then: slice of different versions.

Generally, keep in mind that even though you are working to improve a certain feature of your product, doing that with knowledge of how it currently functions doesn’t help improve the potential of your product at this stage. You want the product to be as awesome as it can be, and you want the user story mapping process to be as blue sky as possible. Knowledge on existing features can come after you have obtained all the ideas on how to improve the product — and the only way to do that is to start with a clean slate every time.

I am a dedicated Product Manager and technologist working in Glasgow, Scotland. I am devoted to amazing products, startups and brilliant teams with a healthy culture. If you liked my article, follow me on twitter @colin_riddell

Colin J Riddell

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.