Using Customer Development on the Customer Development Process

Earlier in November, I started out on a journey to see if there was an opportunity to build a product that would help companies in being a lean startup. The thought was that with Eric Ries’s book flying off the shelves and the lean startup community exploding, there would be new problems to be solved. Thanks to a nudge from Sim Simeonov and a few consulting opportunities brought my way, I felt like there was definitely something there. Like any startup, once I got outside the building, I learned some harsh realities:

1) Most people only pay lip service to lean.

Painful, but true. In both casual conversations in our community and full blown custdev interviews I found the full spectrum from strict implementers like John Prendergast and Matt Mamet (coincidentally co organizers of the local Lean Startup Circle Boston) to people who claim to be lean and think it has anything to do with how little money they spend (names withheld to protect the innocent).

2) Lean is a hands on activity.

The key to lean really is the human interaction; knowing when to ask an interviewee “tell me more” or deciding what analytics to deep dive to match up against your anecdotal discussions can’t be productized directly. It’s also risky to outsource since it’s so core to the future of your business; no amount of meetings, notes and summaries can compare to being there and doing it yourself. There’s huge opportunities to teach companies how to become lean, but I’m passionate about building a product, not a services business and I’m not sure most companies are ready to invest in lean (see 1).

3) Small startups are more likely to be lean and less likely to need process.

Part of the challenge of the adoption curve of lean is that it has most strongly permeated the zero stage entrepreneurs; they’re the ones with time and motivation to watch the videos, read the books and stay up on all the blogs (which has come a long way in the last year or two since all we had was the Four Steps to the Epiphany to go on).

Unfortunately, those people have little to no budget and because of only having a few people on their team, there isn’t much of a need for tools. Everything can be done ad hoc when you’re that small. The most common behavior when you have 5 or less people is to remove your headphones during the work day and share your findings immediately with everyone on your team.  This is effective until you grow to the point that everyone doesn’t know everything that everyone is doing (usually around 8-15 people).

So all that meant to me was time to pivot:

I’ve known all along that customer development feeds into product management. Fittingly, this is where I did find pain:

  • Managing product while being a growing, lean startup requires significant discipline. Not all companies have product leaders with this strength.
  • Many companies build up product management debt as they grow and fail to adapt to the demands of a team that passes the “take off your headphones and talk” phase.
  • Multiple challenges arise in engaging all members of a company at the right times in the right way.

My next post explains what I’ve found. Read on to see the big picture potential for a lean focused product life cycle.

Continuous Deployment: Possibility or Pipe Dream?

For those in the Lean Startup world, the utopian version of product development is continuous deployment.  It means every engineer is deploying code multiple times a day, often even on someone’s first day of work.  It’s also exceptionally test driven, reducing risks of bugs taking down the entire system.  While many startups aspire to this, few have succeeded, which is why it was so exciting to have Brett Durrett of IMVU come and speak to the Lean Startup Circle Boston Thursday night.  Brett is VP of Engineering at IMVU, which coincidentally happens to be Lean Startup Guru, Eric Ries’s startup he spent many years helping build before becoming the movement’s biggest evangelist.

{Note: Brett’s presentation was awesome but hasn’t been posted yet. I’m embedding his Lean LA version as a reference until it can be posted.}

Continuous Deployment at Lean LA

View more presentations from Brett Durrett

In a nutshell, continuous deployment breaks down into 3 steps:

  1. Develop a feature
  2. Test it
  3. Deploy it

But why would you do continuous deployment?

The reason for using continuous deployment hits the core of lean startups: more iterations. Whether funded or bootstrapped, there’s a limited amount of time to iterate and nothing speeds iteration like getting new features, site tweaks and updates out faster. Continuous deployment forces you to break down all your features into bite size chunks which can save you building massive features when you can confirm it with much smaller steps. It also minimizes version control issues if no one is working on a long term project based on old code.

It also makes your engineers more efficient. Is it easier to find the problem with freshly deployed code that has 10,000 lines in it or 10 lines? Is it easier to get engineers up to speed on a system that expects them to write a micro feature or build a major piece of the system?  If everyone writes their own test code, you have greater accountability across the entire engineering team (you have to fix what you break) and you don’t have to hire a QA team stuck cleaning up everyone else’s mess.

The Continuous Deployment Process for Engineers at IMVU

After convincing us why it matters, Brett walked us through the process for an IMVU engineer.  Once an engineer has finished building their bite size feature, they walk through all of the following in less than 15 minutes!

1) Engineer runs the test in their sandbox.

To keep from clogging the deployment and testing systems everyone shares, engineers first run some basic PHP tests on their own system to ensure the code is ready.  (Note: they don’t do branches in the repository; the brand in the code instead.)

2) Engineer runs testing on main system

After passing the tests on their computers, they enter the queue for the main testing system for all over IMVU called Buildbot. They have tons of tests so you tag your code based on what parts of the system it affects and what it’s for. This optimizes the right tests to run and which can be avoided. (Running every test would take over 8 hours.)

