3 Ways Storytelling Can Improve Your Product Development Process
This post originally appeared on my website where I share ideas, articles, & insights about user experience and product development.
There’s a lot of talk about storytelling in these days. But in my opinion, a lot of it is cliché. The focus of storytelling in business has become very out of balance.
Most of the ideas about storytelling in business focus on using storytelling to craft a story for your customer — a story that’s marketing focused.
The lost opportunity in business and product development right now, lies in using storytelling as a tool throughout the entire product development process — not just after as a marketing tool.
The value of storytelling goes beyond communicating with your customers. Storytelling can be a strategic tool with your teams and stakeholders throughout the entire product development process.
Used properly storytelling can help alleviate a common set of symptoms that many teams encounter during the product development process, save significant time and money, and ultimately create a better product.
A few years ago I was working with a startup that had scaled to nearly 75 people. I was tasked with re-designing the header and navigation structure for the site. I think at that point I was also working directly with a product manager, a project manager, a product-marketing manager, the CTO, and the CEO.
It wasn’t actually that complicated of a header and navigation to create. But with that many people involved, it became a multi-week project that included hours of meetings discussing edge cases that I didn’t agree we needed to cover in that iteration. But a lot of the people I was working with were from big companies and were used to dealing with every possible scenario. In other words, the opposite of lean.
I had finished up what I thought was the final versions of the header and the product manager sent it out for review on a Sunday morning. One minor problem though: the product manager provided zero context and simply sent an email to the CEO (cc’ing a bunch of people) and said “which do you like better, header A or header B?” When I finally checked my email Sunday evening, I had 69 emails. Yes, 69 emails. I wish I had a screenshot, but it’s true. I still cringe as think about it!
This is my favorite, yet very sad, example of how a very intelligent team got lost in the details; a team that focused on pixels and not people; a team that ultimately wasted a lot of time, money and energy on a feature that should have been very straightforward.
Why did this happen? And how can you avoid a scenario like this?
In hindsight, I can now see that from the beginning of the project, the whole feature and team lacked context. No one owned the product story.
This experience was a light-bulb moment for me. I had this obvious realization of a key element that so many teams lacked — a product story. This then led me to write an article called ‘Why We Need Storytellers At The Heart of Product Development’.
Four years later, I get inquiries on a weekly basis from people wanting to know how to write their product story and specific techniques they can use to use storytelling in their product development processes.
I’ve been thinking a lot about this recently and wanted to share three ways you can use storytelling techniques throughout your product development process.
1: Storyboarding
Filmmakers don’t normally just start making a movie by getting out their camera and starting to film. Before they hire actors, choose locations, hire directors and other team members, they first take the story or script and storyboard it out so they can get a sense of the key scenes, arcs in the story, and plan out how to tell the story through film.
User experience and product design teams often are quick to jump into software or white boarding key screens. The danger of starting with screens is that you risk getting too deep into the weeds too quickly.
The danger of starting with screens is that you risk getting too deep into the weeds too quickly.
By first creating a storyboard, you force yourself to focus on the people using the product. This forces you to take into consideration many factors that can impact someone’s experience with your product including the physical environment they are in as well as their emotional state and behaviors. As well, storyboarding forces you to see the full experience with your product and not just one specific interaction or screen.
To get started storyboarding, draw 6–8 boxes on a piece of paper or whiteboard and simply sketch out little scenes to represent someone’s interaction with your product. Don’t limit yourself to the screens of the product though; think about what happens before someone even opens your app. What activity or experience triggers them to open your app? Don’t end the storyboard with just the last interaction they’d take on your website or app. If it’s an online store, don’t forget to include a scene for when they receive the package. Or if it’s a dating product, include a scene where they actually meet the person for a date. Consider the experiences that extend beyond the screen.
Get my free storyboarding guide & template here.
One of the key benefits to storyboarding is that it’s very low-fidelity; there should be no pressure or expectation to be doing high-end sketches. Just get the idea down on paper. By keeping things very rough, you lower the barrier to entry and ideally encourage other people to participate and create this storyboard with you.
2: Product Story Statement
Once you have a storyboard in place, you start to shape the experience that someone will have with your product. But sometimes it’s helpful to have a specific statement to represent the core purpose of your product. Sometimes people call this a mission statement, purpose statement, value proposition. I like to call it a Product Story. Call it whatever you want. But here’s why you need it.
Down the road when you’re debating whether or not your product needs a certain feature to be built, you’ll have a purpose statement or thesis that can help frame every decision you need to make. So, if you’re debating feature ‘X’, your team can refer to the product story statement and ask themselves “does feature X help fulfill the promise or goal of our product story?” If the feature doesn’t, then it shouldn’t get built.
If you’re looking for guides for how to create a product story, check out these two articles I previously wrote which provide examples and guidance on creating a product story:
3: Gather better feedback through creating context with story
After you have your storyboard and your key Product Story, you’ll hopefully start the process of actually designing some screens in wireframe format. At some point, you’ll need to get feedback from stakeholders and maybe even other designers on your team.
Storytelling is a critical tool when it comes to collecting design feedback. Before you go and present designs to anyone, you should first formulate the story you’re telling through the designs.
Before presenting designs, you should first formulate the story you’re telling through the designs.
Remember my story about the header design — the one with the 69 email thread? The person who sent the designs out failed to provide any context — the designs were simply emailed out and then the recipients were asked which header they liked best!
Feedback solicited without a frame of reference to a product story will result in feedback that is 100% opinion based.
If you don’t give people a lens through which to see designs or concepts, people will inevitably project their own story onto the designs.
And unfortunately, many times they are not the actual user. As a result, the feedback will be very biased and not reflective of your actual user.
How exactly do you create context when presenting designs? Well, you can certainly use personas. But personas are a bit polarizing and sometimes too formal. You don’t necessarily need detailed personas for your users. But it is certainly helpful to at least cast some characters as you talk people through your product.
If for example I’m looking at a logged in view of a product, I’m always sure to say something like “now imagine we’re logged in a Jessica, and she _____” … in doing this, my goal is to get the stakeholders out of their shoes and into Jessica’s shoes. Simple things like this can go a long way.
Another reason why it’s helpful to use storytelling for feedback, is that if you get your stakeholders thinking in the user’s shoes, you’ll minimize the potential that stakeholders say “well I want the product to do X” and instead, they might start framing their feedback in terms of what Jessica may want. You’ll know stakeholders are user focused if you get suggestions and feedback such as “well, how would Jessica find _____?”
Conclusion
Storytelling is not just a technique or activity that can help you talk to customers about your product. Your entire product development team can use storytelling techniques throughout the whole product development process.
Using these techniques can help your teams avoid a common set of symptoms that many teams encounter including extended budgets, prolonged timelines, frustration from being stuck in the weeds, and failing to focus enough energy on real user needs.
Storytelling is something that needs to be embraced by a whole product team. Contrary to what I previously thought, you can’t just designate a Product Storyteller to be responsible for the story.
The story only works if it is shared and embodied by everyone else who is involved in creating the product.
Therefore, storytelling is a mindset that must be practiced on a daily basis.
By working storytelling techniques such as storyboarding, product stories, and context based feedback reviews, you can encourage everyone on your team to practice storytelling and ultimately create a product people will love.
