The Power of Story Writing
Story writing as a tool for product design and development
The Power of Story Writing
Story writing, as a business system, though seemingly superfluous, is an absolute must, when it comes to aligning and equipping a team with what they need to build software or user experiences. So, why on earth is it so hard to get teams to understand the importance and power of story writing? In this article, you’ll find peace and solace knowing there’s a way to achieve alignment, through story writing, within your engineering and product teams, as a team member.
Who Should Read This?
Designers, engineers, and product managers, who are struggling with aligning teams, cross- functionally; and haven't tried story writing yet.
The Definition of a Business System
There are 13 systems of business. All Designers are Product Designers and if they aren't they should be.
This doesn't mean you are a part of the Product Management team, but you are a leader in the Product Development System. Design should be its own department, just like product. The two come together in this early process to suss out what the product actually is.
Here are the 13 business systems for your own edification.
Enterprise Management System
*Design Management System
Financial Management System
Facilities Management System
Equipment Management System
Employee Management System
Information Management System
Customer Development System
Supplier Development System
Operations Management System
Service Management System
** Product Development System
Improvement Management System
Business System
A business system is comprised of a collection of contiguous business processes connecting workflow together to provide a value proposition that delivers the broader purpose of the Business System itself. When you write stories, you use business systems to gain clarity on what you are building.
I will define 2 Business Systems for you, below.
* Design Management System
The Design Management System conceives, plans, develops, tests and delivers new product experiences.
** Product Development System
The Product Development System conceives, plans, develops, tests and delivers new products and services, as well as obsoleting previously active products and services.
You will see the term Business Systems, often, in this article.
You could have a colleague in one of the roles above, but until they actually employ their tools, or systems, they are not truly a Business System. The same goes for a department. You could have an Operations department, but until the operation department actually deploys their system, they are not really a Business System.
Part of planning and testing means you run exercises to evaluate your concepts. This means, you will indeed, create stories at some point.
The Definition of Story Writing
In the early stages of product design, you and your team will build out stories to help explain the use cases and problems, your product solves. The act of writing stories allows you and your team to clearly articulate the vision of how the product works and it allows you to get an early glimpse of where your ideas about the product, break.
Tools of Structure
Okay, so now that you see how we got here, it’s time to discuss what common tools or systems that are most commonly rejected:
Meetings
Zoom Calls
Emails
Slack Messages
Jira
Confluence
Discovery Phases for Design
User Research
Product Development Process
The two that overlap, and the two we care about, are Discovery and the Product Development Process. Both of these business systems, or tools, contain story writing as a critical component of the product development.
"Trust the process and know that you can customize it according to your needs by retaining the structure and framework of the process, and speeding up and parring down as needed."Trust the Process
Now, I totally understand cultures are different and being too rigid, in the wrong environment, can hurt teams and potentially the company. I am not telling you to change the world, nor am I telling you to fight your team and force feed them a process that they’ll see as bureaucratic red tape. I am only showing you how to get unstuck. Even large scale processes can be trimmed and customized to work for the needs of your team.
I am, however, here to remind you, that no matter how hard you try, it is futile, and arrogant, to take 20+ years of tech processes and snub your nose at them.
That’s asinine! They were created for a reason. Granted, things change, but in our case, it’s safe to assume things like scrum, meetings, whiteboard sessions, and standups, can be — with the right teams — very, very helpful! So, trust the process! The process is like a map in times of confusion.
Stories are the connective tissue of humanity. Without stories, we cease to exist.
Why a Story?
I will assume you know the value of storytelling but for the sake of clarity, allow me to reiterate. Stories are the connective tissue of humanity. Without stories, we cease to exist. So, using them in the early stages of product design and product development, will help everyone navigate the, sometimes confusing, nascent stages of designing something new.
Write a vision. Tell a vision. See a vision. Build a vision.
The Argument of Value
You need to bring in story writing but the team is averse to anything that isn't fast or anything that appears to be, “…adding in more process.”
This is a tough sell, because you are adding in more process. So how do you do it?
Step 1 — Explain the need.
You must first identify a place and time where story writing is beneficial. This is usually after the kick off of a new product.
You need to explain that it will be difficult to proceed unless you take the necessary steps to get there. Document this. Make sure you clearly articulate that there “are phases in product development…,” and you feel the team needs to use those phases, “… to achieve success.”
Step 2 — Back it up with data.
Back up why you need storywriting with data on how it helped in the past at your current company, in other teams, or at other companies.
Step 3 — Champions for the cause.
Be sure to make friends and cross functionally, build support from other departments. No one likes to fail, so this won’t be too difficult. Those champions should have your back when you mention story writing, in conferences, meetings, slack messages, or in conversation.
Step 4 — Trial run or educational brown bag.
To make sure you know what you’re talking about, you may be asked to present a plan, perform a trial run on another project or educate the team on how story writing works.
Step 5 — Slow drip campaign.
Use slack or any other communication tool to post educational articles on occasion, about the benefits of story writing, while you wait for the next project to come up.
Step 6 - Get buy in.
You’ve worked hard and now the time here! Go get buy in!
Step 7 — Educate.
Prepare a deck outline or template to help guide the team through the story writing exercise when the time comes.
Step 6 — Document and add a new policy.
Assuming you have agreement and support, document what took place, and write a policy or rule, showing, “… as a result of the issues with the last project, the company has decided to add in time for discovery and story writing.”
The Story Writing Process
The day is finally here. A new project has just kicked off and the team will look to you, to lead sessions of story writing.
DISCLAIMER
I want to note that, this is intended to get a small part of the entire product design process’ foot in the door. There are many more pieces to this, but starting here, will help you bring in more pieces adhoc, when needed.
Exercise 1 — Goals
Collectively, with the team, create a goal for this exercise. Clearly state the goal, when you’d like to finish, and how you expect to accomplish the goal.
“As a team we will write 5 stories, in 2 days, that help us demo our new software product, by running through a series of exercises that help us extract the value of our product.”
Stick to this goal!!!
You may want to exhaustively list out many goals and pare them down with a prioritization grid like the one seen below.
Exercise 2 — User Segmentation
Now that you’ve created goals for the team. Focus on the who the actual user is.
Do this by asking questions and listing out answers on sticky notes or an online spreadsheet.
Questions to ask:
Who are we building this for?
Who does this product touch?
What is this user’s job title?
What is the user trying to achieve?
Why are they doing this?
How will they do this?
Then create a proto persona. Create empathy maps.
Try Miro for remote exercises. You can also use a spreadsheet for these exercises.
Exercise 3 —Business Needs
Similarly to the exercise you went through for the user, identify what the business needs to accomplish.
Do the business needs and user needs align? If not, how can we align them? The goal here is to have aligning needs and goals.
Exercise 4 — Map the Journey
Through the use of your product, the user will progress on a journey. Map that out with the team and clearly identify the high level steps the user needs to progress through to accomplish the user and business goals.
Exercise 5 — Write the Stories
This day, no one should say the word user. You must now, abandon the term user.
Here is the proper format for a user story.
As a [role], I want to, [task], so that [reason]. Let’s say you are building a tractor for farmers.
Here’s how you’d format a story for a farmer using your product.
As a Farmer, I want to plow faster so I can multiply my crop and profits. As a team, start calling out tasks and activities you know the farmer will want to do with your product.
Exercise 6 —Prioritize the user stories
Prioritize that list.
Exercise 7 — Define Principles
Define some UX, Design, and product principles. Use these principles to help guide you and your team when you are designing.
For example:
PRODUCT PRINCIPAL
1.0.0 High Quality Material
All of GreenBaby tractors provide the highest quality components to make our tractors reliable and durable. When the team talks about cutting costs and using cheaper components, fall back on your principles to remind the team, what was agreed on and what’s inline with your brand and user expectations. Principles are like your compass.
UX PRINCIPAL
3.1.4 Time to Content
Always let me find what I need without unnecessary steps and as quickly as possible. DESIGN PRINCIPAL
1.0.4 Simplicity
Use simple designs that are easy to understand. 
Bringing it All Together
Define Functional and Product Requirements
Create functional and product requirements, based on your stories.
Create Jira Tickets
Create an epic in Jira, create tasks and Jira tickets in Jira, to capture the features needed.
Build your product
Based on your Jira tasks, build out the product!
Ongoing Maintenance
Okay, so the hard part is out of the way, but that doesn't mean you’re done. Make sure to work on maintaining your hard work by revisiting and updating the story writing process at your company, and continuously tout the benefits from that process. When you can, seek out opportunities to re-use your process.
Conclusion
That’s it! I hope you learned a lot and feel free to reach-out to me if you have any issues or need some help.
Follow Jonathan on Twitter or feel free to drop him a line. You can also find him on Dribbble or LinkedIn.
Jonathan Bowman is a San Francisco based Product Design Leader, and accomplished author, with over 20 years of UX experience. He has worked with companies like, AT&T, Verizon, Amazon, Spotify, Arlo, TiVo, NETGEAR, and Virgin. He is currently listening to this song, on repeat. He swims every morning, religiously, and plays sitar.