Imagine you’ve observed a problem that many people around you experience. Like how, for instance, meaningful home automation is still extremely hard for the everyday home owner to achieve. So, being a smart product manager / programmer / entrepreneur / hacker / designer / innovation-generating-machine, you set out to solve this problem once and for all!
Assume, for a moment, we are going to deploy a software solution to this home automation problem. Some time ago, two major schools of thought emerged for solving software problems:
- Big design up front (BDUF) – Deep analysis of the problem, use cases, conditions, acceptance criteria, functional requirements, user interface flows, interaction diagrams, and so on with the ultimate deliverable of a massive, beautiful product requirements document (PRD)
- Extreme programming (XP) – Immediately start to develop a solution that kind of solves the problem, but without really knowing why, what, and for whom. Put off any robust architectural designs in favor of highly tested, peer reviewed, and simplified code. The deliverable: working software that did some stuff we were asked to do, with lots of passing unit tests
The BDUF approach leads to massive budgets, expensive research, wasteful over-specification, and bloated software which often doesn’t even meet the real needs, which may never have been discovered. The XP approach suffers from constant churn in the code as requirements begin to shift over time requiring architectural design changes and massive refactors to the implementation and UI design, leaving customers clinging to product roadmaps in the hopes their needs will eventually show up there.
What are we to do? How can we describe the home automation problem we want to solve to our engineers, without massive amounts of analysis paralysis or wasteful hacking together a solution as we go?
Our Savior, the User Story
Enter the user story, the venerated artifact of the Agile Manifesto, Scrum, and all things Silicon Valley circa 2010, where we value responsiveness to change over adherence to a plan, iteration and MVPs over big releases and customer sign-offs, and epic ping pong while enjoying Topo Chico over late nights in server rooms.
A very obvious “agile” user story for our home automation scenario might be:
As a home owner, I want to be able to automatically turn off my lights when I go to bed so that I can avoid spending time turning off a bunch of light switches in every room.
We are hopeful that this short, contextual narrative slices through the process overhead of BDUF and the lack of functional clarity of XP. Business analyst-types, inclined to define the complete set of use cases using the Rational Unified Process (🤢), are instead inclined to write stories that leave off massive functional detail in favor of “let the team decide.” Extreme programmers who just want to build cool shit, must now sit in (gasp) meetings, trying to decipher what the hell words like “automatically” mean and how to scope the level of effort.
But the ambiguity, lack of definition, and risk of misinterpretation in user stories is HUGE. So, we evolved techniques for story estimation, story points regimes (e.g. Fibonacci, primarily), story break downs to reduce scope, reprioritization, refinement, reflection, playbacks and demos, design reviews, stakeholder reviews, customer playbacks, feature toggles, and on and on and on. All in an attempt to simultaneously de-risk building the wrong product and but maintain velocity in delivery.
And still, we build the wrong things, overdue and over budget. All. The. Time.
Milkshakes For Hire
So, along comes Clay Christensen with his ideas about disruptive innovation and customer segmentation around “jobs to be done” (or JTBD). I won’t go into depth on this research here, but if you’re not familiar it is well summarized with the following analogy: a person is not shopping for a 1/2″ drill bit, she is in search of a 1/2″ hole in the wall, the drill bit is merely hired for the job of making the hole (for more see this).
In our history of storytelling to describe software solutions, many now try to apply this type of thinking to agile stories. A popular technique is the job story (explained here), where the focus is shifted away from a persona and more on the trigger of a given scenario giving rise to the need to hire something to do a job.
The JTBD-centered version of our home automation story becomes:
When I am tired and ready to go to bed at night, I want all the lights to go out automatically so I can go to bed without worrying about leaving lights on.
Hmm. Alright. We can identify some of the obvious benefits of this format:
- Removes the abstraction of “home owner” which is redundant, irrelevant, and incorrect in some cases (e.g. Airbnb guest)
- Describes the trigger for the action of the lights needing to be off (“tired and I go to bed”)
- When it occurs (at night)
- Less about something an abstract “home owner” wants and is more direct that the lights should just go out automatically
So the way we describe what we should build keeps evolving. Both the structure and context of the “job story” focuses, it would seem, on adherence to a few specific rules for finding product-market fit, including:
- If a product is good at meeting a need, then the need can be expressed as a job that the product is hired for
- A job to be done emerges when the right conditions occur, which is ultimately more important to specify than the persona to whom it is occurring
- Customer motivations, then, are necessarily as much about their need to “hire” something to do a job as it is about their preferences, biases, or membership in a persona like “single female” or “student”, commonly used in the “As a ____” user story template
- Finally, to find product-market fit, one should bias toward first understanding the jobs to be done for your hypothetical target market, then aligning a product as the best possible “hire” for that job
Another Possibility: Empathetic Stories
But can’t we go further than just pointing out a user story as relating to a “job” that someone needs done? What if the ideal scenario is that the job to be done never existed in the first place? Christensen’s theory has several flaws in this regard, most obvious being that the solution provider (e.g. the milkshake restaurant in the canonical research example) is constrained to their existing industry.
Maybe we can do better, with empathy. Empathy–defined as the ability to understand and share the feelings of another–might be something we can employ, when specifying product requirements, to better illustrate the purpose of a given solution. I believe an empathetic mindset causes story narratives to abandon the constraints of existing solutions, markets, and industry norms in a very productive way.
So, our empathetic home automation story would go something like this:
Janice, a mother of two young boys, has just finished paying the bills and loading dishes from dinner into the dishwasher. Her husband, Frank, is in bed already, reading a book as he usually does until long after she’s asleep. Time for bed. As she strolls out of the room, Janice leans back toward the kitchen and says, “Good night,” which causes the kitchen, living room, family room, dining and front bathroom lights to immediately go out. The hall bathroom does not go out immediately as it normally would, since Jake, her youngest son, is in there getting a late night drink of water. The hall light remains on for 20 seconds before fading out, just as an exhausted Janice arrives in her bedroom to find Frank reading, as expected, by the light of the beside lamp, which has stayed on. She enters the bathroom, where a light has flicked on automatically, where Janice brushes her teeth, and washes her face before turning out the light and going to bed.
Here, we learn a vast amount more about the scenario we must design and implement into our solution:
- The software probably needs to “know” this is Janice, so that the sequence is specific to her. One of her kids telling the house good night two hours earlier should probably not result in the same events unfolding.
- A “good night” sequence needs to be programmed to be able to automatically turn off, dim over a time period, and turn on simultaneously
- Some lights should not be turned out, even if “all lights” would typically be turned all at once otherwise
- We probably should have presence indication in the bathrooms so we don’t turn the light out on anyone
So, you can see the scope of our story has positively exploded, but so has the degree of purpose, clarity, and potential value of the solution. We have a rich and contextual example in which the home automation solution can apply in the real world. Gone is the generic categorization of “home owner,” the myopic specification that lights only go out when saying “good night,” and ambiguous terms like “automatic”.
Perhaps most importantly, this story sounds like the script of a Super Bowl commercial! I would wager that the average salesperson or customer success manager would greatly prefer seeing the empathetic version in a release note over either of the previous stories.
Do we all have the imagination and creative writing skill to specify our products in this manner?
I think we must, if we are to deliver products that we love designing, building, and supporting.