User Stories
Write with caution
I’ve got a problem with user stories. To help me explain, here’s one I just wrote:
I’ll spoil the twist: this user story is total shit and it’s not the grammar, it’s because the story is a lie.
“As an SMB, I want to fill out….” no I don’t. I’ve never met an SMB that wants to fill out anything, have you? If you have, please send them my way, I’d like to study them in my lab err ask them a few questions.
History was written by the victors and victors are incentivized to recount events in a way that justifies their actions. User stories, it turns out, are also written by a certain type of victor; members of the cross-functional team. “Lie” stories create assumption-based work for the team with no clear benefit to anyone, this is where we can get ourselves into trouble.
It may seem trivial, but I think the language we use to describe user stories contributes to this problem. “I’ll write a user story for that,” can all too quickly become “I’ll make something up that justifies this idea”. My suggestion, ✨document✨ user stories alongside the user data that supports them. The customer can tell her own story, and is often very eager to do so!
Takeaway 1: Approach user stories with a posture of documentation instead of creation. If you don’t have data to back up the existence of the problem, call it a hypothesis and ask your designer to investigate!
For example:
- Lie user story: As an SMB, I want a place to fill out my business keywords, so I can start tracking stats for them.
- Reframed as a hypothesis: SMBs want to fill out business keywords to track certain stats for them.
- Actual story(s) discovered in user research/interviews:
- As an SMB, I want to know how I’m performing locally in online searches.
- As an SMB I want to know which search terms customers use when searching for businesses like mine so I can target them.
- As an SMB I want to know how to improve my ranking for the most relevant search terms to my business.
Notice how the validated user stories don’t mention filling anything out. They don’t even start with keywords! Now that we have a richer understanding of the root problem(s) our customers are trying to solve we can explore a variety of relevant solutions.
💡 Feature ideas aren’t stories
I just made up another user story:
Maybe this feature idea solves a user problem. Maybe is also a synonym for unmitigated risk. User stories that contain solutions should be thrown in the trash. It sounds harsh, but if we want to work backwards from customer problems we have to set aside our initial notions in favour of committing fully to the discovery process. Solution ideas will become relevant later, just not yet.
A few years ago I took a class on listening skills. My first revelation was how terrible I am at listening. Turns out most of us are prone to spend the majority of our valuable listening time thinking about what we would like to say next. The antidote? Become really good at letting your own thoughts come and go without attaching great importance to each one. In short: practice mindfulness. If you’re thinking up solutions while a customer is describing her problems you’re probably not really listening!
This mentality of openness can carry over into the solution ideation phase too. The first idea you have may be a great place to start, but it’s rarely the best idea.
Takeaway 2: Describe the problem the user has, not the solution you (or the user) want to build. If you must start with a feature idea, ask:
- What user problem do we think this will solve?
- How important is it for us to solve this problem?
- Is this the best solution for the problem?
- Are we sure this isn’t a “lie” user problem?
- How can we further iterate on this idea?
A parable on idea generation from “Art and Fear”
“The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”.
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work — and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.”
🕵️ Play the detective
Have you ever gotten a request like this from a customer?
Boom user story! Right? Unfortunately, it isn’t quite that straightforward. Research on human psychology indicates we are remarkably poor at making decisions that further our own happiness and utilize a variety of flawed mechanics to make decisions. This might seem tangential, but I think it supports the notion that many feature requests from customers would be poor solutions to their root problem. “Can you walk me through what you do now to solve this problem?” is a great question to start unearthing insights on the root problem. Dust off your deerstalker Sherlock, the game’s afoot!
Takeaway 3: Dig deeper with interviews and open-ended questions to get past surface level requests and understand the customers root problem.
🏗️ Can I get a little context on this?
This article makes a far better argument than I could for utilizing the Jobs to be Done framework. While I don’t necessarily agree with the author's conclusion that this framework should replace the user story, I do agree that the emphasis on user context is very helpful.
The Jobs to be Done framework emphasizes the problems customers hire our solutions to solve. I find this lends itself well to a problem-focused perspective, rather than jumping to conclusions!
Takeaway 4: Context is key, consider the situation around a users problem to ensure critical details aren’t missed. If possible, take time to develop research informed user persona’s, which pair beautifully with Jobs to Be Done
🤖 Build solutions for humans, not robots
While we’re on the topic of Jobs to be Done I’ll mention one more aspect of the framework; job types. In R&D, if you’ve been utilizing the JTBD framework it’s likely that most of your documentation has been around practical problems. “I want [thing] so that I can do [another thing].” but humans aren’t robots. As explored above, we frequently make decisions with outcomes that contradict our best interests. One way this can be explained is through emotional and social jobs. Below is a short description of all 3 types of jobs:
- The practical job — Does this solve the literal problem I have? (I want to travel from point a → b in 20 minutes)
- The emotional job — How does this make me feel, what version of myself is this solution helping me realize or align with? (I want to feel understood and valued)
- The social job — How does this impact the way I want to be perceived by others? (I want others to see me as professional and intelligent)
It’s easiest to get customers sharing about their practical JTBD, but their decision-making (whether they realize it or not) is often guided by the emotional and social. Why did you just upgrade from the iPhone 11 to 13? Probably not for practical reasons! It’s because the marketing and product teams at Apple understand that customers make decisions based on their emotional and social Jobs to be done.
Earlier this year I interviewed several of our partners who are using Website Pro to offer websites to their SMB clients. Although I never asked directly, one of the emotional/social jobs that came up repeatedly was the desire to feel and appear like a website expert through the entire process. I wonder how we could further design for this JTBD. What does it look like to empower our partners as experts through the copy we use, the visual identity of our platform, and the features we develop?
Takeaway 5: Consider the emotional and social impact of your solution, does it make the customer feel more or less like their idealized self?
✅ Wrapping it all up
- Approach user stories with a posture of research-informed documentation instead of invention.
- Set aside your solution ideas to really invest in the discovery process.
- Dig deep, customers are also prone to jump to their first solution idea, which may not solve the root problem.
- Seek to understand the full context around a user problem with the Jobs to be Done framework
- Consider how emotional and social problems users may be trying to solve in addition to the practical.
