Transitioning From Quality to Product Management — pt 2
A practical approach using Story Mapping
Alrighty, in my previous article we went through a list of product management theory and reference material which lays the foundation for the terminology, standardized procedures, and best practices.
Now we need to roll up our sleeves and get immerse on the practical side!
We are going to start with User Story Mapping. Let’s remember, story maps look at the big picture and it facilitates rich discussions about product vision, potential users, their needs, key product capabilities, minimal viable product, product releases, their goals, risks, and priorities. It is about creating a shared understanding of the following narratives:
- Developers understand the users, their goals, and context better.
- Designers understand what is feasible, what the risks, costs, trade-offs are.
Story Mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product. — Jeff Patton.
1. Frame It (capture the primary goal of your product/feature)
Before starting the mapping, create a small product/feature brief. Think of it as establishing a common goal or vision. Ask these questions:
2. Map that ‘BIG PICTURE’ (building the backbone)
Start with blank wall space and a high-level vision — a placeholder for upcoming conversations. The activities and high-level user tasks that tell the whole story/entire user journey form the backbone of your story map.
Think “milewide, inch deep”.
Continue by describing the user type most critical to your product’s success. Then imagine a common day in that user’s life adopting the new product, an ideal user flow.
Map the user’s steps as user tasks from left to right. Identify user activities, any groups of tasks that together can support a common goal. After this, add in supplementary users. When following the typical use of the product, you may find other types of users enter your story. Proceed to model their story left to right.
We need to talk to subject matter experts to get more information, that way our journey will be nourished. During this activity, everybody can write the steps needed and put them on the board.
3. Explore & break large tasks into subtasks
The steps in the backbone probably are too big for a sprint duration. Break down larger user tasks into smaller subtasks and interface details. Add cards, split one card into two, rewrite, reorganize them. Place subtasks underneath their associated task/step and activity.
Think about all the possibilities, what could go wrong, exceptions, variations. Do not worry if your ideas are ‘in or out of scope’. Later on, things can move to adjust to the desired scope. This is also the time to add other product details like a description of the proposed UI, business rules, data elements, etc.
Don’t hesitate to involve other people from different parts of your company, they might tell you: where you are missing steps in the user journey, if the task is too big, too small, too risky to implement. Search for ‘pain points’, most of the time those are things we haven’t thought about.
Remember to prioritize the importance of each task by moving them up and down, keeping high-priority ones at the top.
4. Slicing Viable Releases
It’s time to slice your map into product releases. By moving horizontally from left to right you can get a slice of what your product could do. These slices need to form an increment product release roadmap where each release should be a minimal viable product release.
Every release should have explicit outcomes and impact. This way we know how the release contributes to the overall goal. Also, identify product success metrics. Answer the following, ‘what would we measure to determine if this product was successful?’.
5. Slicing a Developing Strategy
Slice the first release of your map into three or more delivery phases so that your team can learn fast and avoid risk. A development strategy can help you release the best product possible in the time constraints you have. For example:
- Delivery phase 1 — ‘MVP’: the simplest possible functional version of your product. Vet the product with users and other stakeholders. Begin validating performance and scalability.
- Delivery phase 2 — ‘Higher quality of service’: completing all major functionality and making existing functionally richer. Continue testing and adjusting the product based on feedback; continue testing performance and scalability.
- Delivery phase 3 — ‘Scaling Up’: Refining the product in preparation for release. Continuously assess release readiness based on your release level product goals. Notice that unforeseen work can emerge during this last stretch of development, so you need to count it in.
In your developing strategy, you need to consider planning the work necessary to refine stories. If the stories still need it, you can have story workshops to go through details and agree on acceptance criteria.
Also, plan and schedule development and testing.
Last thoughts:
- In terms of scope and complexity, visual representation of the product backlog brings all stakeholders on the same page.
- Story Mapping helps with prioritization and supports easy slicing of the backlog into small enough releases. Be ruthless when slicing!
- Don’t forget your user story map is alive. Make sure an updated version exists and it remains relevant.
- Story Map Structure: Goals > Activities > Tasks > Stories
- A good map has many levels of detail.
- Remember to surf your system from a user perspective.
- For an existing backlog of well-written user stories, simply pull them into your map.
- A useful comparison I use:
Activities <> Themes
User Tasks<>Epics
User SubTasks <> User Stories
Great online tools to do Story Mapping:
Resources studied:
Next steps in part III…
All about user stories & how to write awesome acceptance criteria.
Thanks for reading!
Clap 👏 — please show if you like this article so others can find it.
Respond 💬 — please let me know if you have any suggestions or questions.
