Coyote’s User Story

ACME Space Program - go ... somewhere!

The directors of the ACME Corporation are throwing ideas at the wall. After a string of missed targets and embarrassing flops, the company badly needs a win.

“We could always launch a new line of safes,” suggests Product. “With all of these security breaches, nothing screams ‘peace of mind’ like a few tons of—“

“But millenials aren’t in-market for safes,” interrupts Marketing. “We need something bigger, more disruptive—“

“—like the portable clouds?” finishes R&D. “They’re nearly ready for production.”

“We can shoot higher than portable clouds,” says Sales confidently. “How about another rocket? No-one can ever have enough rockets!”

Faced with a panoply of contraptions they could build, the directors are struggling to commit. With cash dwindling and time running out, their caution is understandable: any misfire could blow the whole enterprise to the bottom of Calamity Canyon.

More terrestrial concerns occupy the void between the customer’s very furry ears. As Famishus Vulgarus scans the desolate landscape for any sign of food, it’s apparent that the directors holed up in ACME’s board room are missing the point. The one thing their customer needs—the only thing their customer needs—isn’t a safe, cloud, or rocket.

It’s dinner.

Back at ACME, a decision has been made–rockets!–and the team is diving in with gusto. Sales and Product negotiate on range, payload, and timeline; Marketing campaigns to snatch back mindshare in the increasingly crowded commercial-launch field; and R&D tells anyone who will listen about a powerful new propellant. Poor Wile E. is left with his belly button engaging in an increasingly passionate flirtation with his spine.

Products need customers. Long before a rocket can flop from the drawing board into history’s wastebin of unneeded products, it’s worth a candid look at why we’re building what we’re about to build. Paper is cheap.

Let’s give ACME a hand describing the putative need:

A customer catches the Road Runner so they can eat.

It’s all there: actor, action, and motivation, packed and ready for fortune cookie slips, sticky notes, or the product management tool du jour. Contrast with “build The Rocket,” which—while adequate for such an obvious task—tells us nothing about the underlying problem The Rocket exists to solve. Giving our users a face helps us empathize with them, prioritize their needs, and use their motivations to guide us as we smooth out the edges.

Beyond keeping focus on the customer, user stories help product discussions take place at an appropriate level. Sticking to the form leaves no room for implementation details to sidetrack conversation. “How” is conspicuously absent from “who does what, and why.” User stories let us assess value and prioritize the path to success before we dive into specifics. They read well in a kanban queue—fortune cookies!—and they’re cheap to discard. We won’t avoid the detours and complications of implementation, but we can test them in the context of a deliberate strategy.

Product development is fraught with so many threats and distractions that it’s a wonder we ship anything at all. Like so many of the tools and techniques employed in the process, user stories can feel like extraneous paper-pushing. Why bother?

Communication,” of course! User stories don’t guarantee a great product, but they do structure the conversations that conceive it. Ultimately, they are a tool: if they aren’t building shared context and focusing discussion, don’t use them.


ACME’s Marketing marketed like never before and Sales filled up the order book. Product delivered under budget, and for the first time in anyone’s memory an on-time launch was all systems go. Then word began to leak: the rockets, big and shiny as they were, were useless for catching the Road Runner. Everything fell apart.

And while the directors of the ACME Corporation huddle in the conference room throwing ideas at the wall, a lonely Coyote scans the desert for any glimpse of the only food around…

Folks, that’s all.