On average, it takes about 8 minutes to run all the tests needed.  They’ve achieved this speed because they have 40-50 instances running just for testing.  They’ve also discovered that 12 minutes or less is the optimal time to have testing take and keep your engineers happy.

The most common slip at this stage is a missing tag, which means a needed test isn’t run.

3A) If all tests pass, the engineer now deploys the code. 

3B) If any of the tests fail, the engineer reverses their commit.

With the rate the whole team is deploying and testing, their’s no time to have people fixing while they’re in the system. Therefore, regardless of the issue, the engineer will reverse their commit and go back to fixing the problem on their machine and starting the test and deploy process from the beginning.

4) Deployment occurs in pieces

Currently, IMVU (with over 50 Million registered members) has 800 servers in use.  When they deploy new code, it starts out on just 35 servers. This ensures that if something goes wrong, it doesn’t take the entire site down.

5) Testing continues after deployment thanks to the Cluster Immune System

Even after deployment, they’re still testing, just in a different fashion. They’ve developed their own tool called the “Cluster Immune System” which monitors key site (speed, system performance, etc) and customer metrics (revenue, registrations, etc) to make sure there hasn’t been a dramatic change.  Even the best tests won’t notice an engineer accidentally made a blue button on a blue page; the tests will see the button is still there and works, but won’t realize a user can’t see the critical sign up button.

This system runs on those 35 servers they use as a live test bed. If anything goes wrong there, they prevent it from deploying to the rest of the system. If not, it’s deployed system wide to all 800 servers.

An audience member asked about “what if you don’t have massive traffic you can segment to test a new deploy?” Brett said it’s an advantage when you’re bigger, but until then, you may just run at Cluster Immune System to monitor a system-wide deploy.

The best news of all of this?  IMVU plans to open source the Cluster Immune System (CIS) soon.

6) If all CIS testing is passed, deploy to all servers, but continue monitoring

Even after deploying to all servers, they still monitor for anything unexpected. If they see anything alarming, they’ll roll back and remove the feature.

This entire process takes only 10-12 minutes.  Only one engineer can be in the Buildbot testing phase at a time, but as soon as you enter deployment (step 4, above) someone else can enter buildbot.

This process sounds great, right? But it seems so sophisticated…how do you get started? Brett covered that too..

Getting Started – How do you actually do this?!?

Getting started is a different process depending on if you’re an established company or just an infant startup with limited traffic, but either way, there’s great ways to get started:

  1. If you’re a small startup - Start with a sandbox for each of your engineers and just focus on pushing code quickly and in small chunks.  You can develop your testing as things break; that’s how IMVU built their system.
  2. If you’re an established company - Start with production (ie- the last step before deploying code) and automate that process. Start building tests for whether something should be deployed or not.  Work to get the automated tests as good as the human part of the process. Once you’ve accomplished this, keep working backward to continue to remove humans from the deployment flow.  At first, you should err on the side of preventing problems then clean up your tests to be efficient.

Whether big or small, the same key rule applies: Anything can break once. Then you have to make it so the same thing can’t happen again by writing a test for your mistake. This builds both accountability and builds only the tests you really need…one step at a time.

Pitfalls

Like any system, this isn’t perfect. There are challenges both with getting personnel buy in and in scaling this:

1) Philosophy- Blameless systems

It’s not “Ned broke this!” it’s “How did we let that fail get through our system.”  Brett really emphasized this important difference. It’s a philosophical buy in required to really make this work best.

At IMVU, they hold regular “Blameless Post Mortems” to discuss issues that slipped through.

2) Optimize your testing

As you grow, more tests will be required. You should optimize for which tests actually need to be run for a specific line of code (as they did with tagging) and purchase sufficient hardward to make tests fast. IMVU also found they could save a tremendous amount of time simply by optimizing the order the tests run, by running the slower ones first (a 22% time saving).  They also then built in dependency in the testing (ie- if Test B requires you pass Test A to work…make sure Test B runs second).  Finally, sandbox testing of high level issues kept a lot of code from entering their “1 engineer at a time” test system by having everyone be able to test it on their own machines first.

3) Outsourcing doesn’t work well

This sort of system requires a cultural buy in that IMVU found couldn’t be instilled well remotely. It also proved difficult to manage the testing system whenever some engineers were in a different time zone.

4) Complex fails are harder to find

Brett still occasionally finds issues don’t fail during the work day…and being VP of engineering it means he gets the 3am calls about such issues.  They also struggle with MySQL and memcached issues, which has led to separate systems being developed to deal with them.

The key principle in all of this is that continuous deployment is a constantly evolving system. It is not perfect. However, taking it one step at a time will help you build a formidable engineering process that allows your company to move faster than you ever thought possible.

Ready to try to bring continuous deployment to your startup?