My Lessons Learned: Part 2

This is the third part of the My Lessons Learned post born of my experiences at the first Startup Lessons Learned conference on April 23, 2010. The introduction is available at this link:

• Introduction
• Part 1: Startups Aren't Just Midget Companies

Stand Up and Deliver

Anyone who has read any of Seth Godin’s copious writings knows that he spends a lot of time talking about the artist’s need to ship, to get his work out the door. Shipping ensures that what you are doing isn’t just playing around, working for you alone. Shipping is at the core of sharing your work with the world.

It is also core to the philosophy of the Lean Startup Methodology. The Build, Measure, Learn cycle is about shipping.

(The following slide is lifted from Eric’s slide deck)

The key to success with this approach is speed. Not just speed (la de da), but NASCAR SPEED!!!!!! It is top-fuel-dragster speed, it is rocket sled speed, it is speed for learning’s sake. With rapid feedback baked into the process, it is much easier to know where to devote resources and which ideas are not going to pan out. Deliver, measure, fix, and deliver again.

Git ‘r Done

The difference between heresy and prophecy is often one of sequence. Heresy often turns out to have been prophecy when properly aged. -- Hubert H. Humphrey

There were a number of Tweets and commentaries after the conference on Kent Beck’s assertion that Agile Methodology (which has historically focused on delivering high quality code), should be adjusted (perverted in some people’s minds) to deal with the realities of the Lean Startup Model.

Unlike many, Kent didn’t seem to have a lot of angst over this change; he was just adjusting Agile to the reality of startup life. Which when you think about it, was pretty agile of him.

It is my experience that most engineers don’t take to lean thinking very well. They are designers and tinkerers at heart, and are frequently unwilling to release their babies into the world until they are perfect (and sometimes even after that). Trust me, I can sympathize with this, there are deep wellsprings of OCD and control-freak behavior in my gene pool. But for the most part it is counterproductive.

For a number of years Toyota’s Lexus division used “The Relentless Pursuit of Perfection” as its tag line. Most people, especially engineers, read it “The Relentless pursuit of PERFECTION.” But I guarantee you that anyone with a lean background (including Toyota’s engineers) will read it “The Relentless PURSUIT of perfection.” Perfection isn’t an accomplishment it is a goal.

Lean Startup is about the PURSUIT of perfection (defined as product-market-fit). That means that anything that gets the job done quick and easy is the right answer for startup engineering. The technical problems created by this prototyping approach can be resolved later when they prove to be real-world problems and not just inelegant solutions. According to Kent good startup engineers channel Larry the Cable Guy.

--

To keep things easier to read on-line, I have broken this post into 5 parts (including the Introduction). I will post these over the next couple of days. To keep up with postings, you can either check back, setup your RSS reader for this feed, or monitor the #SLLConf hash tag in Twitter (you could also follow me @KurtBCarr)

My Lessons Learned: Part 1

This is the second part of the My Lessons Learned post born of my experiences at the first Startup Lessons Learned conference on April 23, 2010. The introduction is available at this link:

1. Introduction

Startups Aren’t Just Midget Companies

Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. -- Helen Keller

One of the first things that Eric did on Friday was to provide us with the working definition of a startup.

A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty. – Eric Ries

In other words, startups exist to figure out if there is a viable business in the wake of the founder’s brainstorm.

I can’t say that this was a totally alien idea, but I couldn’t have articulated it so clearly. Over the years I have worked with hundreds of companies in pretty much all stages of their existence; from startup to those in the terminal stages of their lives.

I never could figure out how to deliver real value to the few startups with whom I worked. I understood that I they weren’t ready for me; but I didn’t (until last week) understand that the reason I was not helping them was because they weren’t real companies yet. They were business models searching for a way to make money; they were on their journey to something sustainable. I was trying to lock things down for them way too early in their lives (usually with their leader’s active cooperation, since they didn’t understand what a startup was either).

Steve Blank helped me understand this with the following slide (which I have shamelessly lifted from his slide deck)

I have always understood that there is a dynamic in organizations between the imperatives of Change and Continuity. I have also always believed that you have to have both change and continuity in any healthy company ecosystem; though the proportions frequently have a non-obvious relationship to the current state of the organization.

What I hadn’t given much thought to, was the idea that there is a state in which the organization’s health depends upon it being all about change. That state is the startup. I see now that a key part of startup leadership is holding back the onset of continuity until the organization is ready for it; until they have real product-market fit and are ready to begin the “transition” block in Steve’s slide.

