Eat, Shit, Fuck, Die

Mid last year, I was in the process of researching and specifying a massive solution with a team of product managers, and in that process, I came to question and ultimately throw away the notion of “MVP”, or “minimum viable product”, in favour of something a little different.

Why Not MVP?

In start-ups, the MVP as a North Star is a great and functional concept. When the requirements are fairly modest and there’s a ton of leniency and agility for trial and error, building for the minimum works, and labeling your product as an MVP poses no threats.

However, for bigger solutions to bigger problems with bigger stakes and “bigger” stakeholders, I feel the concept doesn't quite capture enough detail to focus conversations during the ideation and research phases. It’s not a bright enough light, and it doesn't guide a scaled flock of shepherds. On the contrary, the simplicity of the “MVP” notion usually distracts more than it helps in this context.

Thus, in trying to better mentally model what exactly to build for a new, massive solution comprised of potentially multiple components (products themselves in some cases), I've come up with something slightly more specific but vastly more applicable.

Forget defining an MVP: instead, define a product that can eat, shit, fuck, and die.

Eat

Although perhaps controversial for start-ups, for product folk at established companies, the notion that a product won’t make money out of the gate is, at least in my experience, a non-starter. No one is going to green-light internal investment in a product if there isn’t a business and monetization plan around it.

Ergo, the first important question to answer is “how will your product eat”? How will it receive unto it its daily bread, or rather, how will it generate and sustain income?

Even for start-ups, this question should be the very next thing answered after “what problem can I solve for the market?”, regardless of whether or not the answer is largely theoretical.

Shit

The next question to answer is a bit counter-intuitive, because you often take for granted its importance. But how will your product shit?

By shitting, I’m referring to all of the necessary functions of your application that aren't sexy and don’t help it eat, fuck, or die directly: accounting and reporting, dev-ops infrastructure, compliance (e.g., PCI, SOX, etc.) — all that stinky stuff that simply must be done, no matter how gross it is.

One big mistake, particularly in small to mid-size product shops, is ignoring the “shit” work. In a bigger organization, though, even a product heartily eating will be on life support post-launch if this critical work isn't done. Worse yet, a bad shitter who eats in abundance will be in even more trouble.

More often than not, making small design conceits up-front by thinking ahead here dramatically reduces the costs and pain of doing so thereafter.

Fuck

Of course, implicit in the product’s worth should be its ability to deliver “satisfaction” to the user and to solve his or her problem. I like to call this “fucking”.

How can the product deliver to the end-user something both fundamentally capable and simultaneously desirable? You want that wow moment, and you want it to hit the spot time and time again — and you also want to have the secret, forthcoming “twirl” waiting in the wings to mix it up when the user gets bored of that.

Die

And lastly, the inevitable: how have you prepared for your product’s death?

This step isn't meant as a defeatist “planning for the end-of-life from day one” but rather a chance to prepare for the worst.

If your product turns out to eat poorly, suffer from constipation, or ultimately lacks in mojo, what can you do to recoup costs? What kind of insurance can you invest in? Can you make it an organ donor by building reusable pieces that help you pivot? Are you prepared to perform the surgery necessary to bring it back to life?

In my experience, even in death, a short, productive life is better lived than a long, useless one.

A Life Well Lived

Ultimately, building a product that can ESFD out of the gate seems like a much more sound goal and a better goalpost — and, importantly, one that doesn't create an argument over what “viable” really means.

Every group in a product-centric business, from business development (eating) and marketing (fucking) through to ops (shitting) and R&D (dying), is accounted for and addressed in turn.

And that, to me, sounds like a better product life-cycle to live — and one certainly safer for work, in spite of its crudeness.