Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

How To Sink Your Lean Bootstrap #4: The X.0 Release

April 2nd, 2012 · 1 Comment

Just to Recap…
Bootstraps are a version of the lean startup with a 37-signals-esque twist, i.e a lean bootstrap. The goal of a lean bootstrap is to run in the black as early as possible, preferably from day 1. Boostrappers don’t need or want outside capital for the most part, and they are always conscious of the need to validate that they can actually make money doing whatever they are doing.

Basically, if you (metaphorically) placed Rework and The Lean Startup in a blender, turned it to high, then ran the puree through a mumbo-jumbo filter (basically the last 1/3 of The Lean Startup would get removed), the remaining juice would be called “The Lean Bootstrap”.

My Life is Sometimes a Study in What Not To Do

About three weeks ago I released TroopTrack 3.0. It was a huge deal. Here’s a list of some of the major changes in this release:

  • Moved from a single slicehost server to a distributed environment using Amazon S3, RDS, and EC2
  • Upgraded from Rails 2.3.8 to 3.2.2
  • Completely redesigned user interface
  • Re-designed the inbound email server (TroopTrack includes a distribution list server)
  • Consolidated several different features into one and completely re-designed that one feature
  • Switched to Twitter Bootstrap
  • Added very fancy CMS capabilities
  • Switched to an asset pipleline

That’s just a sample. The release took just over a year from start to finish. At the same time that I was working on the release, I continued to support the existing version, and I found myself saying “this will be better in 3.0” a lot. The more I said it, the more customers wanted to know WHEN 3.0 was going live. “Q4!” I said. Then it was “January”. Then it was “February!”. Then I promised March. And March it was.

The release was a total disaster. There were too many things going wrong simultaneously. There were environmental issues. There were problems re-processing all the user uploaded images to give them the new styles. Users were confused by the new interface. There were bugs.

Worst of all, I forgot to take down a “This is a beta site” on the log in page that warned users that beta sites were unreliable, not guaranteed, and not expected to be nice. This totally freaked users out, and it took me a while to figure out why they thought they were using a beta site.

Users got angry. Some threatened to leave. One demanded a refund (I gave it to him, right away – I don’t mess around with refunds). I started fixing bugs, but the requests just kept flooding in. I went from 100 open helpdesk tickets to 250 in no time flat.

It was horrible. At one point I had a panic attack. Had I finally managed to sink my lean bootstrap? Was the game over? Had I created a self-imposed runway and then crashed the plan right onto it?

Um, wait, aren’t you that lean/agile guy?

Well, I’m not THAT guy, but I am A guy. And yeah, I am pro-lean and pro-agile. Heck, I wrote a workshop on it. I spent more than a year helping a midwestern insurance company through the difficult value/culture/process shift from waterfall to agile. And yes, I work at DeveloperTown, where we are totally into lean startups.

That said, there was nothing waterfally about TroopTrack 3.0. It was agile all the way through except for one teensy little detail…

Release Often

I didn’t have to do such a huge release. I could have done these things one at a time, like this:

  • Release 1: Upgrade to Rails 3.2.2 sans asset pipeline
  • Release 2: Roll the infrastructure over to Amazon
  • Release 3: Switch to the asset pipeline
  • Release 4: Re-design the user interface with Twitter Bootstrap
  • Release 5: Re-design the inbound mail server
  • Release 6: Consolidate features
  • Etc

That’s what I should have done. I don’t need hindsight to tell you this – if you brought me your project and proposed a big release like this I would tell you to break it up into smaller chunks and release it one chunk at a time, and I’d be right. That’s a lot less risky.

So why didn’t I do it right?

It takes discipline to release often

In many ways, I have spades of discipline, but not in one: I can’t always resist the temptation to start one feature before I have finished another. New releases of gems and other shiny objects call my name like chocolate chip cookies haunt Snoopy. So, part way through the UI re-design, Rails 3.1 came out and I thought “What the heck?”. And I started on it. Then I got back to the UI re-design, except part way through that I thought “Events would be much easier if I consolidated X, Y, and Z first”. So I started on it. Next thing I knew, the release was huge and, instead of having a small release every two months or so, I was ignoring my users, making promises I couldn’t keep, and, when I finally released the product I had so much in it that I totally botched some critical but simple details.

X.0 releases create a runway you don’t need

One of the key principles of a lean bootstrap is the infinite runway. A runway is defined as the number of months or pivots you have left before you run out of resources to continue operating your startup. There are different types of resources, but the four key resources you need to keep on eye on are cash, time, talent, and optimism. Any decision that puts a cap on one or more of these resources is risky and should be considered very carefully.

An X.0 release is a big, dramatic release. Anything that drags on more than two months is probably an X.0 release and represents a big risk to your lean bootstrap because you are spending your cash, time, talent, and optimism on an unvalidated investment that may or may not work out. The more of your resources you dump into the X.0 release without validating that you are doing something awesome, the more likely it is that a big chunk of that investment is going to be garbage and be rejected by your users.

Optimism is your most valuable resource

I’ve seen crunches in all four of the resources I mentioned above, and most of them can be solved by patience. If you are low on cash, you can just slow down a bit, skip the Starbucks, and be okay. The same is true of time and talent – you can modify your pace to preserve those resources. But optimism is hard to predict and plan for, and emotional deficits can be hard to make up. A bad X.0 release can sucker punch the optimism right out of you like you wouldn’t believe.

If you screw up and get in too deep, back it up if you can or stay the course and muscle through

What do you do if, part-way through a new effort, you figure out that it is getting out of control?

You have two choices: go back to the point where you made your first bad decision and finish just that piece, or soldier through. I vote for going back. If you use a decent SCM and good commit messages, this isn’t usually too hard.

If you decide to soldier through, you need to draw a line in the sand and don’t cross it again. Finish what you started. Release it. Get feedback. Then do the next thing.

There will never be a TroopTrack 4.0

I have learned my lesson. I’m through with big releases. In fact, I’m moving the other direction, back to the way it used to be before I started 3.0. Nightly releases. Small changes. Incremental improvement. Feedback cycles of a day or less. That’s the way I roll.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Uncategorized

1 response so far ↓

  • 1 Re-imagining TroopTrack in a Use-Case-Centric Architecture // May 16, 2012 at 9:27 am

    […] number of TroopTrack users. I just put them through a fairly horrible major release, after which I swore I would never do an X.0 release again, so I need to start this post with an assurance. Please don’t interpret this post as a sign […]

Leave a Comment