To Create, You Must De-Story

To Create, You Must De-story

In this weekly series, I opine on how language and content affect the way we understand the products and services around us. I do this for your entertainment and education (and, of course, to remind you that if you’re looking for a freelance copy, content, product, or technical writer… yada yada, hire me).

I have a shameful confession to make.

As a person working in the tech biz, I’ve grown complacent and numb in the wanton reappropriation and reinvention of certain words.

I, like my contemporaries, draw shamelessly from a shared lexicon of sad terms and turns of phrase that permeate the walls of our opulent open-concept offices.

I’ve taken things offline. I’ve circled back. I’ve sidebar’d. I’ve huddled. I’ve even run things up the flagpole to ensure we’ve got buy-in and that all of the stakeholders are heard. I’ve aligned on action items, I’ve collab’d on board decks, and I’ve post-mortem’d more punted OKRs than there are agile coaches who’ve missed stand-ups to host grooming sessions. I even CICD with the best of them.

And while I won’t make myself a hypocrite in criticizing that use of language, there is one loaded word I’ve simply had enough of. Every time I hear it, I erupt into a volcano of opinion and conjecture and angst. Where it used to inspire, it now serves only to irritate, instigate, and infuriate me.

I’m talking about the word “story”.

Wait, What Are We Talking About?

If you’re in the software world, or you’ve watched the first season of Silicon Valley, you probably know what I’m talking about when I say “story”.

For everyone else, here’s the gist.

Not that long ago, software projects were predominantly managed like complex construction projects.

The basic manifest for the project would be established, and bit by bit a complete plan would be built: architecture, blueprints, timelines, budgets, contractors, sub-contractors, and, finally, the beautiful Gantt chart.

The Gantt chart in every way epitomizes this type of build-out: it depicts sequential, descending blocks of dependencies across a timeline which represents each of the major phases, and contributors, of the project.

As a critical artifact of the project, the Gantt chart’s flowing top-to-bottom cascade is the suitable visualization of the project management style aptly named “waterfall”.

Yet, building buildings is hard and takes a long time. That’s largely because missteps in the project can be incredibly dangerous, not just to financers but to human lives, as well.

With that in mind, waterfall in the context of construction makes a lot of sense: its command and control model, with the big design up front, saves not just time but money and potentially lives.

But an app is not a building, and managing software projects with that approach often instead results in other big problems — namely, launching a product into a market that has moved onto another app in the two years it took you to build it.

Avoiding this outcome was the goal of the alternate and more oft-referenced project management approaches of “agile” and “lean”. These methods focus on moving quickly, designing on-the-fly, and applying the scientific method to guess, test, and learn fast.

What Are You On About?

And so we come back to the “story”.

In many ways, the story is as emblematic of agile and lean as the Gantt chart is of waterfall.

A story is quite often the primary “blueprint” of agile development. It is meant to be a concise written summary of a specific user, a specific job to be done, and a specific set of acceptance criteria which encapsulate what the user must be able to accomplish with the software.

Sometimes, stories include mock-ups of a workflow. Sometimes, stories include technical details or test cases or edge scenarios. Sometimes, they may even include other details, like how a user will hear out about the new capability or how much money it will make the company building it.

As those “sometimes” become “all the times”, though, the original monicker of “story” is now quite deceiving.

Whereas the story first began life rooted in telling a simple “story” of a user’s goal, it has evolved into what it was never meant to be: a fully fleshed-out, detailed, bulletproofed, exacting specification.

What Happens

With this shift in the spirit of a story, our “agile” and “lean” processes tend to be more so just that in theory than in practice.

As our companies grow, as roles become more specialized, as we add designers and testers, dev-ops pipers and compliance officers, our stories bloat further.

We start to have approval processes for our stories or, worse yet, parts of our stories. We sit around and draw up mock-ups and hypothesize our stories. The “best” of us test our specification-heavy stories with interviews and discussions and debates.

But what is lost consequentially in this process of returning to a more waterfall-like approach to building software is exactly what was shed deliberately with the waterfall process itself: speed to market.

As though they were complex blueprints, we now spend tons of upfront time obsessing over the act of researching in a vacuum, poring over our insights and our sticky notes and our internal battles of bravado and buy-in.

In doing so, what we allegedly save in developer dollars we instead waste in time spent not learning in the real world. That costs our companies far more in the long run.

The Result

A Stanford University paper published in the journal Science found that publication bias in sciences is increasingly widespread. In other words, even scientists today tend to work on, value, and discuss experiments manufactured to succeed.

Many in the tech industry have developed our own “production bias”: we lean towards only shipping to production things we know will work — or, rather, things we think we know will work.

We seem to no longer apply the most fundamental principle of scientific theory: experimentation with raw materials, in the real world, with real consequences and real learning.

And you know what? We still produce bugs. We still build features no one uses or features used in ways we didn’t intend. And we do so more slowly than needed because we fool ourselves into thinking mock-ups and prototypes in closed environments are accurate indicators of performance in the real world.

Rather, we argue about the design patterns of tables and lists. We argue based on one phone call or one screen share. We argue about “might nots” and “probably shouldn’ts”.

We argue out of motivation for that pat on the back from our CEO or terse commendation from our board or claps from our modest Medium audiences.

We argue for ourselves, not our customers: for what we want or what we think they want. We argue to be the one in the room who is “right”.

And through the glass of the white-boarded rooms in which we throw up our hands and lift our voices in the argument passes the very market we argue to serve.

The Takeaway

One of the truly amazing advantages that software enjoys over other types of products is one we seem to so seldom use to its fullest: the ability to split-test after we ship.

We have this incredible power given to us by technology: we can with but a modicum of engineering effort show a part our product to only a small fraction of our customer base.

We can experiment with raw materials, with real customers and real data. And yes, our changes may wind up being the vinegar to our customer’s baking soda; they may spill out of our beakers and make a mess on the floor.

But for those of us not designing MRI machines and guns, we should strive to make a mess from time to time if it helps us find the right solution faster.

That was the whole premise of “fail fast” in the first place.

We should be spending less time writing design specs and conducting wireframe-clad interviews and more on making informed assumptions, shipping software, and testing in the real world.

In other words, to create we must de-story.


Stories are a great tool for quickly encapsulating a user need and a job to be done, but they shouldn’t become exhaustive specs.

Do the homework to understand the user’s job and the underlying pain, but then build and ship something to at least a few real users in the real world in your real product.

Believe me: those users will tell you what you need to build, and how, faster than your product owners and designers will figure out what works and what doesn’t.

What about you? Any lessons you’ve drawn from this? Respond away. And if you’d like to learn more about me or my business, visit