Startup essentials: release half-cocked features

Who's to blame - from http://manujg.deviantart.com/art/success-blame-failures-172506934If your startup is searching for product-market fit then the life of your company depends on how quickly you can decide, release and learn. To speed the release part of this cycle it is critical that you encourage your dev team to release features before they are “ready”.

The challenge is that this goes against what we learn at university and experience in corporate jobs. In those environments releasing unpolished work can be a career-limiting flaw.

I just got a complaint from a customer about the feature that Jon just released. We need to warn him to be more careful and maybe put him on a less important project. [FAIL]

Adopting this corporate-world attitude will retard your iterations and undermine your agility.

Half Cocked

As a lean startup your primary objective is to learn about customers. You win when you release code and learn something about your customers. It does not matter if the code is buggy or incomplete so long as you gain validated learning about customers. The faster you can get something, anything, in front of customers the better. Therefore you should encourage your team to release, not just commit, early and often, but to release early and often.

What does this mean? For starters you should talk about the minumum viable form of each feature, but this point is obvious. What’s non-obvious is how you should deal with the inevitable problems that arise from a hastily (in a good sense) released feature. Here are some suggested responses:

80% of our users jumped in to use Jon’s new feature. It’s a hit! Jon, could you now put in some time to debug this complaint I just received.

or
Ugh, the feature Jon just released isn’t getting traction. Let’s scrap it and move on. No need to worry about this bug report.

or
Jon, I think the feature you just released needs a bit of debugging to be a viable test. Here’s the complaint I just got.

Flapping in the Breeze

Everyone on your startup’s team should understand that when devs release early they put themselves into a very exposed position. Their work is incomplete. The feature is probably going to break. Some customers may get annoyed. If your devs think that they’ll be blamed when the feature goes pear-shaped then your team has a problem.

A dev who releases a minimum viable feature, complete with bugs and unhandled cases, is taking a personal risk to benefit the company. The entire team needs to appreciate this fact. A newly released feature that still has bugs is a good thing. It means that the dev trusts the team and is letting them help decide how to allocated their time. The alternative, of a developer silently debugging a feature, often wastes cycles on work that does not contribute to the larger goal of customer development.

The key point is that in a lean startup everyone must be doing the minimum effort to generate the most learning. For developer, who’s work product is on public display, there is inherent pressure to fall back from this goal to keep their ass covered. Counteracting this requires trust and understanding across the entire team.

Getting Your Wobbly Bits Out

Here are a few tips for getting to a minimum viable feature faster:

  • Put off for tomorrow what you don’t need to do today. Use your ticket system to log all non-minimum aspects of the feature so that the team as a whole can decide whether or not the effort is justified.
  • Establish a blame free culture. Every one on the team needs to know that they are asking the devs to take a personal risk with every release. And, that the team as a whole benefits from their risk taking so NEVER rub in the blame when there are problems. The fact that bugs exist is frustrating enough for a dev, they don’t need to feel judged in the eyes of the team as well. The right approach is to realize that the bugs exist because the dev is doing it right.
  • Consider and praise the minimumness of a release. This is not to say that devs should not learn from their mistakes and take steps to reduce future bugs. Rather, the entire team should understand that over-polishing a feature is as much problem releasing it with bugs. As the team assesses their processes it is important to ask whether feature releases could both be more viable (less buggy) and more minimal.
Advertisements
  1. #1 by Joel Gascoigne on June 1, 2011 - 3:19 pm

    Great article Jesse. I think the key is to develop a culture in the startup of “put it out, then get it right” rather than “everything we put out must be perfect”. I think it is as true for marketing as it is for development. Marketing requires experimentation to find the optimal headlines, channels, etc. just as development requires pushing things out fast in order to find out what works best. Getting the culture right means that we can maximise “validated learning” in all areas of our startups.

  2. #3 by Ollie Rattue on June 2, 2011 - 4:08 pm

    Great post Jesse. This all makes sense in theory but I find it is often hard to do in practise. One thing I find helps me is to keep telling myself that my MVP won’t have any users at launch. With no users a bug doesn’t matter. With no user a less than perfect layout doesn’t matter. With no users jQuery wizz bang trickery isn’t important. I find this really focuses me on launching rather than perfecting.

    Once launched there is a huge motivation gain. When real users start complaining / suggesting you get a rush to fix / improve your product. You are out there. You are real.

    Definitely agree that there needs to be a culture shift to see developers as ‘brave’ to release less than perfect code rather than irresponsible or untalented. It’s a very good point and a subtle yet hugely important ideology shift.

    • #4 by Jesse Heitler on June 2, 2011 - 4:17 pm

      I agree with you Ollie. And there’s also a difference between bugs that are avoidable with good dev practices like TDD and continuous integration versus those that are a conscious result of putting things out that are quick and dirty. While neither should engender blame, the first category should lead to a discussion about investing time into a process change.

      -Jesse

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s