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 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.