Eric Ries Spotted at HubSpot: 5 Lean Startup Insights

Eric Ries of Lean Startup fame came to visit HubSpot yesterday, and we soaked up his input like a sponge. If you're not already familiar with him, Eric's opinions are pretty well documented. Reading his blog or buying his book would serve as a good introduction. Or you could follow @ericries on Twitter. He's been and continues to be hugely influential in the startup world, and we're big fans.

We invited Eric to spend the day with us at HubSpot because, as we've found product-market fit and continue to grow aggressively, we wanted to hear his thoughts on how we can keep applying the principles of the lean startup as we go along.

Once you have a successful product, you need to fanatically serve the needs of your installed base

Pretty obvious, right? One way to view the lean startup principles is as a logical extension of Clayton Christensen's work on disruptive innovation, which emphasizes protecting against attacks on your installed base by remembering to serve their needs first, and to innovate upwards only when it's not at their expense. Meeting Eric in person underscored the similarities between Christensen's work and the philosophy of the lean startup. If anything, it seems like Eric advocates many of the same very ideas that Christensen does, but does so in a way that is more geared toward the engineer than the CEO. The combination of these complementary philosophies ensures that everyone is on the same page, both strategically and tactically.

Innovation is cheap

This is not to say that you don't also need to innovate. Eric suggests that you invest some consistent percentage of your efforts towards disruptive innovation. It doesn't have to be a lot -- 10% or so was the number he suggested offhand. And you don't need a huge team to innovate, either. It's a straight percentage, so whatever size team you've got, take 10% of their time and apply that. Protect your 10% allocation towards innovation aggressively and maintain discipline around truly dedicating it to disruptive innovation. Remember: innovation also serves your installed base, too.

Use your technical debt as an asset

Try to think of your technical debt as a good thing. After all, if you have technical debt, that at least means that you have real customers who are relying on this code. That's great! Now you can borrow time against thatexisting asset to invest in something else.  For instance, you could invest in new features (a good idea) or use that debt to invest in tools and infrastructure that allow you to iterate more rapidly and learn even faster (an even better idea).

At the end of the day, if your technical debt isn't getting in your way, don't focus on it.  A system of 5 Whys analysis and continuous deployment can root out the things that are truly getting in your way.

Make customer interaction routine

This was a message especially targeted to the engineers in the room. It's easy for programmers to get their only customer interactions exclusively via bug reports. And even those are typically filtered to some degree through technical support. Eric advocated instituting a simple rule: Every engineer has to seek out some kind of customer interaction regularly, something like once a month. Watch user tests, sit in on support calls for a full day, visit a customer in their own workplace -- anything to get more direct customer feedback, more often.

Validated is better than done

At one point when we were disucssing the lean startup approach and how it related to the agile development methodology, the conversation wandered to kanban. In kanban, there are commonly at least three columns representing the lifecycle of a user story: backlog, doing, and done. Eric advocated for having a fourth: validated. Forcing product owners to own a validation step in which the measurable goal is assessed can act as a nice forcing function for increasing the likelihood that you'll learn something from each piece of work.