During my time as a product manager I was always faced with two things: tight deadlines, and presenting the same information to different audiences.
A typical day usually involved meetings with at least one member of upper management, daily stand up meetings with at least 2 project teams, synchronizing with Quality Analysts on the status of tests, writing specifications…well, you get the idea. In many of these meetings I would have to present the same information in a manner that was pertinent and useful for each person.
After working with different flavors of Agile for over a decade and trying various techniques, the scenario became my life- and time-saver of choice. This was mainly due to the fact that scenarios get to the heart of what matters, by providing quick answers to these questions:
- Who is my user?
- What issues s/he facing?
- Which actions/tasks will s/he execute on my site or app to solve the issue?
The scenario is an efficient, multipurpose tool that any product manager can use as the foundation upon which to build product backlogs and interact with other staff members.
Scenarios in a nutshell
To illustrate what a scenario is, here’s a good example taken from the Gates Foundation, which in 2013 set out on a mission to improve the usability and user experience problems associated with vaccination cards. There are two main users of vaccination cards: parents and healthcare providers. And it turns out that both sets of users face a variety of usability issues when dealing with vaccination cards. So in an effort to explain those problems to the general public, the Gates Foundation created a scenario showing how the cards are often used and manipulated. At each step in the scenario, they point out some of the usability issues faced by users. A snapshot of the scenario is shown below:
As this example shows, a scenario is, the story of how one or more users make use of a product, at a very concrete/basic level.
How I’ve used scenarios in the past
Now to shed light on how scenarios apply in the digital world, here’s an example of how I’ve used them in my past lives…
I was a product manager for a company that was developing an application for one of its partners. The partner would be selling the product to its customers. I was told that I had a few days to whip up an overall vision and present it to the stakeholders which included my company’s sales director, VP of Product, and CEO, as well as the Partnership Manager from the partnering company.
So, after doing some research which included looking through data about the partner’s client base, and checking out other competitors, I got together with my trusted UX designer (every Product Manager’s best friend!) and we sketched out a scenario. Literally.
With pen paper, we set out to illustrate the following scenario:
1) Pierre, a 20-year old Parisian student is heading to Latin America for vacation (Who is my user).
2) He’s really attached to his grandma and wants to share pictures of his adventures with her as he goes from country to country. He’ll be using his smartphone a lot to take pictures, but he doesn’t want to be bothered with having to share them at the end of each day of the trip.
Also, he grandma’s not very tech-savvy so he needs something that will update her regularly without requiring much interaction from her (Issue/Dilemma).
3) Before leaving for vacation Pierre signs up for our product, and in 4 steps (for example) sets up the rules regarding the sharing of his photos so that grandma automatically gets updates, and he can focus on having fun during the trip (Solve Issue).
For each of these steps the UX designer hand sketched:
1) a young man carrying a backpack, standing on a globe
2) Adorable grandma
3) Young man in front of his PC/mobile device setting up the photo sharing rules he wants to use during his trip
We scanned these 3 sketches and put them into a powerpoint presentation. I added a few more details to the powerpoint and within a couple of hours, we were good to go.
This presentation was eventually shown to the stakeholders (VP of Product, sales director, marketing directors, and Partnership Manager) who were able to get a high level overview of the who, what, and how of product. This allowed them to ask me questions, poke holes in the product vision, and also evaluate whether it made sense for their business partnership.
The product vision was eventually approved, with some tweaks, and we modified the scenario accordingly. I then used the modified scenario to present the overall project to the web and mobile development teams. This scenario was also shown to the marketing team to give them an overview of how to position the product. When I started working on the product specifications (user stories) I went back to the basic scenario to figure out the functionality I had to address. While I worked on the specifications, the UX designer used the scenario as reference to start planning out the screens and possible interactions that could be put into place. The support team was also shown the scenario so they could be updated about the upcoming changes, while waiting for formal documentation to be put together.
Those 3 sketches went very far.
Benefits of scenarios
Let’s take a look at some of the ways in which scenarios can help with various phases of a project
Product management From a product management perspective, scenarios are a great foundation upon which to build a product backlog and define user stories. Since scenarios tell a story at a higher level, while user stories tell a story at a more granular level, user stories are a natural extension of scenarios.
Going back to my photo sharing example, I talked about the student setting up his sharing rules in 4 steps. This means that at a minimum I would have 4 user stories in my product backlog, one associated to each step. The more detailed the scenario the easier it is to link each item in the scenario to a given scenario. But this is not a requirement. Scenarios are adaptable and flexible and are there to paint the broad picture.
Upper management/stakeholders For stakeholders, scenarios are a great communication tool that can save them and the product manager a lot of time. Generally speaking stakeholders generally don’t read through user stories because it’s too much detail. They just need the big picture in terms of functionality. They do care, however, about how the product compares to competitors, for example. So for discussions with stakeholders, the scenario can be a good support tool that is used along with other statistics and documentation to show how the product is better than (or equivalent to) competitors.
Developers and designers As a product manager it’s usually best to talk to design and development teams about a new project before working on the detailed specifications. This way each team member can start thinking about design and technical implications. The scenario, once again, is a good way to kickoff such discussions. A lot of good stuff comes up when a scenario is presented to developers and designers. They may have suggestions on what could be improved or done better, pinpointing items the product manager and stakeholders never even considered. They can also suggest alternative ways of achieving the same functional result. And in the event that the product vision is a little dodgy, then the discussion with developers and designers can also serve as an excellent reality check for the product manager.
Marketing and sales Scenarios tell the story of how one or more users will make use of, and benefit from, a product. Storytelling is a key part of the marketing and sales process, so a scenario can work as a great jump off point for those teams to prepare the supporting documentation that they need. A scenario alone will be hardly sufficient because it rarely covers technical aspects, but once again, it works well as a support to explain the user benefits or competitive advantage to sales and marketing
Rules regarding scenarios
When it comes to scenarios there really aren’t strict rules. They are malleable and adaptable, depending on how much time, information, and resources you have. The more time and information you have, the more in-depth you can make them. If you’re crunched for time but would still like the benefits of having the product story, then you can make them less in-depth.
Some people are of the opinion that scenarios go hand-in-hand with personas, with at least one scenario for every persona. This is not a bad idea and is obviously more thorough because it allows you to really dig deeper into user needs. But again, depending on the time and resources available to you, you may not be able to do both. And it’s also essential to make sure that one isn’t stuck in the cycle of creating lots of documentation that doesn’t provide a lot of benefit.
Also, scenarios don’t have to be accompanied by sketches. If you don’t have any artistic ability and don’t have someone who can assist you with that, you can still write out your high level story in words. Adaptable.
Even though I’ve only spoken mainly about my experience in using scenarios for new products, they can be used for just about any type of project. As the vaccination card example at the top of this post shows, they’re excellent for mapping out the user flow of existing products, allowing one to see how users are interacting with a product and the pain points or hindrances that creep up. This can be very useful in analyzing an existing product and determining future product enhancements.
However you choose to use scenarios the key is to focus on:
- Who is my user?
- What issues s/he facing?
- How does my product solve the issue (or how is my product not solving the problem, if you’re analyzing for pain points and hindrances)
Leave a Reply