User story mapping has become a go-to technique in Scrum for effectively capturing and visualizing user requirements. While Product Managers and Agile teams commonly leverage this approach, user story mapping extends its benefits to various stakeholders involved in the Scrum process. This article will act as a comprehensive guide for Agile Product Development. Indeed, it will explore how the different users in Scrum can harness its power to drive successful product development.
As the orchestrators of product vision and strategy, product managers play a vital role in user story mapping. Not only do they utilize this technique to gain a holistic view of user needs, but also prioritize features. User story mapping helps product managers identify gaps, dependencies, and opportunities, enabling them to make informed decisions that align with the overall product vision.
Scrum Masters act as facilitators and coaches for the Scrum team. They play a crucial role in ensuring effective collaboration and communication. Hence, user story mapping serves as a valuable tool to guide and facilitate user story discussions and sprint planning. It helps them create a shared understanding among team members and fosters a collaborative environment.
As for development teams, they are at the heart of the Scrum process, responsible for transforming user stories into working product increments. As a matter of fact, user story mapping helps development teams gain clarity on user requirements, dependencies, and priorities. It enables them to plan their work effectively, break down stories into actionable tasks, and align their efforts toward delivering value to end-users.
Next, user story mapping allows Designers to understand the user journey and design experiences that meet user needs. By visualizing user stories, designers can identify touchpoints, pain points, and opportunities to enhance the user experience. They can collaborate with product managers and development teams to create intuitive and user-centric designs.
Finally, stakeholders such as executives, customers, and business analysts, benefit from user story mapping by gaining visibility into the product development process. The tool provides a clear picture of the product’s direction, timeline, and expected features. All stakeholders can actively participate in discussions, provide feedback, and ensure alignment with business objectives.
All in all, user story mapping is a versatile technique that caters to various users involved in Scrum. From product managers shaping the product vision to development teams delivering working increments, each stakeholder benefits from the shared understanding and collaborative environment fostered by user story mapping. By leveraging this technique, Scrum teams can streamline their processes, enhance communication, and deliver products that truly meet user needs.
Start embracing the power of user story mapping and unlock the full potential of Scrum!
Agile project management has become an integral part of software development methodologies. It has revolutionized the way software development teams operate, making them more flexible and adaptable to changing market demands. At FeatureMap, a User Story Mapping Software company built by engineers, we believe that User Story Mapping is the best agile technique for managing software development projects.
What is User Story Mapping?
User Story Mapping is a technique used in agile project management to plan and organize product development based on user needs. It involves creating a visual representation of user stories, which are short, simple descriptions of a feature or functionality that a user needs to accomplish a specific task. The user stories are then grouped into themes or epics, and arranged in a hierarchical order to create a map of the product development process.
Why is User Story Mapping the Best Agile Technique?
User Story Mapping is the best agile technique for several reasons. Firstly, it helps in prioritizing techniques by providing a clear understanding of the user needs and requirements. This enables the development team to focus on the most important features and functionalities, ensuring that the product meets the user’s needs and expectations.
Secondly, User Story Mapping is a lightweight and non-nonsense stand-alone solution, which means that it is easy to use and does not require any additional software or tools. This makes it accessible to all members of the development team, regardless of their technical expertise.
Thirdly, User Story Mapping is an effective tool for creating agile project plans. By providing a clear and concise overview of the user stories and their priorities, it enables the development team to plan and schedule their work more efficiently. This ensures that the project stays on track and is completed within the required timeframe.
Example of User Story Mapping in Agile Project Management
Let us consider an example of how User Story Mapping can be used in agile project management. Suppose we are developing a project management software using agile development software. The first step is to identify the user needs and requirements. This can be done by creating user stories, such as “As a project manager, I want to be able to assign tasks to team members, so that I can track their progress and ensure timely completion of the project.”
Once the user stories have been created, they can be organized into themes or epics, such as “Project Management,” “Task Assignment,” and “Progress Tracking.” These themes can then be arranged in a hierarchical order, creating a map of the product development process.
Using User Story Mapping, the development team can easily prioritize the user stories based on their importance and create an agile project plan that focuses on the most critical features and functionalities. This ensures that the project is completed within the required timeframe and meets the user’s needs and expectations.
The Bottom Line
User Story Mapping is one of the best agile techniques for managing software development projects. It helps in prioritizing techniques, creating agile project plans, and providing a lightweight and non-nonsense stand-alone solution. At FeatureMap, we believe that User Story Mapping is essential for any software development team that wants to be agile and flexible in today’s fast-paced market.
You can try FeatureMap and get started with making your first map right away, and for free.
As a project leader, you know that Agile methodology is essential for successful software development. User story mapping is a prioritizing technique that helps teams understand the user’s needs and plan the development process. At FeatureMap.co, we offer an agile tool that simplifies user story mapping and streamlines the software development process. In this post, we’ll discuss the advantages of Agile methodology and explain how our tool can help you achieve your project goals.
What is Agile Methodology?
Agile methodology is a software development methodology that emphasizes flexibility, collaboration, and continuous improvement. Unlike traditional Waterfall methodology, which involves a linear approach to software development, Agile methodology involves iterative development and testing.
Agile methodology offers numerous advantages, including faster time-to-market, improved quality, increased customer satisfaction, and reduced risk. By using Agile methodology, teams can respond quickly to changing requirements and deliver software that meets the user’s needs.
User Story Mapping
User story mapping is a prioritizing technique that helps teams understand the user’s needs and plan the development process. It involves breaking down the user’s requirements into small, manageable stories that can be completed in an Agile sprint. User story mapping ensures that the development team is focused on delivering features that are valuable to the user.
For example, imagine that you are developing a project management tool. Your user stories might include creating tasks, assigning tasks to team members, and tracking progress. By breaking down the user’s requirements into small stories, you can prioritize the features that will provide the most value to the user.
The Benefits of Using FeatureMap
At FeatureMap, we offer an Agile development software that simplifies user story mapping and streamlines the software development process. Our tool offers a collaborative environment that allows teams to work together seamlessly, ensuring that everyone is on the same page.
Our tool is easy to use, even for teams that are new to Agile methodology. With real-time tracking and prioritizing features, our tool ensures that everyone is working towards the same project goals.
How FeatureMap’s Tool Can Help with Agile Project Plans
Our tool offers numerous benefits to Agile project planning, including:
Prioritizing features: Our tool makes it easy to prioritize features based on user needs, ensuring that the development team is focused on delivering features that provide the most value.
Creating a shared understanding: FeatureMap helps teams all get on the same page by seeing the visual big picture.
Story points in Jira: Our tool integrates with Jira, allowing teams to track their progress and estimate the time required to complete each task.
Real-time tracking: Our tool offers real-time tracking of progress, allowing teams to identify and address issues quickly.
So what next?
Agile methodology is essential for successful software development, and user story mapping is a key prioritizing technique that helps teams deliver software that meets the user’s needs. FeatureMap’s Agile development software offers numerous benefits, including a streamlined development process, a collaborative environment, and real-time tracking. If you’re looking to improve your Agile project plans, we encourage you to try it out free today.
Are you tired of feeling overwhelmed by your backlog and deadlines? Do you want to improve communication and alignment among your team? Look no further! A User Story Mapping Workshop is the perfect solution. Not only will it help identify problem areas, but it’s also easy to teach and can be introduced with a simple game.
In just 30 minutes, your team will learn how to use this powerful technique to make the most of their time and effort. Don’t let fear of the unknown hold you back – give User Story Mapping a try and watch your team thrive!
Teaching User Story Mapping to your team can seem a little daunting to newbies when you first pull up a full FeatureMap. Luckily, User Story Mapping is easy to teach, and I have a great simple exercise to walk your team through as an introduction.
The technique is innately simple and can be taught with one simple game (because if we say game instead of exercise, it sounds better, right?).
I have some exciting and engaging 30-minute games that you can use in your teaching workshop or as a starting point for a User Story Session. These games will not only help your team develop a better understanding of User Story Mapping, but they’ll also have fun and build team cohesion along the way. So why wait? Add some fun and learning to your next workshop and watch your team thrive!
How to conduct a User Story Mapping session and teach!
Running a user story mapping session is fairly straight-forward and you can get sorted quickly.
Here is an easy set of instructions broken into 8 steps:
Begin by explaining the concept of User Story Mapping and its importance in the product development process.
Provide an overview of the steps involved in conducting a User Story Mapping session, including how to identify user needs and create a shared understanding of the product vision among team members.
Divide the participants into small teams and give each team a scenario, such as developing a new mobile app or a website for a small business.
Ask each team to brainstorm and identify the different user needs and goals that the product should address.
Have the teams create a rough draft of their User Story Map, using sticky notes or a whiteboard to organize the user stories into columns representing the different phases of the product development process (e.g. planning, development, testing, etc.).
Ask each team to present their User Story Map to the group, explaining their reasoning behind the organization and placement of the user stories on the map.
Facilitate a group discussion to identify common themes and areas for improvement in the different teams’ User Story Maps.
Conclude the exercise by summarizing the key takeaways and reinforcing the importance of conducting User Story Mapping sessions as part of the product development process.
By participating in this exercise, team members will gain hands-on experience in conducting a User Story Mapping session and will learn how to use this tool to create a shared understanding of the product vision among their team.
Get to Work!
One of the easiest and well known games is the “Get to work” or “Wake up in the morning” tasks.
You write out on your map what you do each morning. This can be broken down to the most mundane steps.
I once had a team member write out everything they did which included an impressive rising time of 4am and 3 hours of morning preperation. I have since added to the challenge that they only have 20 minutes to get up and to get out the door to get to work.
What you can do is expand the task to reduce the time available, and to extend the time available to experience with what they add and cut aka minimal viable product! 😉
Another game that can be used to introduce the concept of User Story Mapping without the need for cards is called “User Story Jigsaw.” This game involves dividing the participants into small teams and giving each team a set of user stories that are related to a specific product or project. The teams must then work together to organize the user stories into a logical sequence that represents the product development process.
To play the game, first, create a set of user stories that are related to a specific product or project. These user stories should be based on the real-life challenges and needs of the team or organization.
Next, divide the participants into small teams and give each team a set of user stories. The teams should then work together to organize the user stories into a User Story Map, using sticky notes or a whiteboard to create columns representing the different phases of the product development process.
The teams should then place the user stories onto the map, trying to create a logical sequence that represents the flow of the product development process. The team with the most effective User Story Map wins the game.
After playing the game, the teams can discuss their User Story Maps and compare them to see how they differ and what they can learn from each other. This discussion can help the participants gain a better understanding of the concept of User Story Mapping and how it can be applied in their own work.
Tic Tac Toe Game
another game that can be used to introduce the concept of User Story Mapping is called “User Story Tic-Tac-Toe.” This game involves creating a grid with different user stories written in each square, and then having the participants take turns placing their “X” or “O” on the grid to organize the user stories into a logical sequence that represents the product development process. The objective is to create a User Story Map that covers as many squares on the grid as possible, with the winner being the team that creates the most effective User Story Map.
To play the game, first, create a grid with different user stories written in each square. These user stories should be based on a specific product or project that the team is working on.
Next, divide the participants into two teams and give each team a set of “X” and “O” markers. To begin the game, one team should place their “X” on the grid, choosing a user story from one of the squares. The other team should then place their “O” on the grid, choosing a user story that is related to the first user story.
The teams should continue taking turns placing their markers on the grid, trying to create a User Story Map that covers as many squares as possible. The team with the most effective User Story Map wins the game.
After playing the game, the teams can discuss their User Story Maps and compare them to see how they differ and what they can learn from each other. This discussion can help the participants gain a better understanding of the concept of User Story Mapping and how it can be applied in their own work.
Final Tips for your Workshop Games
Using games and exercises to teach any product or methodology will be met with variation. Be aware of your audience, what will work and tailor your tutorials to fit them.
Some important tips for running these games.
Clearly explain the objective and rules of the game at the beginning to ensure that all participants understand what is expected of them.
Encourage collaboration and teamwork among the participants, allowing everyone to contribute their ideas and perspectives to the User Story Map. Try to discourage any“leader” roles who make all the decisions, let the entire team contribute.
Provide guidance and support to the teams as needed, helping them to understand the concept of User Story Mapping and how to apply it to their own work.
Focus on keeping time for each exercise to be utilised well, we often recommend under 60 minutes.
Use a variety of tools and materials, such as sticky notes, whiteboards, and digital tools, to allow the teams to create and organize their User Story Maps in the way that works best for them.
Debrief after the game to discuss the teams’ experiences and what they learned from the exercise. This can help reinforce the key takeaways and provide additional insights and guidance for applying User Story Mapping in the future.
Consider providing additional resources and support for teams that want to continue learning and practicing User Story Mapping after the game or exercise is over. This could include access to online tutorials, workshops, and other learning materials.
User Story Mapping is innately simple, with a huge range of depth that can be demonstrated in deep and powerful maps. If you need more assistance or ideas, check out how some of our templates to inspire.
What are the main differences between a user story and a user journey?
A user story is a brief, concise description of a task from the perspective of the user.
For example: “As a ‘type of user‘, I want ‘some goal’ so that ‘some reason’.”
A user journey is a described series of steps that show how a typical user would interact with the web app that is being designed.
The main difference between the two, is that a user story is based on a specific user and caters to a particular type of user to answer a specific problem. A user journey can follow a “random user” that may using the tool. This also includes dynamic user journey scenarios.
User Story Mapping has been described as a tool that can be used for many purposes, including product development, feature definition, version improvement, and project management.
In short, you are able to create a map, highlighting the user story, as a persona, whilst building the map for a user journey. Placing cards and tasks and building out the entire epic.
You can get started straight away, and intuitively you’ll be building maps that remove the debate between user story and user journey. Just head over to FeatureMap.co to get started.
Otherwise, read on to get the steps to get started.
We are looking at the steps to create answers that fulfil both requirements for a user story, whilst also catering to the user journey.
Here, we explore how best to utilise the User Story Mapping methodology to help define your path. We also have the added bonus that the first two steps instantly reward in their own right.
The first two steps can be very rewarding. Firstly, planning the map will give you a pathway to the point where you can start writing user stories or journeys.
Secondly, the end result is a visual chart showing the structure of your stories. This will give you the steps you need to take for development.
Here is another way to approach User Story Mapping in three steps.
This is a relatively quick way of getting to a point where you can start development work.
The start of a user story map on FeatureMap
Hosting your Story Mapping Session
Because User Story Mapping can be complex, it is important to have a framework for the session. It is also important to explain what User Story Mapping is and describe the process.
Start with tasks where the team thinks about the product, users, development, and personas.
We start by brainstorming every task that users will want to address when using the product.
Task each participant to write down steps in your cards, every step will need to cover from the users first engagement to the conclusion of the users interaction. Encourage the team to think of these as actions not features.
It’s okay for each individual on the team to focus on other user journeys. For example if we take an app, someone may do a customer, and another may write about a copywriter, whilst the developers may think from the perspective of the administrators.
Top Tip: Writing them so they start with a verb is a good technique.
Encourage people to be creative and try to cover tasks and steps wide, but not deep. This part of User Story Mapping is about breadth not depth.
Start posting all cards and tasks in one large map.
That’s fine if you have duplicates. Just group them together, and these should sit beside each other on the line (not above or below).
As you expand and get into the swing of it you can easily drag and drop and delete if needed.
The beauty of using digital software for large collaboration tasks such as this allows you and you and your team to easily edit, expand and develop your map all at the same time.
This first line is the user tasks, and they form the backbone of your story map.
Then we organise these tasks into wider goals, and arrange them in order of completion.
These groups are known as “epics” or “activities”.
As facilitator, you can walk along the line of tasks and ask where the team think the splits are between each group of tasks, and what each group should be called.
For example, if you were building an app for an app to arrange your movies, you might group user tasks into epics like this:
Browse DVDs in collection – epic
View flat list of all DVDs – user task
View DVD cover thumbnails in results – user task
DVD Spec Call – user task
We can then move into the Prioritisation exercise, further developing the user story map.
This is the stage where you start writing in the details, building up the tasks and redefining tasks.
This may include adding tasks, merging tasks or separating tasks.
It is important to detail the tasks enough to remember in the future. After writing all the tasks, you should have a comprehensive map by this stage. Task your team to go over each line (now defined as Epics/activities) and ensure you have everything charted. This is where the User Story Map will become easier, as you will now have a visual chart of a defined product. Here you can move to the next steps.
Now you are ready to start prioritising the user stories on your map. You can start adapting and moving your tasks to sprints, also known as versions for your product.
A completed user story map is the perfect centrepiece of any product discussion with stakeholders.
How it works is simple.
First, identify your personas.
They capture your goals, your behaviours and the needs for the end user.
They help you build your story map and give it life.
The personas should always be kept in mind when you add features to your board. Personas can naturally be real people or groups and made up.
The next step is simple.
Understand the user journey.
Take those personas and map out your product with each feature identified as a goal.
Break down each goal into a set of consecutive activities. It can help if you line up these personas to each of these goals.
Then capture each requirement to help achieve that user goal with the help of the stakeholders.
You should be able to formulate all the user stories and the acceptance criteria of what you want to build. Add as many details as you wish to each feature for your team to fully understand the goal.
Control your map, add details, add status, aggregate and take control of your backlog.
You can add with future map annotations and estimate your features, time, budget or any other custom status.
Your team can collaborate on each feature by adding comments and tagging one another.
You can also add a set of different colours to help organise your map.
Once you have completed mapping your user stories journey, you will then be able to prioritise your backlog.
Each feature needs to be mapped to release, and the Golden Rule is that each release needs to be a valuable product slice across the user journey.
Finally, do your last steps.
The most important features are placed at the top.
You’ll wish to start out simple and expand on the functionality of your product by adding new product slices.
These product slices can be converted into MVP’s or Sprint’s. With Feature Map, your product can evolve constantly and cards can be moved around by simply dragging and dropping.
You can also aggregate the values of each task on your map and be able to see how long in time or how much in budget each slice and goal may cost.
You can finally eradicate your long list of features, your overwhelming sprint lists, and your misleading Gantt charts.
A story map is the perfect tool to communicate your product vision with the members of your team and non-technical stakeholders. It beautifully pulls together the big picture and allows you to prioritise your product and progress while not forgetting the details.
Once you are happy, you can share your feature map board to anyone. Or you can invite your own team to collaborate further. Additionally, you can integrate with JIRA.
This is a project manager’s backlog for work to be completed on the application to find and purchase audio files, and mp3s. This is a snapshot of the tool under development with it’s MVP defined and work midway through it’s first sprint.
The tool was picked up by the new team as it had stalled, the new team used FeatureMap to define the MVP and continue forward.
This is a fun tool that one of our developers created to help them go shopping for Christmas. They literally created a list of people, ideal gifts and a process to keep on top of making their holidays stress-free.
It’s a fun map, and shows that you can bend FeatureMap to really cater to all sorts.
This is a map that a project manager and marketer created to help them identify a workflow and the requirements. Instead of a MVP and sprint, they operated with a very human “Must Have, Need and Nice to have” flow, allowing a bit of freedom while helping one another adhere to a set of rules.
It’s a step away from the usual design of what FeatureMap was made for, but as we said at the start. FeatureMap can be a canvas and only limited by your design.
Moviebuddy has been our go-to example for years. It’s from a product owner’s perspective, but also caters to the entire team.
MovieBuddy is an application to build a list of your movies for record keeping. The map expands, both through sprints horizontally, but also vertically it explores new features, sections and upgrades.
In the map you can see how it grows from being a simple record keeping piece of software, to a software for sharing, compiling automatically, finding new recommendations, complex listings and integrated wish lists.
Take a look and it may just inspire you.
So now its your turn…
You have some examples, some inspiration and hopefully some ideas.
If you’ve made a map, or a new design, reach out to us and share with us the map and template.
One beautiful benefit of FeatureMap is having maps shared with us and seeing the new and wonderful ways that imagination has been captured and put down into a map.
Creating a product map can feel intimidating, but with the right tools, it can be completed in no time. A systematic planning process and the right tool can get your project plan mapped out and finished in less than an hour.
A product map answers three basic questions:
What activities do you need to do?
Who will do these activities?
How long will these activities take?
It’s super easy, and it’s even better when you bring a team along with you to get started.
So how to start?
Step 1: Define your product
A story user map can be used as a method for visually outlining your roadmap for your product.
You will need to think of your product in stages, from high level to detailed level. Break your product down to varied groupings, then into steps, and then into further detail. Turn these steps into cards.
Product owner, testers, technical lead, customer support, architect, developers, UX/UI designer, sales and marketing, etc. All have their own techniques and requirements which will help you create your map.
With the questions above, what, who, why.
Step 2: Build that Map out.
If you are brand new to user story mapping, we have a short and sweet exercise. Let’s take a simple real-life example of “getting ready for work”.
Start with the goal. What is the story map about? What are you trying to accomplish? The main overall purpose.
Second, list your main stories, your main tasks or activities. From left to right, insert the main steps of the story map that need to happen.
Move on and detail each main list – column by column, left to right.
In the case of product features, the layers can be then developed and then bingo bango. Done.
In a simple step you have your Product Map of high level tasks.
Product Map complete.
And it’s only step 2… granted the product map would have been done as soon as you applied your main stories and really its more like step 3 if we need drag out tasks, but really… User Story Mapping as a tool for Product Maps offers a value you can only understand once it is underway.
Step 3: Now you have your Product Map – Let it breath!
Story User Maps are ideal for allowing a team to design out a product feature and reduce the need to go back halfway through development because XYZ requirement. Let the project develop, evolve and change into larger, bigger projects or features.
You can develop and maintain any feature creep by creating new cards and assigning them into new sections.
You can add new requirements and manage the product map by assigning times, values, budgets and aggregating those values to the higher level cards.
The product map can become the defacto aid and tool in all your roles as Producer or CTO!
When building your story map approach it from all roles, if alone think about each responsibility in an order and feel free to create duplicates to then merge later. It’s about going with the flow and giving creative freedom to fleshing out a detailed product map. You can always edit, merge, delete in a later step. Due to their different foundations and interests, all roles have valuable points of view. As well as when working collaboratively with a team, everybody has an unmistakable and common comprehension of what they are about to build together.
As an aside, for further reading, we covered a series intro to story mapping with a basic run down and a simple exercise taking you through the morning tasks and making a map that may help, also don’t forget to check out some good practises in going from Idea to MVP.
We have a two examples below.
One is the Audio Finder Project, a board finished, with MVP defined, sprints defined and using some aggregation on the cards. A good example to see a finished map.
One is the App for Lending Electronics, a board and map which is in the stage of “undergoing fine-tuning” and shows an example of half the map with tags and status applied, while the other half is still in flux. A good example to see a map undergoing evolution.
If you want to give making your product map a go, quickly, check out FeatureMap and start for free.
User story mapping can allow your team to see and understand the product from a user-centric design. You can see the bigger picture of the product, help the team identify gaps and dependencies, and give the first framework of a shared understanding between your entire team.
A finished FeatureMap Board should have your entire product outlined. The team will have sections separated, and you’ll be scheduling and planning the outline of prioritized stories into sprints and releases.
In this article, we will share how to gain a better shared understanding of a map by utilising the feature of aggregation.
In short, it is the option of aggregating values. On each card you can assign a status, estimation and a budget. When you assign the aggregation option to a header card, the card will gather the values of all sub cards and calculate, dynamically, the overall status or number.
A beautiful map, full of information, which can be daunting, but with ease you can see if the product development has any issues just by looking at the aggregated dynamic values on each of the layer headers.
Let’s break it down.
With Status, you are able to assign to a card, displaying a coloured icon on the main map. Great for that easy acquisition when viewing the larger map.
The statuses you can apply are: Todo, Ongoing, Done, Cancelled, Blocked.
With aggregation, you can apply the option “automatic (aggregated)” on your header cards, and the header card will a value by priority to display allowing the team to see each header, and associated higher task status.
A quick glance at a busy map can be even quicker with good application of status icons, and aggregation allowing you to identify issues and solve them quickly. This is one huge advantage for those busy product owners or leads 😇
The priority for aggregation display is by importance: Blocked -> Ongoing -> Done.
When a card is set to “To-Do” and “Ongoing” are is aggregated as “Ongoing”.
When a column or layer has a “Blocked” card, this takes priority and is aggregated as “Blocked” as to draw attention to issues.
When all cards within a column/layer are done, the aggregated value draws “Done”.
The status “Cancelled” is ignored.
The header card (groups) Sign Up has been set to an automatic (aggregated) value.
The sub headers (lists), Sign Up and Registration are also set to automatic (aggregated).
The cards in those columns have all be seen set with “Done” status.
The value will dynamically be displayed based on the values of the cards within the sub-cards.
In this case, FeatureMap draws the values from Register Onlineand Email Confirmation.
Both are “Done”, so the value aggregated is “Done.”
Budget and Estimation Aggregation
The task status is not the only aggregation option. You can also track your assigned values of budget and estimation.
When you assign numbers to a card, and then aggregation to the header. It will draw vertically to each header group and list or, if applied to a layer header, it will draw horizontally to each layer. This allows you to see the overall bigger picture, but also a specific collection of times, costs or the main status of the project.
In this FeatureMap we are utilising Aggregation.
On the User Management Section, we are not aggregating status instead we are estimating the time it will take for our developers to code the described section.
You can see the Dashboard Options Card is estimated to take 15 hours, and the Dynamic Windows Card is estimated to take 20 hours.
The header above – Dashboard draws those numbers and calculates both, giving us 35 hours. At a quick glance, the team now know the Dashboard feature should be done after 35 hours.
This aggregates higher to the USER MANAGEMENT header as well, showing us the value of 76 as it draws all estimations in it’s sub lists of Dashboard, Interact with Review and Social Media Elementals.
Customising the Aggregation Options.
On both Estimation and Budget, you can rename the labels of these fields and assign units.
If you decide to do this after the fact, worry not, you can assign the field settings to a single card, or all cards on the map when editing the options.
To edit, open up a card and click the grey cog wheel next to the Estimation or Budget field.
Here you can rename the fields, and assign units.
Units available are:
Apply to all cards please, and let my map be beautifully informative.
Vertical or Horizontal
Aggregation can be applied horizontally or vertically.
When you apply it to the Group and List Headers (Vertically) the aggregation will be drawn from the entire column, spanning every sprint or value.
As such, it is much more common to see the aggregation applied horizontally to see the Sprint status.
A user story map need not be static. Teams can update it with findings from research spikes, revised estimations, and user feedback from sprints and releases. The story map can also be used as a visual roadmap to communicate both the planned work and the work that remains.
So if you find yourself as a product owner or project manager wondering the status of your developers, and you want to avoid it interrupting them distracting them or holding unnecessary meetings, the aggregation tool is invaluable for your management.
It allows your developers to keep you updated while allowing an optimal level of communication. Maybe they’ll get more done? 😀
Give aggregation a go, you’ll be surprised how much control it gives to your map. You can access aggregation options with a Premium Subscription, or with the free sign-up trial.
As a product manager or product designer, you’re constantly thinking about how you could improve your product further.
Most of the time, this means building new features, or improving existing UX.
With FeatureMap you can build out your maps, get a visual broad understanding, but what about supporting your next steps?
How do you know if the features you are planning to build are what is going to really drive user value, while pushing your company closer towards its revenue goals?
You can use prioritization frameworks, of course but first and foremost you should…talk to your customers.
And Teresa Torres, a renowned Product Management expert, wants you to talk to them more often!
Let’s see how you can recruit more users for your interviews without spending more time and effort on it – and get better results from your product delivery efforts?
What is Continuous Product Discovery?
Continuous Product Discovery is a mindset of developing a weekly cadence of having conversations with your customers.
The term has been coined by Teresa Torres, an authority in the field of product management, who recently published an eponymous book on that topic.
The expectation that you will start talking to your customers every day or even every week, if you’re not talking to them at all now (or once in a blue moon) is a bit like going on a crash diet – an extreme change that is not likely to last.
Continuous discovery implies a continuous improvement mindset – if you talk to your users quarterly, take a small step and talk to them monthly. If you talk to them monthly – try talking to them bi-weekly.
Now – you may be asking yourself – why bother to increase the frequency of talking to your customers at all?
Why is Continuous Discovery important?
We make product design decisions every day. But we talk to our customers every…6 months? What happens in the meantime?
You’re more likely than not to work on features that nobody wants, or that the users are likely to find confusing.
Learning from user behavior only after you have launched is very expensive. If you find out that the feature you’ve just launched was a big mistake and you basically need to go back to the drawing board and redo it – you’ve already wasted the precious time and resources.
This could have been prevented through exposing your users to the planned features at the stage of paper sketches – making the whole process easier and cheaper.
Escaping the “Build Trap”
Continuous Discovery also helps you to understand your customers and users a lot better, thus avoid falling into the ‘build trap’ – a situation where the product team is stuck in the cycle of building and launching features, without giving much thought to the outcomes.
This term, in turn, was coined by Melissa Perri, an author of another great book for PMs on that topic.
The Curse of Knowledge
Another reason why you should employ Continuous Discovery is our “curse of knowledge” as PMs.
We are experts, but our customers are not.
They are not familiar with our products. They don’t know the ins and outs of our interface. What seems “so obvious” to us may be total rocket science for them.
In consequence – we make product decisions that are not good for our customers, from an expert point of view.
Validation mindset vs. Continuous Discovery Mindset – it’s cheaper
PMs tend to have a “validation mindset” – they build things, and then A/B test them to check if the users are getting them. This mindset, however, is very expensive.
Continuous discovery mindset, in turn, helps us test our hypotheses a lot earlier in the process – before we have built anything.
When we get feedback at an early stage, on “paper sketches” and half-baked ideas – it’s faster, easier and cheaper to iterate.
This is what we call the co-creation mindset – where the customer is actively involved in the feature creation process.
You shouldn’t ask customers what to build
A common objection to continuous discovery is that “customers don’t know what they want.”
You may recall these famous Steve Jobs quotes, or even Henry Ford’s famous “If I had asked people what they wanted, they would have said faster horses.”
This sentence is actually quintessential to explaining the common misconception about Continuous Discovery. You should never ask your customers what they want. Your customers are not aware of what’s possible to do with technology.
That’s why you shouldn’t ask them what to build. But you should totally liaise with them over what you decided to build early, to get feedback and see if they see it as easy to use, valuable or important as you (once again – the curse of knowledge is a thing!)
Who should do Continuous Discovery?
Hopefully, if you’ve reached this point in the article, you’re at least to some extent convinced that you need Continuous Discovery.
But who’s supposed to do it? Do you have to hire a product researcher?
You will feel relieved to hear that, according to Teressa Torres, the answer to that question is “no”.
The team responsible for Continuous Discovery should be the same as the team that is building the product, on a weekly basis.
You don’t want a hand-off between a discovery team and a delivery team. Your delivery team should be talking to the customers too.
The product “trio” is the minimum team that is doing discovery. They should focus on having small, but frequent touchpoints with the customer.
We need to do research in a way that discovers customer value that drives business value.
How do you discover features like that?
Opportunity solution tree helps you find opportunities that increase financial metrics by increasing customer value at the same time:
Ok, so now you’re probably wondering…how on earth do I get my customers to talk to us, especially in the busy B2B world?
Problems with Continuous Discovery
Apart from finding the right people to conduct discovery, and finding time (and motivation!) to do it consistently – you also need to find the users who will want to jump on a call with you.
Filling your calendar with customer interviews may have been a challenge, but it is now becoming increasingly easy with digital adoption tools that can be used to recruit users for discovery calls on autopilot.
How to recruit users for Continuous Discovery?
How to fill your calendar with user interviews without even thinking about it? You need to ask your users when they are already engaging with your product:
You can do it directly on your website, by showing a popup with a link to your calendar
You can get your customer-facing teams to recruit customers for user interviews – e.g. your Customer Success or Customer Support teams.
Or – if your buyer persona is the same as user persona (e.g. in B2C, or SMB-B2B) – the best way to do it is inside your app.
Make it in-app
Your users are most likely to respond to your bid for connection – and accept an invitation to a user interview – after they have successfully accomplished something using your product.
You can do it by building reactive in-app experiences that appear only when a custom event has been triggered by the user:
BacklinkManager asks the users to jump on a quick, 15-minute interview after the user has launched their first link building campaign.
As you can see in the example above – offering a small incentive in the form of e.g. an Amazon voucher, or a discount on your annual subscription or upgrade – can make it more likely that the users will book a call with you.
Make it relevant
If you have a more complex SaaS product, it’s likely that you cater to different audiences and personas. Using segmentation will enable you to reach the right audience.
You can then invite a specific segment of users to interviews focusing on a particular problem you’re trying to solve for this specific audience segment.
This is why you should use user segmentation to trigger interview requests.
With tools like Userpilot, you can easily segment your users both by demographic and behavioural characteristics – e.g. by user attributes such as plan, or by the role in their organization, or by custom events such as e.g. performance of certain actions in app (and the number of such actions) or the use of certain features.
Make it timely
Time is also of essence. You don’t want to invite a user to an interview after they have just failed to complete a certain task, after they’ve contacted your support about a problem or a but that hasn’t been successfully resolved yet, or you have an indication that they are unhappy with your product or service based on their low NPS score.
In such a situation, the user will be very unlikely to respond to your invitation to an interview, and it may even frustrate them further (as the in-app invites inevitably interrupt their workflow).
Hence: you should make sure you excluded these users from the audience you’re targeting with your in-app experiences, e.g. by excluding users who have not performed certain custom events, have contacted the support a certain number of times in a specific time period, or have a low NPS score:
You can use NPS as a triggering criterion in Userpilot.
Ways to invite users to a Continuous Discovery interview in-app
There are different UI patterns you can use to invite users to a continuous discovery interview.
The one we showed above – called modal, is the most popular one, but you can also use a more subtle slideout:
Or a tooltip highlighting a specific element on the UI, if you want to collect feedback on a specific feature:
Or a banner sitting on top of your screen.
You can build these invites completely code free with several onboarding tools, like Userpilot or Appcues.
Best in-app Continuous Discovery tools
The banners, modals and tooltips inviting user to a discovery interview can be built without coding in Digital Adoption tools – however, some of these tools are more useful than others for Continuous Discovery.
For instance – some digital adoption tools such as Walkme or Whatfix are used for employee onboarding on third party apps such as Hubspot or Salesforce rather than building in-app experiences for the end users. This means they are more complex than necessary and have a significantly higher price tag than onboarding tools.
When it comes to value for money, the best product adoption tool for creating user discovery interviews is Userpilot, followed by a more expensive Appcues. Userpilot will be your best choice if you need to build in-app experiences code free in Responsive Web Apps, but if you need Salesforce integration, Appcues may be a better option.
For mobile apps – Pendo is currently the best option on the market.
Continuous Discovery can help you save a lot of time and resources in the process of building new product features. And it’s possible to recruit your users for discovery interviews on autopilot, using product adoption tools you may already have implemented for user onboarding.
With a little bit of foresight and segmentation, you can fill your calendar with user interviews automatically, and foster these good Continuous Discovery habits.
About the author
Emilia is Head of Marketing at Userpilot and a product marketing enthusiast. She has experience of working with several SaaS businesses as a marketer and a co-founder. Her passion for content marketing, SEO and SaaS products led her to build Userpilot’s whole content ops, hiring system, and documentation from ground up.