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.
How did we get here?
Before we dive right in, I think it’s important to note, that we cannot necessarily solve a problem without truly knowing the problem; and, like knowing a person, knowing a problem requires a bit of history. So, let’s start from the beginning.
When designing a product, teams are comprised of individuals, that have developed strong biases towards: methodologies, processes, and the day-to-day customs of doing business. So much so, that they unwittingly attached those processes to a type of, “negative culture,” and develop aversions.
That culture is then blamed for their own poor performance at their past company, and they begin anew, by abandoning those attributes and processes they associated with their past failures, and search desperately, for like-minded individuals who also share the same list of negative processes that they — DO NOT — ever, want to be a part of, again.
TL;DR: If you dated a guy who wore corduroys and he was really mean and cheated on you several times, leading to an explosive and traumatic breakup, you might have an aversion towards dating guys who wear corduroys, for the rest of your life. 🤷🏻
…it’s only natural to look for reasons why there’s a problem, and attribute them to systems, structure, and even things like emails or meetings.
Now, to suffer from this ailment, you didn't necessarily have to perform poorly at your last job, although, to develop this aversion, it’s highly likely that poor performance was a symptom, or a byproduct, to a larger problem and not necessarily a direct factor, to what I call Business Systems Aversion or BSA.
BSA is a state high performers are put in when they reject basic business systems after being in a tumultuous environment where those basic business systems where being implemented unsuccessfully or abused.
This almost always leads to a personal failure, failure of the company, product, project, or a career calamity of sorts.
If you’ve had this happen to you, don’t feel bad, it’s a natural process of growth and should not be anything you're ashamed of.
The BSA Formula
The environments that create BSA are usually: highly stressful, rampant with confusion, or consistently disorganized.
In those cases, it’s only natural to look for reasons why there’s a problem, and attribute them to systems, structure, and even things like emails or meetings. But those things really aren't the problem, they are just the patsy, or scapegoat to a larger problem the employee wasn't able to see, because they didn't allow their brains to process their experiences through a logically sound lens.
Why are systems blamed instead of people? It’s obvious that the reason for this is because a system is a thing and not a human.
Here are the criteria for BSA.
Take a high performer
Place them in a environment of chaos
Give them inefficient leaders mixed with highly competent system creators
Add in high turnover of highly competent replacements who introduce structure
Ask them to perform better, repeatedly
Always ask why things are not working the way they are supposed to
Bombard with meetings
Bombard with emails
Bombard with lack of clarity
Break their will
Tell them it’s their fault
Reject the structure
So, what’s a logically sound lens? During the time you are experiencing this, you won’t really be able find or use one, but if you are strong, you can combat BSA with a few tricks. More about that in a different article.
I will say, it’s not the method that matters, it’s how — and when — the employee uses the method that matters.
Bye Bye Old Job, Hello New Job
So the BSA sufferer will quit their current job and move on to a new one.
Then that new employee brings over their bias, naturally, as expected, with no real fault of their own, to their new job, and thus begins the cycle of rejecting anything that they developed an aversion to, usually things like meetings, emails, and yes, even story writing.
The logic the BSA sufferer invokes is usually something like this, “to move quickly, we need to avoid systems, as they are a hindrance.”
Don’t get me wrong, I’m definitely not pro meeting or pro email, but these are the top two most common aversions I see.
Humans with BSA will almost always avoid communication and most times remove email and meetings as an effective means of communication. I will say, it’s not the method that matters, it’s how — and when — the employee uses the method that matters. I will also say yes, both email and meetings, have been abused severely in the tech industry, so I understand the aversion to them.
Now, remember the old saying, misery loves company. During the hiring process affirmations are sought out, by the candidate and the interviewers alike, who are looking for key words and triggers indicating the new hire will fit in just fine. These may be comments such as, “I love communicating over slack instead of email,” or “Meetings should be done, sparingly.” If the new location is looking for a like minded individual and they share the same sentiment about systems and efficiencies, they will most likely hire that person. This unfortunate result covers many cognitive biases. Here’s a few for starters:
Availability heuristic
Blind-spot bias
Confirmation bias
Outcome bias
Recency
Reject Reject Reject
Now, the employee is in a state of constant rejection to anything related to their aversion, usually a system-based method for gaining clarity and getting work done. Unfortunately, this is a fallacy. Doubly, everyone at the company will adopt that same state, because of the bandwagon effect. And on to a campaign of consistently rejecting structure; that ironically creates the same, if not worse, environment the employee just came from except now on the extreme end of the threshold.
Your Attitude
So, now that you have this background, you are obligated to love, and care for these colleagues, in the deepest and most respectful way. You can’t bite back or lash out. You need to be empathetic and nurturing when you deal with colleagues who are struggling with these biases because you know the source and know why they feel the way they do.
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 — tell them you need it.
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 — wait for a response.
It’s likely, they will say no. That’s okay. If they say yes!!! Pat yourself on the back and move on to story writing.
If they say no, go to step 3.
Step 3 — let it fail.
I know, this is crazy, but how can your team learn, unless they see the results of not having story writing?
Listen carefully, because, even though I said let it fail, I really mean keep pushing for the process, but realize that if the general consensus of the team is that they do not want to fold in a discovery and story writing process, you're going to be fighting an uphill battle. DO NOT MAKE ENEMIES.
So, you don't really let it fail, you follow the biggest opposers lead, by saying, “We need to do some story writing.” Then when it’s rejected, ask the person rejected it, what method they'd rather use to arrive to clarity.
Take their lead and listen. They might be right, and they may have a better method, who knows. Either way, take a back seat and let that person run the show. Listen, observe, document, and most importantly, be respectful.
Anyone can build a product without story writing, but that’s not the focus. The focus is, you want to prove that adding in story writing increases the efficiency and speed of product design, and that story writing increases the quality of the product and the confidence, morale, and accuracy within the team.
Step 4 —Plead your case.
When and if it fails have a retro, and during that retro, express the need to never have this happen again. Also, argue the value of story writing by showing the start and end dates of the project and showing the differences in time spent. This calculation is always in favor of embedding the process of story writing.
In other words, it will be very rare, that after showing the struggles you had led to extreme inefficiencies, and after showing a manager what could have mitigated those inefficiencies, that the manager will opt out of folding in time for story writing in the future.
To successfully show the inefficiencies you must have 2 things, or else you don’t have a dog in the fight.
Metrics or data such as: hours spent, files created, meetings attended, etc.
A deep understanding of the story writing process
Here’s an example argument.
I proposed 2 weeks of discovery.
The team voted against it.
This project was supposed to be completed in 1 month.
This project was complete in 4 months.
We ended up going back and doing discovery and story writing anyhow.
This caused us to add in an additional 4 weeks to the project.
I estimate, had we embedded story writing, we could have finished in the allotted time.
Solution, we add 2 weeks to our schedule for story writing.
Step 5 — Gaining acceptance.
Make sure everyone, from the top down, is onboard and gain acceptance, cross functionally and if possible, company-wide.
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.”
Step 7 — 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 8 — 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 9 — 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 10 — Prep a template deck.
Prepare a deck outline or template to help guide the team through the story writing exercise when the time comes.
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.