Fascinating Customer Stories
When’s the last time you heard someone say, “Boy, that Pixar movie sure was boring”? I bet you never have! Pixar’s animated tales, like Toy Story, Up, and Inside Out, draw in viewers of all ages from the first moment and keep them engaged and excited until the credits roll. Their 22 rules for storytelling describe the “secret sauce” that drives this whirlpool of interest.
Now, ask yourself whether your developers are as excited and involved in their work as they are in Pixar movies. Do they discuss customer problems with vigour and interest? Suggest new creative solutions to those problems? Do they, as one team I worked with did, shout at the screen when watching a video of a user-testing session, cheering for the user to find the right button?
If not, you have something to learn from the creators of Nemo, WALL-E, and Buzz Lightyear.
Making Any Story Exciting
Look at Pixar’s rule 4, the “story spine”:
Once upon a time there was __. Every day, __. One day __. Because of that, __. Because of that, __. Until finally __.
For instance, here’s how this applies to a classic Pixar movie:
Once upon a time, there was a talking car named Lightning McQueen. Every day, Lightning raced as fast as he could and pushed his crew to breaking point. One day, Lightning got stuck in a little town in the desert. Because of that, he tried to race out of town but damaged the road and had to repair it. Because of that, he got to know the small-town residents and appreciate their loyalty and perseverence. Until finally, in the big race, Lightning sacrificed his own victory to help another car finish safely.
Notice what this story does. The “once upon a time” and “every day” sections help you identify with the character. You are probably not a talking car, but there are probably aspects of your life where you are competitive or hard-driving, or you know people who are. Once you’re hooked and empathising with Lightning’s drive to win, you hit a sharp turn in the “one day” section, where his isolation gives him a big challenge to overcome. The “because of that” shows how Lightning struggles with this problem, and you empathise with his difficulties—I expect you have probably been trapped or frustrated by a situation before just like him. Finally, the conclusion resolves the problem with Lightning released and a better person (er, car), and you feel relief and the release of the dramatic tension.
All together, the spine gives you the rails your story can run on to draw the audience in and make them care. That’s what makes Pixar movies so engaging.
Writing a Customer Story
Now let’s use Pixar’s story spine to create a customer story to engage our tech team. An effective customer story:
- is at least believable, and ideally drawn from real life,
- is about external customers, not employees or partners,
- creates empathy,
- illustrates the problem, including previous attempts to solve it, and
- includes a proposed solution (but doesn’t preclude other resolutions).
Like the Pixar spine, this story helps you identify with the customer and understand the pain of his or her problem, then takes you through the struggle to solve it alongside the customer, and resolves at the end with a solution. Unlike Pixar, the resolution isn’t dictated to the reader, allowing for creativity and spontaneity in response.
Notice that what I’m describing here is not a traditional user story, whose format is “As an X, I want to Y, so that Z.” Among other things, the user-story format doesn’t usually name people or admit multiple approaches, both of which are vital for creativity. User stories are, however, very useful at later stages, once the approach is agreed and the team needs execution detail.
Follow this “story spine” to create your story:
- Identify a real (or realistic) person with a name and a believable profile.
- Create empathy by explaining the person’s situation.
- Illustrate the problem in a personalised way.
- Describe your planned solution from the customer’s point of view, but check that other solutions are also possible, including low-tech or no-tech approaches.
Ideally, all or almost all your prioritised work should be realisable as a customer story, with the exception of tasks you do purely for internal benefit, such as those that exist only to eliminate cost or reduce business risk. (If instead you struggle to find any of your tasks that are linked to customer stories—then maybe that’s why your developers aren’t engaged!)
A Real Example
Here’s a real example I created when working with my client Holiday Extras:
Kylee is a stressed-out restaurant manager in her 20s (1. realistic person). The bar she runs is struggling to stay afloat in the pandemic; she’s had to make staff redundant and take a pay cut herself. She desperately needs a holiday to unwind from all the ups and downs of her job. (2. empathetic situation) Now that travel is allowed, Kylee wants to book a low-stress beach holiday in Porto. But her 2020 holiday was cancelled and she waited six months to get refunds for everything, which hit her finances hard. She doesn’t want the same stress again! (3. personalised illustration) We plan to offer Kylee the option to cancel her bookings online right up to the time of her flight, with an e-voucher generated on the spot. (4. planned solution)
Notice that we could have come up with other solutions besides the one proposed, such as delaying payment or offering personal help and reassurance on the phone. Those may or may not be feasible or wise, but the important thing is that the story doesn’t railroad the reader into accepting just one ending. That’s what allows engineers to be creative and engaged in responding to the story.
Can you imagine how your development team would react to a backlog of features, each accompanied by a customer story? If not, try just a few and see how they respond. When you get it right, you’ll see creativity and interest that will wow you.