The timing of this transition is critical to the overall health of the company that emerges from the startup chrysalis. If you do it too early, the resulting company will languish or die because the “product” that it delivers is half-baked (if that) and has no real market. If it is done too late the company never finds a market beyond early adopters and tinkerers. It might continue to find new pools of early adopters, but it never finds the early majority, it never crosses the chasm.

A lot of my consulting has been with manufacturers of customized capital equipment. While this may seem like a weird analog to internet-based startups, it’s not as strange as you might think. Both types of organizations are loaded with engineers. Capital equipment manufacturers are frequently started by engineers and are born because he had a “better” solution to a specific problem. (This should sound really familiar to most of the people reading this.)

It is interesting to work with these companies, in large part because most of them biff the transition from startup to company. They never really move out of startup stage, it is as if they are still looking for product-market fit even while they masquerade as a real company. To borrow from Harry Potter; they are squibs.

A key component of their sales cycle is “how can I customize this for you?” It is a question that delights early adopters and scares the hell out of the early majority who scream: “Whadda ya mean that it has to be customized? I don’t want some custom thing; just gimme something that works.”

The internal dynamics of these organizations militate against reaching true transition and reaching out to the early majority customer base that is needed to cross the chasm. Some of the engineers come to see their roles as continuing to innovate along the existing product branch (I hesitate to call it a product line) at the customer’s expense while others are content to slide into a role of repetitively shuffling paper and redrawing schematics. The company devolves into a hybrid-extended-startup rife with roadblocks that prevent it achieving the status of a real company.

I sure wouldn’t want that to happen to my (or your) startup.

----

To keep things easier to read on-line, I have broken this post into 5 parts (including the Introduction). I will post these over the next couple of days. To keep up with postings, you can either check back, setup your RSS reader for this feed, or monitor the #SLLConf hash tag in Twitter (you could also follow me @KurtBCarr)

My Lessons Learned: An Introduction

It's so much easier to suggest solutions when you don't know too much about the problem. - - Malcolm Forbes


I had the great privilege of being one of the people on the second floor of the Westin for Friday’s Startup Lessons Learned Conference (SLLConf). It was great just being in the same room with the key thought leaders of this new movement. Kent Beck, Randy Komisar, Steve Blank and Eric Ries were inspirational and clearly deserved their places on the podium. The entrepreneurs who shared their stories and the folks who served on panels all did a fantastic job of sharing.

Now that I’m back in Ohio (I was one of the token foreigners in a room full of Silicon Valley residents), I have found myself reliving and rethinking much of what I saw there. It has taken me a while to integrate what I learned into my experiences but I think that I have gotten at least the MVP version of that integration completed. These posts are the result.

I went to the conference thinking that I was well grounded in the basics of the Lean Startup approach and that attendance would hone the edges of that understanding. As it turned out, my thinking was short sighted at best.

It’s not that I was ignorant of the fundamentals of Lean Startup thinking, but that hearing these fundamentals discussed by some very intelligent, experienced folks helped me transform and internalize that knowledge. I had really debated about whether there was any value in spending the time and money to fly to San Francisco when there was a perfectly serviceable simulcast going on in Cleveland. All I can tell the folks who attended the simulcasts is that I’m not missing either the time or the money.

I first discovered Eric’s blog over a year ago and have been fascinated by his application of Lean thinking to the problem of starting a new business ever since. Having spent the last 18 years of my life working with manufacturers, I was familiar with Eliyahu Goldratt’s Theory of Constraints, the Toyota Production System and Lean Thinking as it applies to manufacturing environments. I have also been following Lean thinkers in other areas like Mark Graban’s excellent Lean Healthcare blog.

Lean thinking has long made sense to me, so when Eric applied it to the organization of companies, I was hooked. The Startup Lessons Learned Conference was another step in my lean journey.

Steve Blank has famously (at least within this community) referred to the conference as a “Woodstock for entrepreneurs.” In its wake, I’m going to respectfully disagree. The Westin wasn’t Max Yasgur’s farm; it was The High School of Performing Arts, the magnet school featured in the movie Fame. We weren’t there because we wanted to watch the performers on the stage and smoke some e-weed. We were there because we wanted to be the performers. We needed to learn how they did it. That said; these are my lessons learned.

----

To keep things easier to read on-line, I have broken this post into 5 parts (including the Introduction). I will post these over the next couple of days. To keep up with postings, you can either check back, setup your RSS reader for this feed, or monitor the #SLLConf hash tag in Twitter (you could also follow me @KurtBCarr)