Death of a startup

From a 2010 showing of ‘Death of a Salesman’ (by brian stauffer)

We (team Wayhome¹) decided to hangup our spurs. Bittersweet, but we’d agreed in the beginning that if we failed to meet certain goals by certain dates, we’d call the whole thing off. I still believe in the crux of our vision (here’s a 105 second video demoing that vision), but being right is neither necessary nor sufficient for success in this racket.

I’ll leave the sweeping post-mortem analysis to my future biographers. Instead, I wanted to jot down a few things I’ve learned.

Win a little every week

When I was the military, we went through a program designed to train us to survive during prolonged periods of isolation—e.g., if we ever had to evade capture. One of things that stuck with me was the advice:

you can live 3 weeks without food, 3 days without water, and 3 hours without a positive mental attitude

I realized eventually that this wasn’t just some boilerplate pep-talk. In survival situations, losing hope (whatever that means for you) can have dire consequences for your energy levels, your resistance to illness, and / or your willingness to endure more pain.

Obviously, launching apps & surviving in hostile wilds filled with wild hostiles are materially different things (no matter what that Silicon Valley executive retreat guru told you), but the lessons about mental resilience are perfectly applicable.

In our case, our morale was at its lowest with long lead-time features. If we were working on something that took a week to build, the change in pace from building to launching to observing was enough to keep things dynamic.

On the other hand, if we were working on a feature that took 3+ weeks, we’d eventually begin to lose sight of the end goal. Morale would decay, work would slow, and before we knew it, we’d run out of steam.

The solution here, as the subheader suggests, is to engineer your processes around your team’s natural tempo. Try to keep the time between right now and the next time you ship code or a feature as small as possible. Even if your milestones feel artificial / contrived as you’re laying them out, giving your team (and your self) a near-term goal to focus on will help keep the positive mental attitude you’ll need to survive.

Move fast, but do it at the right level

Most startup gospels esteem speed over most any other concern in the early stages, while you’re still figuring out what your users want. To that end, any time you’re building something new, you typically want to (a) identify the Most Important Feature of the product you’re building, then (b) build as little as possible to test whether or not users care about that feature. To get to this so-called ‘minimum viable product,’ you’ve got to think fast. And this is where things can get a little murky.

I’ve always liked the military trichotomy of “tactical, operational, and strategic” actions. As a simple example, pretend you’re building a messaging app. The lowest level of decision you’ll likely have to make, ‘tactical,’ includes simple questions like “which color should this button be?”, or “what time should we send this email campaign?”

Operational, the second lowest level, typically thinks about things on a longer cycle than that of tactical. Think product design decisions, like “which feature do we sprint on to get our user engagement up?”

Strategic handles the big, often existential questions: should we add a dating service? Which startup should we acquire?

We found ourselves paying due deference to speed on the tactical level quite often: skipping unit tests (I know, I know), skimping on aesthetics, using off-the-shelf solutions whenever we could, etc. This gave us the self-satisfaction of knowing we were doing right by the rules of building a startup. “Are you moving fast?,” we’d ask ourselves. “You bet,” we’d reply proudly, “we used Zapier today in lieu of building our own API to send emails.”

What we didn’t do enough of, though, was scrutinize the strategic & operational level decisions. That is: maybe we made the right decision to cut sensible corners in implementation, but did we really need to implement the email feature in the first place?

Eventually, we realized we had to repeatedly ask the speed question at the strategic & operational levels. Instead of making the decision to build feature X, then optimizing a thousand implementation details for speed, we should’ve come back to that initial decision periodically & asked ourselves: “what’s our strategic goal here?”

I found the easiest way to shift my thinking on this was a change in wording. Instead of asking “what compromises can I make to build this thing faster?”, I started asking “what’s the fastest possible way I can achieve or validate my strategic goal of X?” In essence, I was forcing myself to continually defend the premise of my plan instead of making the decision once & placing it onto a pedestal somewhere to be spoken of as Truth.

Plan sober, execute drunk

I don’t mean liquor-drunk, but instead a sort of drunk very specific to building stuff: design drunk. If you’ve ever thought to yourself: “self, wouldn’t it be cool if this thing did X?”, then you likely know what I mean. For some, ideating on product features can feel an awful lot like daydreaming.

That daydream euphoria, which I view as a sort of drunkenness, has its perqs. Have some shit work to do? Think about your near-term goal for a little motivation. Trying to brainstorm? Envision what you’re building, get excited, then start drawing.

But as with most of its species, this form of ‘drunk’ cuts both ways. Particularly, the pernicious optimism it brings.

Let’s say you’ve thought of a feature that’s going to change everything. You jot down a plan of work & decide it ought not take longer than 3 days to build. You’re a smarty, so you budget 4 days just in case.

You know where this ends. It’s six days later, the feature’s half-assed & broken, and your hangover’s got you swearing-off Sweet Lady Product Design for good.

You planned drunk, is the thing. You weren’t even really planning. No, with a clinically lethal amount of optimism, you were spinning simple pipe dreams.

If this sounds ridiculous to you, good: you likely don’t carry this particular monkey on your back. But if this rings familiar, I regret to say I don’t have a perfect solution. People often scoff at business-types for coming across as soulless, lacking any passion whatsoever for the thing they’re building. That caricature, I think, is the opposite end of the ‘design drunk’ spectrum. To get shit done, you’re going to have to dip a bit into that end of the spectrum every now & then and manage yourself like a soulless taskmaster. “Is this decision really in-line with our strategic goals? Really? Really?” et cetera.

But don’t over-correct. While disciplined execution keeps the U.S.S. Innovation chugging ahead, it’s the twinkle in the eye of a product person dreaming about the Next Big Thing that serves as a North Star.

Just launch the fucking thing

You’ve likely heard “if you aren’t embarrassed by what you launch, you waited too long.” It bears repeating, again and again.

For us, we saw this as permission to forgive ourselves for mistakes we’d find after launching. This was incorrect, I think. Instead, we should’ve viewed this advice as an imperative to launch a feature before we thought it was ready.

This isn’t for the sake of being able to say ‘we moved quickly,’ but instead to compensate for our natural habit of waiting too damned long. In other words: we knew our shots were always landing a beyond the target, so we should’ve started deliberately aiming short.

Besides: while you might view launching something as a sort of finish-line, rest assured it’s anything but. The real work starts once the product’s out in the wild, so why wait to get started?