I’ve been diving into different product management – importance of roadmap and product prioritization and then a RICE framework for prioritization. Today, wanted to jump back in but look at story mapping. I haven’t done a story map before, but I’ll share what I’ve found reading up on several sites including Aha!, MANIFESTO, Agile Velocity, ThoughtWorks, and others.
- There are two axes – from left to right, the goals a user accomplishes to achieve a greater goal (e.g. make a purchase, stream a video, other). From top to bottom, the prioritization of stories (activities/ tasks) organized into a release schedule.
- At the top level, you have the intermittent goals a user achieves. All tasks and activities that help accomplish this goal fall under. For streaming a movie on Netflix, for example, the top-level goals, these can be: “Find movie”, “Assess movie (details)”, “Select movie”.
- Under each goal would be the activities to accomplish the goal – the stories a user undergoes. For example, under “Assess Movie”: “View movie trailer”, “View movie description”, “View critics rating”, “View user rating”.
- Take an iterative approach to the story map where developers, product managers, and customers review the stories for gaps… adding missing stories and removing redundant stories.
- Evaluate which stories are critical for the first release – this may create the “MVP”. You could prioritize stories by “MUST”, “SHOULD”, and “COULD”. Assessing the stories, you could draw a line that demarcates the stories into the releases (or MUST, SHOULD, COULD).
- Utilizing Post-It notes is a fantastic way to create these maps offering flexibility and color-coded stories, goals, etc.
- Keep story maps focused on achieving specific outcomes and performing specific tasks for a target persona. Then, create other story maps as needed.
These are the highlights of utilizing story mapping in the realm of product management. It’s an effective route to hash out the activities to accomplish a user goal.
- Reach – How many customers or prospects would a feature/ development engage?
- Impact – What is the outcome/ results of a build? Would this drive engagement – feature/ user adoption? Drive revenue?
- Confidence – How likely would development have the effect on reach and impact?
- Effort – How many total man-hours/ weeks/ months would this development take? Remember to include hours for each resource across functions (i.e. product, front-end, back-end).
Intercom suggests teams add bands of scores to quantify each factor as best as possible. For example, to understand the factor of Impact, scoring can follow: “3 for ‘massive impact’, 2 for ‘high’, 1 for ‘medium’, 0.5 for ‘low’, and finally 0.25 for ‘minimal’”.
- Most folks enjoy the creation of new ideas, not necessarily incremental improvements to existing features/ product(s).
- Development can take on the personal interests rather than based on the impact and influence of another.
- As a partof the shield to guard against the “Next Feature Fallacy” where the idea that “this” new feature will improve traction, sales, etc.
- To align cross-functional teams on not only the impact, but the efforts required by all to produce XYZ changes.
Really, the key is being able to optimize for value based on limited resources. Product prioritization requires objective measuring to ensure the most valuable product, and thus company, is created.