What features to build for your SaaS product? Part 2 - Story Mapping
Story Mapping technique as a product prioritisation technique for product teams
In the previous post, we covered a simplified version of Kano model and how it makes the product teams consciously think about customer's emotional response to your product. As a continuation to that series, we will cover another interesting UX process, Story mapping in this edition.
Part 2: Story Mapping for feature prioritisation
What is it?
This is a fusion of agile stories and user journey mapping process from the UX world.
The key idea is to breakdown any product into critical user journeys that a user has to undergo and map them visually as a step by step process. Each of the steps gives you an idea of critical features and good to have features, that are necessary to achieve the end goal. Thanks to its simplicity, it is super effective to get alignment within product teams. Also it is super visual and highly suitable for a team sprint workshop.
Step by step method to implement this technique
Jobs to be done: List the key tasks or jobs that a user has to accomplish by using your software. For example, for a CRM tool,
Critical job 1 is to enable users to create leads and contacts.
Critical job 2 is to enable them to send emails or make phone calls to the leads created.
Critical job 3 is to track a lead's progress in the sales pipeline etc etc.
In UX parlance, they call this as Jobs-to-be-done framework. Essentially it breaks a large software into simpler user jobs and user journeys to get them done. This is based on the belief that users are interested in getting a job done and not necessarily thinking of your software in terms of its individual features.
Pick one of the key jobs from the list above.
On a piece of paper or on a digital jam board, along the horizontal axis, write down the sequential steps that a user has to go through to get that particular job done.
For the CRM example above, 'creating a new lead' is an important jobs to be done for the user. Now for this job, the hypothetical steps could be something like this…Now this is the basic flow. Reserve the details for the next step.
Now think of additional rich features that each of the above steps would have in a matured software. For instance, there could be option to add additional information to the form or instead of just saving , there could be an option to "save and add another"
I am just guessing feature improvements here based on my limited experience of having used a CRM tool. I guess you get the point here. As a product member you might be able to come up with more items for each of the steps. Now keep adding them below the bare minimum step as shown above.
each of the swim-lanes added below the main sequence of actions are additional features needed to be prioritised.
But the key advantage is that we have added a user-journey lens to all the individual features. Now the discussion within the product team is not about 'autosuggest feature in search bar' , it is about giving more ways for the user to discover the product that they were looking for in the first place.
The product discussion has moved to user journey based wording. And thats a win already in the right direction for your product.
Pros of Story mapping
Deeply centred around user's experiences. So every feature becomes a user story in itself.
MVP identification becomes super easy in this method. The top items on your user flows automatically becomes the release zero or MVP as you call it.
Suitable for products in all stages.
Also the story map developed becomes a visual asset for the product team to refer to at any stage.
Cons of story mapping
Business value, competitor features and complexity of the features listed are not taken into account at all.
This is particularly important for products that are fundamentally complex to build. One good example is building a 3D video game. Even the basic user journey in such a project would take enormous engineering effort and complexity which is not factored in this method.
When to use it?
Use it when you want to quickly release a MVP or proof of concept for your idea. It helps you identify the core tasks very effectively.
Isn't this the responsibility of a PM? What does UX has to do with it?
In an ideal situation, the entire team including engineering, UX, marketing and support staff should be involved in this process with the PM leading and curating the inputs. But for all practical reasons, Product managers (PMs) end up doing this in most companies.
Designers can add unique value by bringing the most relevant user research inputs to assess what emotional impact a particular feature will have on the user. Users may not spell out the exact feature that they may die for but understanding their underlying motivations, fears, needs and desires will give you a fair idea to make a close guess of the potential impact. It is always iterative process but at least a UXer make the starting point so much closer to the sweet spot and also give a sense of direction to improve further.