The Entrepreneur’s Guide to Customer Development

Brant Cooper and Patrick Vlaskovits have written a new book, The Entrepreneur’s Guide to Customer Development, which builds upon the foundational work of The Four Steps to the Epiphany, while improving accessibility, updating the ideas, and making it more actionable. I believe it is the best introduction to Customer Development you can buy.

As all of you know, Steve Blank is the progenitor of Customer Development and author of The Four Steps to the Epiphany. I have personally sold many copies of his book, and continue to recommend it as one of the most important books a startup founder can read. 

I used to give copies of Four Steps out to my employees, in the hopes that it would instantly indoctrinate them into the methodology of Customer Development. I just assumed that everybody would love the book as much as I did, and would instantly change their behavior based on what they read in a book. You can imagine how well that worked. Instead of that naive approach, I wish I'd had a book like this one, to help me figure out how to get started with customer development step-by-step. 

When I wrote a review of Four Steps on this blog in November, 2008, I did my best to be candid and warn of a few shortcomings:

And Steve is the first to admit that it's a "turgid" read, without a great deal of narrative flow. It's part workbook, part war story compendium, part theoretical treatise, and part manifesto. It's trying to do way too many things at once. On the plus side, that means it's a great deal. On the minus side, that has made it a wee bit hard to understand.

Brant and Patrick undertook a difficult challenge: to provide a generally accessible introduction to Customer Development, without diluting its impact or dumbing-down its principles. I think they've succeeded.

The Entrepreneur’s Guide is an easy read.  It is written in a conversational tone, doesn't take itself too seriously, and avoids extraneous fluff. It does a great job of laying out general principles and suggesting specific, highly actionable tactics. You can easily take from it whatever makes sense for your business, and leave the rest. And it's incredibly to-the-point: you can digest this book in a couple of hours.

While the customer development framework of Four Steps is universally relevant, The Entrepreneur’s Guide updates its practices for modern startups. Four Steps primarily centers its stories and case studies on B2B hardware and software startups. This new volume also tackles examples from the Internet and wireless startups of today, both B2B and B2C. And throughout, they maintain a thoroughly realistic take on the power - and limitations - of an entrepreneurship methodology:

Successful implementation of Customer Development, let alone simply believing in it, will not guarantee success for your business. Customer Development will help you – force you – to make better decisions based on tested hypotheses, rather than untested assumptions. The results of the Customer Development process may indicate that the assumptions about your product, your customers and your market are all wrong. In fact, they probably will. And then it is your responsibility, as the idea-generator (read: entrepreneur), to interpret the data you have elicited and modify your next set of assumptions to iterate upon.

Many “airport business books” urge entrepreneurs to never give in. They tell them to persist in their dream of building a great product and/or company, no matter what the odds are or what the market might be telling them – success is just around the corner. They tend to illustrate this sort of advice with inspiring stories of entrepreneurs who succeeded against all odds and simply refused to throw in the towel. While maintaining persistence and willpower is certainly good advice, Customer Development methodologies are designed to give you data and feedback you may not want to hear. It is incumbent upon you to listen.

The Entrepreneur’s Guide to Customer Development includes four powerful case studies/interviews with successful entrepreneurs who have taken iterative approaches to their respective startups that very much resemble the spirit of Lean Startups and Customer Development.  I found these to be particularly interesting and worthwhile.

At the heart of Brant and Patrick's interpretation of Customer Development is their belief that its fundamental teaching is to question assumptions. This gives them a hook with which to apply their ideas to a wide variety of situations. In other words, if particular examples in the book don’t apply to you directly, Brant and Patrick show you how to figure out what might work for you.  This is important, since every situation is different.  I'll give them the last word:

You are already skeptical of Customer Development and Lean Startups and the slew of emerging buzzwords and supple-to-the-point-of-meaningless terms. That’s great, more power to you; we applaud your skepticism. But be philosophically consistent: periodically take the time to question your own expertise and that of your friends, partners and investors. Make the effort to test your assumptions.

If there’s a shortcoming to this book, it’s that it focuses primarily on the Customer Discovery step in The Four Steps.  Here’s hoping they soon tackle Customer Validation. Well done, Brant and Patrick. I can't wait to see what's next. In the meantime, go buy a copy of The Entrepreneur´s Guide to Customer Development right now.

Combining agile development with customer development

Today I read an excellent blog post that I just had to share. Jim Murphy is a long-time agile practitioner in startups. He's often felt that there was something missing. In most agile development systems, there is a notion of the "product backlog" a prioritized list of what software is most valuable to be developed next. The breakthrough idea of agile is that software should be built iteratively, with the pieces that customers value most created first. This is a significant improvement on the traditional waterfall methodology.

But startups sometimes have trouble applying agile successfully. Or, rather, they apply it successfully, but things don't turn out so well. Enter Jim's post...

Customer Development - The Missing Piece!

But, over the years I’ve realized that the toughest problem - the one that matters most and was consistently the most challenging - was figuring out what the product backlog should be.

The backlog is the answer to the question: “What is the most important work we should do right now?” it presumes that you could confidently make that list, and keep it up to date as things change - or at least articulate what you’re building and for whom. Embedded in that assumption is why startups fail. How do you really make the best backlog for your company?

XP and Scrum don’t have much to say - they punt. Its by far the hardest part of the puzzle of shipping successful products and both recommend that you get a customer in the room and ask them to clarify what they want as you go. Well, that’s fine as far as it goes but when you’re a startup and you don’t have customers yet you need a way to bootstrap and that can feel awfully chaotic and wasteful. What’s worse is that as you grow you’ve probably developed some pretty bad habits as far as setting priorities and strategy: like thinking you’re a genius - just because you got funded - and that genius is what allows you to *know* what the market wants.

I remember having this exact same "aha!" moment, auditing Steve Blank's class when we were first building IMVU. Ever since that time, I have struggled to explain how the feedback loop in customer development should interface with the feedback loop in product development.

If you look at the origins of most agile systems, including Scrum and XP, they come out of experiences in big companies. Consider the classic project that was essential to the creation of extreme programming, the Chrysler Comprehensive Compensation System. This was to be a new piece of software to run payroll for Chrysler. In a project like that there are lots of big questions that need to be answered in order to build a working product. But you don't generally have to ask "what problem are we trying to solve?" That's pretty clear. In the case of C3, that was to run payroll for 87,000 employees, who were presumably receiving payroll before the project began. What causes projects like this to fail in traditional software development is that the solution is unknown. Agile is one way to succeed, because pursuing unknowns iteratively is a good way to mitigate risk. What do you do if the problem itself is unknown?

In a startup, rather than think of ourselves as having a marketing department and an engineering department, I now believe it's better to think of ourselves as focusing our energies on unknown problems and unknown solutions. Approaching each of them iteratively is the right thing to do. But the biggest payoff of all can be found when we combine them into one large company-wide feedback loop.

Last year, I found myself back in Steve Blank's class at Haas, this time trying to teach the students about what it's like running engineering alongside customer development. Working with Steve, I came up with schematic diagrams that I hope illustrate this point. (You can see the full deck in my post on Customer Development Engineering or listen to audio from a more recent lecture)

I thought given Jim's prompting it might be useful to post this excerpt. Notice that the unit of progress changes as we move from waterfall to agile to the lean startup. For more on this latter point and why it's so important, consider taking a look at the posts Achieving a failure and Throwing away working code.

Eric Ries Lean Startup Schematic View Of Agile Development And Customer Development

View more presentations from Eric Ries.

Anyway, thanks Jim for the great post. And credit once again goes to Nivi from Venture Hacks for sharing it with me.

What is customer development?

When we build products, we use a methodology. For software, we have many - you can enjoy a nice long list on Wikipedia. But too often when it's time to think about customers, marketing, positioning, or PR, we delegate it to "marketroids" or "suits." Many of us are not accustomed to thinking about markets or customers in a disciplined way. We know some products succeed and others fail, but the reasons are complex and the unpredictable. We're easily convinced by the argument that all we need to do is "build it and they will come." And when they don't come, well, we just try, try, again.

What's wrong with this picture?

Steve Blank has devoted many years now to trying to answer that question, with a theory he calls Customer Development. This theory has become so influential that I have called it one of the three pillars of the lean startup - every bit as important as the changes in technology or the advent of agile development.

You can learn about customer development, and quite a bit more, in Steve's book The Four Steps to the Epiphany. I highly recommend this book for all entrepreneurs, in startups as well as in big companies. Here's the catch. This is a self-published book, originally designed as a companion to Steve's class at Berkeley's Haas school of business. And Steve is the first to admit that it's a "turgid" read, without a great deal of narrative flow. It's part workbook, part war story compendium, part theoretical treatise, and part manifesto. It's trying to do way too many things at once. On the plus side, that means it's a great deal. On the minus side, that has made it a wee bit hard to understand.

Some notable bloggers have made efforts to overcome these obstacles. VentureHacks did a great summary, which includes slides and video. Marc Andreeson also took a stab, calling it "a very practical how-to manual for startups ... a roadmap for how to get to Product/Market Fit." The theory of Product/Market Fit is one key component of customer development, and I highly recommend Marc's essay on that topic.

Still, I feel the need to add my two cents. There's so much crammed into The Four Steps to the Epiphany that I want to distill out what I see as the key points:

1. Get out of the building. Very few startups fail for lack of technology. They almost always fail for lack of customers. Yet surprisingly few companies take the basic step of attempting to learn about their customers (or potential customers) until it is too late. I've been guilty of this many times in my career - it's just so easy to focus on product and technology instead. True, there are the rare products that have literally no market risk; they are all about technology risk ("cure for cancer"). For the rest of us, we need to get some facts to inform and qualify our hypotheses ("fancy word for guesses") about what kind of product customers will ultimately buy.
   
   And this is where we find Steve's maxim that “In a startup no facts exist inside the building, only opinions.” Most likely, your business plan is loaded with opinions and guesses, sprinkled with a dash of vision and hope. Customer development is a parallel process to product development, which means that you don't have to give up on your dream. We just want you to get out of the building, and start finding out whether your dream is a vision or a delusion. Surprisingly early, you can start to get a sense for who the customer of your product might be, how you'll reach them, and what they will ultimately need. Customer development is emphatically not an excuse to slow down or change the plan every day. It's an attempt to minimize the risk of total failure by checking your theories against reality.
   
   
2. Theory of market types. Layered on top of all of this is a theory that helps explain why different startups face wildly different challenges and time horizons. There are three fundamental situations that change what your company needs to do: creating a new market (the original Palm), bringing a new product to an existing market (Handspring), and resegmenting an existing market (niche, like In-n-Out Burger; or low-cost, like Southwest Airlines). If you're entering an existing market, be prepared for fast and furious competition from the incumbent players, but enjoy the ability to fail (or succeed) fast. When creating a new market, expect to spend as long as two years before you manage to get traction with early customers, but enjoy the utter lack of competition. What kind of market are you in? The Four Steps to the Epiphany contains a detailed approach to help you find out.
   
   
3. Finding a market for the product as specified. When I first got the "listening to customers" religion, my plan was to talk to as many customer as possible, and build them as many features as they asked as possible. This is a common mistake. Our goal in product development is to find the minimum feature set required to get early customers. In order to do this, we have our customer development team work hard to find a market, any market, for the product as currently specified. We don't just abandon the vision of the company at every turn. Instead, we do everything possible to validate the founders' belief.
   
   The nice thing about this paradigm is it sets the company up for a rational discussion when the task of finding customers fails. You can start to think through the consequences of this information before it's too late. You might still decide to press ahead building the original product, but you can do so with eyes open, knowing that it's going to be a tough, uphill battle. Or, you might start to iterate the concept, each time testing it against the set of facts that you've been collecting about potential customers. You don't have to wait to iterate until after the splashy high-burn launch.
   
   
4. Phases of product & company growth. The book takes its name from Steve's theory of the four stages of growth any startup goes through. He calls these steps Customer Discovery (when you're just trying to figure out if there are any customers who might want your product), Customer Validation (when you make your first revenue by selling your early product), Customer Creation (akin to a traditional startup launch, only with strategy involved), and Company Building (where you gear up to Cross the Chasm). Having lived through a startup that went through all four phases, I can attest to how useful it is to have a roadmap that can orient you to what's going on as your job and company changes.
   
   As an aside, here's my experience: you don't get a memo that tells you that things have changed. If you did, it would read something like this: "Dear Eric, thank you for your service to this company. Unfortunately, the job you have been doing is no longer available, and the company you used to work for no longer exists. However, we are pleased to offer you a new job at an entirely new company, that happens to contain all the same people as before. This new job began months ago, and you are already failing at it. Luckily, all the strategies you've developed that made you successful at the old company are entirely obsolete. Best of luck!"
   
   
5. Learning and iterating vs. linear execution. I won't go through all four steps in detail (buy the book already). I'll just focus on the paradigm shift represented by the first two steps and the last two steps. In the beginning, startups are focused on figuring out which way is up. They really don't have a clue what they should be doing, and everything is guesses. In the old model, they would probably launch during this phase, failing or succeeding spectacularly. Only after a major, public, and expensive failure would they try a new iteration. Most people can't sustain more than a few of these iterations, and the founders rarely get to be involved in the later tries.
   
   The root of that mistake is premature execution. The major insight of The Four Steps to the Epiphany is that startups need time spent in a mindset of learning and iterating, before they try to launch. During that time, they can collect facts and change direction in private, without dramatic and public embarrassment for their founders and investors. The book lays out a disciplined approach to make sure this period doesn't last forever, and clear criteria for when you know it's time to move to an execution footing: when you have a repeatable and scalable sales process, as evidenced by early customers paying you money for your early product.
   

It slices, it dices. It's also a great introduction to selling and positioning a product for non-marketeers, a workbook for developing product hypotheses, and a compendium of incredibly useful tactics for startups young and old.

When I first encountered this book, my first impulse was as follows. I bought a bunch of copies, gave them out to my co-founders and early employees, and then expected the whole company's behavior would radically change the next day. That doesn't work (you can stop laughing now). This is not a book for everyone. I've only had luck sharing it with other entrepreneurs who are actually struggling with their product or company. If you already know all the answers, you can skip this one. But if you find some aspect of the situation your in confusing, maybe this will provide some clarity. Or at least some techniques for finding clarity soon.

My final suggestion is that you buy the book and skim it. Try and find sections that apply to the startup you're in (or are thinking of building). Make a note of the stuff that doesn't seem to make sense. Then put it on your shelf and forget about it. If your experience is anything like mine, here's what will happen. One day, you'll be banging your head against the wall, trying to make progress on some seemingly intractable problem (like, how the hell do I know if this random customer is an early adopter who I should spend time listening to, or a mainstream customer who won't buy my product for years). That's when I would get that light bulb moment: this problem sounds familiar. Go to your shelf. Get down the book, and be amazed that you are not the first person to tackle this problem in the history of the world.

I have been continually surprised at how many times I could go back to that same well for wisdom and advice. I hope you will be too.

Customer Development Engineering

Yesterday, I had the opportunity to guest lecture again in Steve Blank's entrepreneurship class at the Berkeley-Columbia executive MBA program. In addition to presenting the IMVU case, we tried for the first time to do an overview of a software engineering methodology that integrates practices from agile software development with Steve's method of Customer Development.

I've attempted to embed the relevant slides below. The basic idea is to extend agile, which excels in situations where the problem is known but the solution is unknown, into areas of even greater uncertainty, such as your typical startup. In a startup, both the problem and solution are unknown, and the key to success is building an integrated team that includes product development in the feedback loop with customers.

2008 09 06 Eric Ries Haas Columbia Customer Development Engineering

View SlideShare presentation or Upload your own.

As always, we had a great discussion with the students, which is helping refine how we talk about this. As usual, I'm heavy on the theory and not on the specifics, so I thought I'd share some additional thoughts that came up in the course of the classroom discussion.

1. Can this methodology be used for startups that are not exclusively about software? We talk about taking advantages of the incredible agility offered by modern web architecture for extremely rapid deployment, etc. What about a hardware business with some long-lead-time components?
   
   To be clear, I have never run a business with a hardware component, so I really can't say for sure. But I am confident that many of these ideas still apply. One major theory that has influenced the way I think about processes comes from Lean Manufacturing, where they use these same techniques to build cars. If you can build cars with it, I'm pretty sure you can use it to add agility and flexibility to any product development process.
   
   
2. What's an example of a situation where "a line of working code" is not a valid unit of progress?
   
   This is incredibly common in startups, because you often build features that nobody wants. We had lots of these examples at IMVU, my favorite is the literally thousands of lines of code we wrote for IM interoperability. This code worked pretty well, was under extensive test coverage, worked as specified, and was generally a masterpiece of amazing programming (if I do say so myself). Unfortunately, positioning our product as an "IM add-on" was a complete mistake. Customers found it confusing and it turned out to be at odds with our fundamental value proposition (which really requires an independant IM network). So we had to completely throw that code away, including all of its beatiful tests and specs. Talk about waste.
   
   
   
3. There were a lot of questions about outsourcing/offshoring and startups. It seems many startups these days are under a lot of pressure to outsource their development organization to save costs. I haven't had to work this model under those conditions, so I can't say anything definitive. I do have faith that, whatever situation you find yourself in, you can always find ways to increase the speed of iteration. I don't see any reason why having the team offshore is any more of a liability in this area than, say, having to do this work while selling through a channel (and hence, not having direct access to customers). Still, I'm interested in exploring this - some of the companies I work with as an advisor are tackling this problem as we speak.
   
   
   
4. Another question that always comes up when talking about customer development, is whether VC's and other financial backers are embracing this way of building companies. Of course, my own personal experience has been pretty positive, so I think the answer is yes. Still, I thought I'd share this email that happened to arrive during class. Names have, of course, been changed to protect the innocent:
   
   

   
   Hope you're well; I thought I'd relay a recent experience and thank you.
   I've been talking to the folks at [a very good VC firm] about helping them with a new venture ... Anyway, a partner was probing me about what I knew about low-burn marketing tactics, and I mentioned a book I read called "Four Steps to the…"
   It made me a HUGE hit, with the partner explaining that they "don't ramp companies like they used to, and have very little interest in marketing folks that don't know how to build companies in this new way."

Anyway, thanks to Steve and all of his students - it was a fun and thought-provoking experience..

Case Study: Using an LOI to get customer feedback on a minimum viable product

How much work should you do on a new product before involving customers? If you subscribe to the theory of the minimum viable product, the answer is: only enough to get meaningful feedback from early adopters. Sometimes the best way to do this is to put up a public beta and drive a limited amount of traffic to it. But other times, the right way to learn is actually to show a product prototype to customers one-on-one. This is especially useful in situations, like most B2B businesses, where the total number of customers is likely to be small.

This case study illustrates one company’s attempt to do customer development by testing their vision with customers before writing a single line of code. In the process, they learned a lot by asking initial prospects to sign a non-binding letter of intent to buy the software. As you’ll see, this quickly separated the serious early adopters from everyone else. Mainstream customers don’t have enough motivation to buy an early product, and so building in response to their feedback is futile.

Along the way, this case study raises interesting ethical issues. The lean startup methodology is based on enlisting customers as allies, which requires honesty and integrity. If you deceive customers by showing them screenshots of a product that is “in-development” but for which you have written no code, are you lying to them? And, if so, will that deception come back to haunt you later? Read on and judge for yourself.

The following was written an actual lean startup practitioner. It was originally posted anonymously to the Lean Startup Circle mailing list, and then further developed on the Lean Startup Wiki’s Case Studies section. If you’re interested in writing a future case study, or commenting/contributing to one, please join the mailing list or head on over to the wiki. What follows is a brief introduction by me, the case study itself, and then some Q&A led by LSC creator Rich Collins. Disclaimer: claims and opinions expressed by the authors of case studies are theirs alone; I can’t take credit or responsibility. – Eric Ries

In April of 2009 my partner and I had an idea for a web app, a B2C platform that we are selling as SaaS [software-as-a-service]. We decided from the get-go that, while we clearly saw the benefits and necessity of our concept, we would remain fiercely skeptical of our own ideas and implement the customer development process to vet the idea, market, customers etc, before writing a single line of code.

My partner was especially adamant about this as he had spent the last 6 months in a cave writing a monster, feature-rich web app for the financial sector that a potential client had promised to buy, but backed out at the last second.  They then tried to shop the app around, and found no takers.  Thousands of lines of code, all for naught -- as is usually the case without a customer development process. (See Throwing away working code  for more on this unfortunate phenomenon. -Eric)

We made a few pencil drawings of what the app would look like which we then gave to a graphic designer.  With that, the graphic designer created a Photoshop image. We had him create what we called our "screenshots" (which suggests that an app actually existed at the time) and had him wrap them in one of these freely available PS Browser Templates. Now armed, with 4 "screenshots" and a story, we approached our target market, some of which was through warm introductions, and some, very literally, was through simple cold-calling.

Once we secured a meeting, we told our potential customers that we were actively developing our web app (implying that code was being written) and wanted to get potential user input into the development process early on.  Looking at paper print-outs of our "screenshots", no one could tell that this was simply a printout of a PSD, and not a live app sitting on a server somewhere. We walked them through what we thought would be the major application of our product.  Most people were quite receptive and encouraging.  What proved to be very interesting was that we quickly observed a bimodal distribution with regards to understanding the problem and our proposed solution:

• people either became very excited and started telling us what we should do, what features it needed and how to run with this, or
  
• they didn't think there was a real problem here, much less a needed solution.

We ruminated on this for a while. The vehemence of those that didn't get it surprised us.  Perhaps we had a super-duper-hyper-ultra-cool idea  --- but not enough customers existed to make it worth the effort. We visited each potential customer a minimum of twice, if not three times.  Each time we would come back with a few more "screenshots" and tell them that development was progressing nicely and ask them for more input. We also solicited information as to how they were currently solving the problem and how much they paid for their solution.

On the third visit, we pressed those who saw merit in the idea to sign a legally non-binding Letter of Intent.  Namely, that they agree to use it free of charge if we deliver it to them and it is capable of X, Y and Z.  And not only do they agree to use it, but that they intend to purchase if by Y date at X price if it meets their needs.

By the way, this LOI was not written in legalese.  Three quarters of it was simple everyday English.  In fact, we customer dev-ed the LOI itself.  The first time, we asked a client to sign it before we had even written it.  When they agreed to sign it, we quickly whipped it up while sitting in a coffee shop and emailed it off to them.  This would help us separate the wheat from the chaff when it came to determining interest and commercial viability.  Once we had two LOIs signed and in-hand, we actually began to write code.

We also implicitly used the LOIs for price structure and price discovery - which we are still working on.  We backed into prices from all sorts of angles, estimating the time-cost of equivalent functionality, competitive offerings, other tools we were potentially displacing -- but in the end, we lobbed a few numbers at them and waited to see if they flinched.

Customer A got X price, Customer B got X + Y price, and so on.  So far, our customers have never mentioned price as an objection, which suggests to me that at this point we are very much underpriced. The LOI was also useful as we leveraged it by approaching the competitor of one of those who signed by simply letting them know that their competitor will be using our app.  They returned our cold intro email within 8 mins.

We have two customers that have balked at signing LOIs, but want to use our product.  This has been somewhat of a quandary for us.  When we decided to go the LOI route, we thought that we would not bend and that we would only service those customers who would sign the LOI.  In the end, we decided that these two customers were large enough to help us with exposure, provide good usage data and worth the risk of them wasting our time.  Time will tell if this theory proves correct.

Right now, the app itself is pretty ugly, a bit buggy and slow -- and doesn't even do a lot.  It is borderline embarrassing.  Don't get me wrong, it does the few necessary things.  BUT it definitely does NOT have the super-duper-hyper-ultra-cool Web 2.0 spit and polish about it. Interestingly enough, our ratio of positive comments to negative comments from actual users is about 10 to 1.  One of our first customers had a disastrous launch with it, yet, has signed on to try it again (granted, they did get it for free and we did offer it for free for this next time). But they didn't hesitate to try it again.  I thought we would have to plead, beg and beseech.  But for them, it was a no-brainer.  So, we have to be doing something right.

Our feature set is very limited and being developed almost strictly from user input.  While I personally have all sorts of super-duper-hyper-ultra-cool Web 2.0 ideas --- we are holding ourselves back, and forcing ourselves to wait for multiple, explicit and overlapping user requests.  We have seen our competitors whose feature sets are very rich, to say the least, but we think in some cases, are as over-engineered as they are feature-rich.

Only time and the market will tell if they are innovative and we are slow, lazy pigs or they have gotten ahead of themselves/the market and our minimalist solution will be better received.

Rich Collins, founder of the Lean Startup Circle, responded to the poster with some Q&A.
LSC: What is your response to some of the people on Hacker News that questioned the ethics of taking this approach?

Some of the commenters have some good points.  It definitely explores ethical boundaries.  However, I don't think we indulged in any zero-sum game type deception.  By that, I mean our intentional fuzziness about the state of development did not cause harm in any manner to our prospective clients.  In fact, just us showing up at their offices and talking about our screenshots benefited our prospective clients tremendously as:

1. Those clients who had never even entertained the functionality we were proposing gained significant knowledge.
2. With that knowledge, they could (and did) Google our competition and start exploring the space and current offerings. 

We did, in fact, tell one of our prospects in the beginning that our screenshots were simply mock-ups.  However, that makes the prospect feel as if you are wasting their time and they then are unlikely to provide input.

"Oh, this is just a Photoshop file?  Well, come back to us when you are further along." which defeats the whole purpose of getting face time for Customer Development!

When you tell them, the app is in development (and it was, even before coding, we were spending a lot of time on what we wanted and didn't want, how it would look, use cases ‚ etc) the prospects are interested in providing input and shaping the product.  They need to feel and see some momentum.

LSC: Your use of a non-binding letter of intent was another interesting tactic.  Did the customers that signed it end up paying for your product?

Yes and no.  We had a dispute with one signee and couldn't convert them.  However, we successfully converted others.  I should also mention that there was one client who refused to sign an LOI, but we are in the process of converting them.

The LOI was designed to give us hard, non-bullshit-able feedback instantly.  Too often people will affirm your idea so that you (or they) can save face, which BTW is a form of well-intentioned and socially acceptable deception.  This is why, IMHO, friends, wives, and significant others are probably not good people to talk to about your idea.  At the end of the day, no one knows if the idea is any good.  The market will tell you.

LSC: Would you respond to a few selected Hacker News comments?
"If I were one of your prospects, I would never sign a letter of intent based on drawings only. I'd make you come back later with something, anything I could play with ... Come back when you have something real to show. Until then you're no different from any other poser."

I myself probably would never sign an LOI on screenshots only.  However, our customers did a lot of stuff that I would never do.  Lesson learned:  I am not my customer.  We think differently.  We solve our problems differently.  We have different needs and wants.  Repeat after me:  You are not your customer.

LSC: And one more: "Except the LOIs in this case are utterly meaningless. I've been on the customer side of LOIs that were signed on request, knowing that it obligated us to nothing."

Wrong.  We got instantaneous feedback on the validity of the idea and started our sales process concurrently.  While legally non-binding, customers who have signed an LOI are a lot less likely to disappear or make themselves hard to get a hold of.  LOIs, while clearly not as good as signed sales contract, do have meaning and are valuable.  I encourage B2B startups to keep them in their customer development arsenal.

Special thanks to Rich Collins, the Lean Startup Circle practitioners, and to everyone who has contributed to the Case Studies on the wiki. And thanks to these entrepreneurs for sharing their story. Have a case study you’d like to share? Head on over to the Lean Startup Wiki.

Lean Startup at Scale

Guest post by Lisa Regan, writer for The Lean Startup Conference.

As Lean Startup methods have been used now for a number of years, we’ve become increasingly interested in how companies use them to sustain growth. That is, once you’re no longer a small company and you have some success, how do you execute and continue to grow through innovation? Next Tuesday, October 22 at 10a PT, we’ll take a look at this advanced entrepreneurship question. In a webcast conversation, Lean Startup for Growing Companies, Eric Ries will talk with two Lean Startup Conference speakers: Wyatt Jenkins, VP of Product at Shutterstock, a stock photo site that has become one of the world’s largest two-sided marketplaces, and has expanded since its founding in 2003 from a single development team to 12 cross-functional teams spanning all phases of product development; and Ari Gesher, a senior engineer at Palantir Technologies, which specializes in data-mining software for a diverse set of problems across verticals, including disaster recovery work recognized by the Clinton Global Initiative, and has grown since its founding in 2004 to over 1,000 employees and undisclosed revenues reported to be approaching $1B today. The webcast is free with registration and will include a live Q&A with attendees.

Below are excerpts from conversations we had with Ari and Wyatt about their growing companies and about some of their suggestions for staying with Lean Startup as you expand:

When we asked Ari to talk about how he addressed some of the challenges of growth at Palantir, he gave the example of developing iterative cycles that could accommodate a scaling company:

Ari: At Palantir, we've had to tailor our software development process over time to deal with the scale of the team and the scale of our core software products. Each plateau of scale has required adjustments--changing or dropping an old process that wasn't working or creating a new process to deal with novel challenges. One good example is the way in which we've adjusted the length of different phases of our agile sprints. We don't follow a set agile methodology, but rather follow a more home-grown, minimal version of various approaches. We work in prototypically four-week iterations, with quality engineers and software developers working in close collaboration.

It wasn’t always this way. Palantir is a deep technical play and we had a lot of code to write just to fill out the product vision that we had already validated with potential customers; it took us two straight years of development to go from early prototypes to software that could be used in production. In these halcyon days, we weren't using iterative cycles as there was often nothing that could be tested for long periods of time (aside from unit testing, of course). During this period, the Palantir Gotham team grew from five developers to around 35.

This finally bit us after a four month stint of development blew through its testing schedule by a factor of four: two scheduled weeks turned into two months before the product reached stability.
So what was going on? Software development is all about managing complexity and the bigger and more mature the codebase gets, the more complex it gets. The interconnectedness had come to a head, such that new code was much more likely to disrupt existing code than ever before. As we started looking at bug counts something else became clear: we could now create bugs faster than we could find them.

We had finally hit the point where we needed to impose clear process - process whose main goal was to ensure that software stayed stable. But we couldn't have identified this without having clear metrics (that high bug count) to assess our development process. The result was a new process of four-week iterative cycles all about throttling new code. Here's the simplest form of that cycle:

• Week -1 - Planning/End-of-Cycle - Software engineers are planning: writing specifications, doing light prototyping, and experimentation. During this week, quality engineers are attending planning meetings but also doing end-of-cycle testing of the previous iteration - the final testing on an internal release before it's deployed to our dog-fooding systems.
• Week 0 - New Feature 1 - Software engineers are busy building brand new features. Quality engineers are writing up test plans based on the specifications and creating test data (if necessary). By mid-week, the software engineers have to deliver something testable so the quality engineers can start testing and (of course) filing bugs.
• Week 1 - New Feature 2 - Development and testing continue together. By the end of the week, the new code should be stable, with all filed bugs fixed.
• Week 2 - Regression - Software engineers start paying off technical debt by attacking a queue of existing bugs. Quality engineers make full regression passes through the software, looking for old functionality that may have been impacted by the new changes this iteration.
• Week 3 - Planning/End-of-Cycle - See Week -1.

Software is an interconnected system and thus a change can reverberate through the codebase with a super-linear, potentially quadratic complexity. A good analogue is air resistance, which has a quadratic relationship to velocity. If you've ever ridden a motorcycle, you know that at low speeds you hardly feel the wind. As you hit 45 mph, it starts pushing on you. At 65 mph, it's like having a large animal sitting on your chest.

The new process let us manage the velocity of change in the codebase low, keeping the resistance manageable.

More important, the iteration framework gave us something like a meta-process: we could try new ideas about how to manage development process and measure them against historical data to see what could further optimize the process.

Note that the iteration template above is our prototypical iteration. What started as a four-week cycle has since expanded to five-week cycle — adding a second week of regression to pay down technical debt. For the final iteration that turns into an external release, we push out to a six-week cycle, adding an additional week of testing: end-of-release testing.

We asked Wyatt about his experience with testing at Shutterstock, and the best ways to approach it in a growing company:
 
Wyatt: The concept that your "big idea" is nothing but a hypothesis until we test it is a part of the Shutterstock culture. We learned some hard lessons via A/B testing, but realized quickly that the pace at which we could perform tests and the systems for reading tests had to be both excellent and easily accessible by many different groups in the organization. Because of this (and because we believe our data is a competitive advantage that we don't want to share with third parties), we chose to build many tools ourselves. At this point, we have our own open-sourced click tracking "lil brother," an internal data visualization tool built on Rickshaw, as well as an A/B testing platform called Absinthe. We pride ourselves on the speed of testing hypotheses and reading those tests. Shutterstock is in a competitive market, but we have the most traffic and the most usage, meaning that we can run more tests (achieve significance sooner) and learn faster than our competitors.

The upshot of this is that speed matters if you hope to build, measure and learn faster than your competition. As Shutterstock has grown, there are a few key elements to our continued development speed:

• Small, autonomous teams: The more a team can do on their own, the faster they can go. The hand-offs between teams are (mostly) eliminated, and close-working autonomy creates a good startup vibe as well.
  
• Continuous deployment: A key component of speed is to keep pushing out work. This has kept us lean as well—we don't have release trains, and code generally goes live to the site every day of the week.
• Don't get religious about process – just continuously improve. You need to strike a balance between process and problem-solving. You don’t want to get so committed to a particular process that you can’t adapt to problems as they actually present themselves. So, depending on which team you are talking to at Shutterstock, we may be Lean Startup or Agile or Kanban or some other method depending on the type of problem that team is designed to solve. But that doesn’t mean that we don’t take these ideas seriously. You want to be flexible enough to change your process across teams as you scale--but as a rule of thumb we question every new bit of process someone tries to add because process is easy to add and very difficult to remove once it's in place. For that reason, it’s important to go with methods, like Lean Startup, that have proven results for the kind of problem that team is trying to address.

On Customer Development in a growing company, Wyatt offered the following advice: 

Wyatt: We've employed a number of systems in the organization that keep all of us close to the customer. As we've grown, we now have a great qualitative research team dedicated helping us stay close. There are 5-10 customers in our office (or remote) per week for developers, product owners and marketers to speak to and validate learning. The important aspect of scaling customer development is to build it into the process and make it so easy to put your idea in front of a customer that everybody does it. Skip the focus groups--they don't work and they take too long to set up. Create a steady stream of customer input that anyone can dip into.

Ari also talked about the changes in the information flow as a company grows, in his case thinking of it moving in a variety of directions--between the company and its customers, certainly, but also between the company and its own internal teams, or between parts of the company itself:
 
Ari: One of the biggest effects of scale has to do with internal information flows. For example, a small team of four people starting work on a product has it easy. By just sitting in one room, they can have amazing shared situational awareness. There's two things at work here: as new information comes into that room, it's as easy as an offhand comment or a lunch conversation to share. The second thing is that it has no history - everyone on the team is starting from a place of zero knowledge and accumulating context as it arrives.

I joined Palantir when it was one room and fifteen people--the above model was still pretty functional. We all knew a lot about what was going on. Things like shared meals helped us stay in sync such that the knowledge about everything from the state of the product to the outcome of our last meeting with potential customers was pervasive.
Another interesting feature of those early years: most of what we needed to know was outside the company.

Growth changed all that. We've been building the company for almost ten years now and we have three major locations in the United States, as well as about half-a-dozen overseas offices. Over a thousand people work here now.

Most of the information that most of the people need to do their jobs is actually generated inside the company now. We have a long history and so new employees have to spend a long time getting up to speed on the why, what, and how of everything that we do. As a result, we've had to designs process, protocols, and infrastructure to make sure that critical information flows to the right people in a timely manner. We've had to design and implement training programs to help on-board people to our culture and technology. We have a blog that's internal-only to capture important stories for prosperity. We have a dizzying array of email lists and careful protocols about which lists get copied to make sure we can maintain a shared situational awareness that can only hope to approach what we had when we were in one room. We have an internal directory that lets people tag themselves with the things they know about--often learning is about finding who knows the answer and can explain the full why (not just the what) of something.

And none of that addresses exactly how the company as a whole learns from the world. There is now an immense flow of information coming in from the world, about how our product is working (and not working), about how our software is solving customer problems.
There are two teams that handle the bulk of the learning that comes in from the field: Support and Product Navigation. Both of these teams are collating, distilling, and turning into knowledge the information flowing from the field.

Unlike most support teams, the [Palantir] Support Team is not contacted by end users but instead by our people in the field. Our model is to place Forward Deployed Engineers (FDEs) on customer sites to add with integration of data, customization of our platforms and applications to a specific task, and training of the customer's analysts who will be the end-users of the system. If an FDE runs into trouble with the product or a novel situation that we did not anticipate, they contact the Support Team, who handles both resolving the situation, communication with the product team and documenting the knowledge gained in this situation so it can be avoided in the future.

The Product Navigators are responsible for understanding the use cases that are covered by our products--the gaps, what new features we need, what's working, what's not. This is not bug tracking but more along the lines of customer development and guidance to the product team on what to build next. They collate, distill, and prioritize information coming in from the FDEs and product instrumentation about how well the product is actually solving customer problems, what features are in use (or that users don't understand). This is a part of what many other organizations would call product management, but we decouple the learning portion of that discipline from the design portion (handled by product designers and engineers based on the knowledge created by the Product Navigation team) of product management.

Both of these teams were created to handle the sheer scale of information coming in from the field as our customer base as grown from zero to where it is today.
--

Register today for our free webcast to join Eric, Ari, and on October 22 at 10a PT. For even more Lean Startup learning, register for The Lean Startup Conference, December 9 – 11 in San Francisco.

The Lean Entrepreneur is here

Last May, I shared the news that long-time Lean Startup advocates Brant Cooper and Patrick Vlaskovits were working on a new book called The Lean Entrepreneur featuring illustrations by FAKEGRIMLOCK. That new book is about to hit bookstores everywhere.

I was honored that they asked me to write the foreword, and with their permission I'm posting an excerpt below. After the 2012 conference I viewed it as an opportunity to reflect on the growth and evolution of the movement as a whole.

One of the things that I love about what Brant and Patrick have done with The Lean Entrepreneur are the numerous case studies of how entrepreneurs are tackling new ventures, minimizing risk and learning their way to success - these case studies will speak to garage startups and corporate entrepreneurs alike.

A few of the detailed case studies include:

• Tech legend Bill Gross building an MVP in 1999 to test demand for online car sales, which grew into CarsDirect.com.
• LitMotors approach to using Lean Startup to create a new vehicle category.
• AppFog creating "high-hurdle" experiments to surface authentic early adopters with real pain.
• The Embrace infant warmer was developed - by getting out of the country -- and how Rob Emrich learned and scaled his non-profit, Road of Life. (Social entrepreneurs take note!)
• BetaBrand building apparel MVPs and testing them quickly with targeted customer communities.
• Telecom O2 learning to move at the speed of the internet
• 500 Startups and their accelerated feedback loops on what works, and what doesn't work in early-stage investing.
• Scott Summitt iteratively leveraging the emerging technologies of digital fabrication and 3d-scanning to change people's lives.
• PayPal, under the leadership of David Marcus and Bill Scott, re-defining and re-engineering itself by embracing Lean Startup to improve the product experience.
• KISSmetrics building and empowering cross-functional teams to attack problems in their sales funnels via hypothesis testing.
• Intuit showing large organizations how to combine Lean Startup with horizon planning to nurture internal innovation and startup experiments.
• Berkeley Pizza: from pizza in the farmer's market to a sit-down restaurant.

Another thing I love about The Lean Entrepreneur is how Brant and Patrick are treating their book like a startup. One example is in their marketing, which in today's environment requires providing value. This doesn't mean pointing to the product and describing the product's value, but rather the marketing provides value itself.

As part of their book campaign, Brant and Patrick have teamed up with General Assembly to offer 4 free online video classes, including:

Lean UX Research Techniques - Rapid Prototyping - How to Hire Developers - Growth Hacking

Every book pre-order get access to all of these classes - and quite a bit more. You can pre-order on their site until February 10^th 2013, and after that on Amazon.

Lastly, I wanted to share with you the foreword I wrote for The Lean Entrepreneur. As we head into 2013, it's a good time to reflect on how far the Lean Startup movement has come:

---

When I first started blogging in August of 2008, I had no idea what to expect. Startup blogging was hardly "cool" back then. Plenty of venture capitalists advised me against it. 

My personal background was as an engineer and my companies had been Web-based startups, so that is what I wrote about. Struggling to explain the successes and failures of those companies, I discussed principles like continuous deployment, customer development, and a hyper-accelerated form of agile. When I delved into lean manufacturing, I discovered the concepts and terminology dovetailed. The result: a new idea I called The Lean Startup. 

I started with some basic theory: that a startup is an institution designed to thrive in the soil of extreme uncertainty; that traditional management techniques rooted in forecasting and planning would not work well in the face of that uncertainty. Therefore, we needed a new management toolkit designed explicitly for iteration, scientific learning, and rapid experimentation. 

At the time, I viewed it as incidental that the theory might be tied to a particular industry, such as high-tech startups or web-based environments. Lean, after all, emerged from Toyota, a huge automobile manufacturing company. I simply stated my belief that Lean Startup principles would work in other types of startups and in other areas of business where uncertainty reigned. 

Boy, was I unprepared for what happened next. I was hopeful that we would change the way startups are built - but I didn't know.Fast-forward more than 4 years and I'm astounded by what has emerged. A nascent community has blossomed into a full-fledged movement. Entrepreneurs, both new and experienced, proudly share their Lean Startup learning in case studies, conferences, and many, many blogs. Books, workshops and courses authored by passionate practitioners relate experience, share insight, and create tools to teach students ways to make Lean Startup principles their own. Many investors, advisors, mentors and even celebrity entrepreneur icons speak the Lean Startup language. 

It's a big tent. We stand on the shoulders of giants: customer development, the theory of disruptive innovation, the technology life-cycle adoption theory, and agile development. Complementary lines of thinking, such as that of user experience professionals, design thinking practitioners and the functional disciplines of sales, marketing, operations and even accounting, come together to share practices that lift us all. 

Lean Startup has gone mainstream. I wish I could say that this was all part of some master plan, that I knew all along that companies of all sizes - far outside the high-technology world - would embrace Lean Startup. I wish I had foreseen that within a year of publishing The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Achieve Radically Successful Businesses, many large organizations, including such monsters as the United States Federal government (!) would have recognized that to cope with today's world -faster, more competitive, and inundated with data - new methods are needed to keep up. The truth is that all of this change has happened faster and more thoroughly than any of us imagined. And - as you're about to see - we're just getting started. 

That's why I am so excited by the volume you hold in your hands. The Lean Entrepreneur is about those new methods. Brant Cooper and Patrick Vlaskovits are among the earliest adopters of new ideas such as Lean Startup and customer development. Their new work turns their lens on three primary focal points: how to interact with customers, run experiments, and use actionable data to move the needle of any uncertain business endeavor. 

As with all of their work, theirs is not just a book of theory. Brant and Patrick provide great tactical depth in each of these areas. 

They endeavor to answer the question: No matter where you are as an organization, how do you know where to focus your Lean Startup activities? The Lean Entrepreneur offers new thinking, tools and activities that help organizations identify and act upon business model challenges in a waste-eliminating manner. Following the precepts of traditional lean thinking, Brant and Patrick introduce the value stream discovery process, which helps organizations hypothesize what they must do, including product development, marketing, and sales in order to create value. These business model assumptions are then ripe for testing, measuring and iterating upon. 

Further, the value you create is meaningless without a customer who needs, wants, desires and ultimately, determines the final value of your creation. Brant and Patrick spend considerable time helping you think through your customer segments. Cleverly and in the spirit of the scientific method, they even help you discover where your customer theory is wrong. 

Everyone likes a good story; Brant and Patrick interviewed dozens of entrepreneurs and documented numerous case studies both inside and outside of high-tech, in both startups and large enterprises. There's even a classic Wizard of Oz minimum viable product that dates back to 1998! 

Make no mistake, Brant and Patrick have been here since the beginning. They self-published The Entrepreneur's Guide to Customer Development in April of 2010
From the outset, they were both practitioners and mentors, urging entrepreneurs not to follow a paint-by-numbers approach, but rather to think lean: fast, agile and continuously learning. Over the last two years they've traveled around the world speaking, advising, and teaching Lean Startup. 

The Lean Entrepreneur is an important addition to the growing library of principles and practices designed to improve how we tackle innovation and uncertainty, be it in tech startups, Fortune 100, non-profits or government. 

I consider myself lucky to count Brant and Patrick as friends and colleagues. It is my hope that from this book you will gain valuable insights, make Lean Startup your own, and - much more importantly - that you are successful in changing the world for the better. 

Eric Ries,
San Francisco, December 2012

---

If you want to read more, you can find an excerpt of Chapter 6, Viability Experiments here.

Inc Magazine on Minimum Viable Product (and a response)

Inc Magazine has a great new piece up about the increasing use of the Minimum Viable Product by businesses (and not just startups). Here's an excerpt; some of my comments are below:

One of the most gut-wrenching moments for a company is the rollout of a new product. A significant swing and miss can break a company's momentum -- and maybe its bank account. Unfortunately, after months or even years of development, many companies discover that customers aren't willing to buy their new wares. That's why some entrepreneurs are trying another approach to product launches: marketing a product online before spending much on research and development or inventory.

Consider the method used by TPGTEX Label Solutions, a Houston-based software company that specializes in bar codes and labels for manufacturers and chemical companies. Like many companies, TPGTEX rolls out new products several times a year. But instead of spending the time and money to develop products on spec, TPGTEX creates mocked-up webpages that list the features of a potential new product -- such as a system for making radio-frequency identification, or RFID, labels -- along with its price. Then, the company spends no more than a few hundred dollars marketing the product through search engines and to the contacts in its sales database and LinkedIn. It isn't until a customer actually clicks or calls to place an order that TPGTEX's developers will build the software. "We do not develop a product until we get a paying customer," says Orit Pennington, who co-founded the six-employee company with her husband in 2002. Development time is typically no more than two to three weeks, and it generally takes just a few orders to cover development costs.

TPGTEX's approach is an example of a trend in business that has been dubbed minimum viable product or microtesting. The idea is to develop something with the minimum amount of features or information needed to gauge the marketability of a product online. That might mean mocking up a website with potential features and seeing how many visitors click on the item. It might also involve buying pay-per-click ads to see how easy it is to gain potential customers. Or it might mean selling a few products on a site like eBay to see how well they perform before ordering in bulk from a wholesaler.

What sets this approach apart from practices like using focus groups is that companies base product development decisions not just on what customers say they want but on how they vote with their wallets.

Read the rest...

This article is part of a trend that has taken me a bit by surprise: the adoption of lean startup techniques outside the traditional domain of high-tech startups. The theory predicts this, of course, because the definition of a startup as “a human institution creating a new product or service under conditions of extreme uncertainty” says nothing about sector, size of company, or industry. Still, it’s always a relief to see practice and theory converge.

Of course, as more people attempt to use the Minimum Viable Product as a tactic, there are a lot of misconceptions possible. The biggest is the confusion over why this tactic is useful. The Inc story, and many others, does a good job emphasizing its lean-ness. By allowing customers to “pull” value from the company in small batches, you reduce the risk of building a product that nobody wants. Like all lean transformations, this is powerful – it increases the value of every dollar invested in new product creation.

But MVP is most powerful when it is used as part of an overall strategy of learning and discovery. And this is the most confusing, because MVP does not pay off under this strategy if we are attempting to build a minimal product. For that, release early, release often will suffice. But if our aspiration is to change the world, we need something more.

The key ideas are customer development, the pivot, MVP, and root cause analysis. Each is described in separate essays on this blog, but let me say a few words about how they work together – especially for companies with big ambitions. Big visions take a long time to develop, and require an exceptionally high degree of product/market fit. That’s just a fancy way of saying: customers have to really, really like your product. Being specific, it means that their behavior powers one of the three fundamental drivers of growth with a large coefficient. But if big products and big visions take a long time to develop, it’s exceptionally risky to build it based on vision alone. That’s because for a big product to take off, it needs to be right in many key respects. Miss just one, and you can find yourself just a few degrees off – and moving with too much momentum to change course. Think Friendster, the “achieving a failure” startup I’ve written about, Apple’s Newton, Webvan, etc. In each of these, the failure of the initial idea led to the failure of the company (or division).

Building an MVP can help mitigate that risk. But it’s not enough. What if customers hate the MVP? Does that mean your product vision is fundamentally flawed, or just that your initial product sucks? There is no way to know for sure. That’s why entrepreneurship in a lean startup is really a series of MVP’s, each designed to answer a specific question (hypothesis). Being systematic about these hypotheses is what customer development is all about. By testing each failed hypothesis leads to a new pivot, where we change just one element of the business plan (customer segment, feature set, positioning) – but don’t abandon everything we’ve learned. In order to work, these pivots have to be heading in a coherent direction, which is why vision is still such a critical part of entrepreneurship, even in a data-based decision making environment. (See “It’s a startup, not a spreadsheet” for more.)

And yet, even that is not enough. The more visionary the entrepreneur, the more difficult it is to really pivot, really seek out what’s in customers’ heads, and really create a minimum viable product. And so startups – great and terrible alike - are prone to give these ideas lip service, but fail to really take maximum advantage. That’s why a process of rigorous root cause analysis is so critical. After every major milestone, the company has to ask: what did we learn? Why didn’t we learn more? And, most importantly, make incremental investments to do better next time. This is the ultimate startup discipline, the hardest to master, and the one that pays biggest dividends. If you can embrace continuous improvement from day one, you can actually speed up as you scale. It’s an awesome thing to watch.

The lean startup

(Update April, 2011: In September, 2008 I wrote the following post in which I published my thoughts on the term "lean startup" for the first time. In the interests of preserving that history, I have left the original post unchanged and unedited. To learn more about the progress of the the lean startup movement since 2008, click here.)

---

I've been thinking for some time about a term that could encapsulate trends that are changing the startup landscape. After some trial and error, I've settled on the Lean Startup. I like the term because of two connotations:

1. Lean in the sense of low-burn. Of course, many startups are capital efficient and generally frugal. But by taking advantage of open source, agile software, and iterative development, lean startups can operate with much less waste.
2. The lean startup is an application of Lean Thinking. I am heavily indebted to earlier theorists, and highly recommend the books Lean Thinking and Lean Software Development. I also owe a great debt to Kent Beck, whose Extreme Programming Explained: Embrace Change was my first introduction to this kind of thinking. (So far, I have found "lean startup" works better with the entrepreneurs I've talked to than "agile startup" or even "extreme startup.")

What are the characteristics of a lean startup? One that is powered by three drivers, each of which is a part of a major trend:

1. The use of platforms enabled by open source and free software. At the application-stack layer, I see LAMP + Danga as the most common combination. In recent years, we've also got great new options all up and down the stack, in particular things like Amazon EC2 and RightScale (none of which would be possible without the free software movement).
2. The application of agile development methodologies which dramatically reduce waste and unlock creativity in product development. (See Customer Development Engineering for my first stab at articulating the theory involved)
3. Ferocious customer-centric rapid iteration, as exemplified by the Customer Development process.

My belief is that these lean startups will achieve dramatically lower development costs, faster time to market, and higher quality products in the years to come. Whether they also lead to dramatically higher returns for investors is a question I'm looking forward to studying.

Built to learn

It's been an exhilarating ride since the Web 2.0 Expo last week. Thank you all so much for making the event an overwhelming success (way beyond my wildest expectations) and a special thanks to all of you who have reached out to share your feedback, comments, and questions since then.

I have been meaning to write this post for days, but the meetings have been non-stop and I haven't had much time. First of all, I promised to post the full slides of the talk, which are below. I want to thank those people who were recording, tweeting, and posting from the hall itself. Thanks to you I know about the energy in the room and even have pictures to prove it. Best of all, Nivi from Venture Hacks was recording, so these slides have synchronized audio, too.

I learned an incredible amount by giving this talk, especially from the many people who have commented, disagreed, and asked questions about it. Here are some of my top takeaways. Rather than use boring section headers, I thought I'd just quote from actual customers, in their own words.

MarkH: Key takeaways from Eric's great talk #w2e #leanstartup 1) "building a culture to learn" @ericries

Mark's point is the one that seems to have had the biggest impact from the talk as a whole: that startups should be built to learn. That's the essence of so many of the lean startup techniques I've evangelized: customer development, the Ideas/Code/Data feedback loop, and the adaptation of agile development to the startup experience. Many people asked some variation of the question: "sure, learning sounds good. But how do I actually organize my team so that we actually do it day-in day-out?" Answering that question is what I'm striving to do on this blog (and at future webcasts and workshops).

blader: @ericries my #1 takeaway from #leanstartup: "No marketing team. No engineering team. You need a problem team and a solution team."

Steve Blank has evangelized the "no departments" theme for many years. This is my take on that idea. The insight is that waterfall and agile are well-adapted for situations of "known problem, known solution" and "known problem, unknown solution" respectively. The lean startup focuses on situations where we have both an unknown problem and an unknown solution.

Creating a company-wide feedback loop that incorporates both customer development and agile development is a challenge. Traditional department labels just make it harder. So instead of having sales, marketing, and business development, we have a problem team implementing customer development. But where it makes sense, that team may also include engineers building new experiments or prototypes to try with customers. And instead of design, engineering, QA, and operations we have a solution team implementing a startup-centric version of agile development. But that team may also include product marketers or other in-house customers who can give insight into the impact that solution trade-offs might have on customers. Most of all these two teams are in constant contact, sharing insights, hypotheses and -- above all -- data.

rahmin: #leanstartup unit of progress: validated learning about customers, preferably with $$$ attached - @ericries

adachen: The biggest source of waste at a startup is building something that no one wants #leanstartup

Once we have our problem team and solution team, it's essential that they share a single definition of progress: validated learning about customers. It's not good enough to hit product milestones and conduct usability tests. We have to actually validate our key business theories and prove that we're on a path to creating somethng that matters.

dalelarson: "Metrics are people, too." @ericries's talk on Lean Startups absolutely fantastic. #leanstartup

ericnsantos: #w2e #leanstartup Metrics should be Actionable, Accessible and Auditable. Use them to split-test all the time.

(Gotta love using twitter quotes, since they occaisionally come with compliments attached).

Metrics are a key questions startups face. How do we decide what to measure and why? What do we do about it once we get started? I didn't start life as a metrics-lover, and it took me many years to learn to distinguish between "vanity metrics" that make us feel good and "actionable metrics" that help us make decisions. "Metrics are people too" is a reminder I constantly needed when I was a manager. It's not about moving numbers in a spreadsheet, it's about changing customer behavior -- for the better. When people ask about how to reconcile metrics with interaction design, usability testing, or in-person customer interviews, this is the issue they are really talking about. When we lose sight of the humanity of our customers, we're not likely to be able to delight them.

sachinrekhi: "Visionary customers are as smart if not smarter then the founders" #leanstartup

There's no skipping the chasm. Startups have no choice but to first talk to and sell to what Steve calls earlyvangelists. This is true whether you're selling million-dollar software to huge enterprises or selling fifty-cent virtual clothes to teenagers. Only the truly visionary customers will engage early-on. Luckily, they can help you find their mainstream counterparts, if you listen closely.

hansoo: #leanstartup "MBA fallacy: whiteboard, think about it, whiteboard some more, think about it, whiteboard, feel good about your idea"

Although I never went to business school, I have committed the "MBA's fallacy" many times. It's actually the fastest way to iterate on a business: just keep reworking it at the whiteboard. At IMVU, I remember spending an incredible amount of time iterating on the model that would power our third-party developer economy. My cofounders and I would hash out nuances and details almost every day, re-drawing diagram after diagram on the whiteboard. Now, the first few times we thought through those issues, we probably did some quality thinking. But pretty soon it degenerated into fact-free bloviating. If it doesn't involve new facts, it doesn't count as learning.

MeganMurray: "Behind every technical problem is a human problem. Fix the cause, not just the symptom." #leanstartup #w2e (via @blader) Amen

mcavalcanti: #w2e #leanstartup every technical problem is a usually a human problem.

jonbischke: "We're fine with having any problem occur one time. But no problem can occur twice." @ericries #leanstartup #w2e

If you are willing to follow a continuous-improvement methodology like five whys, you can re-derive almost all of the lean startup techniques, and probably discover many more besides. All it takes is that you focus seriously on the idea that you're not willing to waste time having the same problem occur twice. It sounds easy, but in practice it usually means a radical shift in perspective, one that can help see through the apparently technical problems that most of us who are engineers spend our time fixing. Those are only symptoms.

So without further ado, let me share the slides with audio.

The Lean Startup at Web 2.0 Expo

Upcoming Events
If you missed the session at Web 2.0 Expo, never fear. I'm doing my best to satisfy the many requests I've had to provide more in-depth material and more diverse locations.

April 21 - Agile Vancouver is sold-out (thank you all so much!). However, for those who weren't able to get in (or are real gluttons for punishment), I will be speaking the night before at a free event hosted by The Vancouver Ruby/Rails/Merb Meetup Group. It will be a more-technical version of the Expo talk. You can register here. I'm doing my best to live up to the three-!!! billing.

May 1 - free webcast. I'm doing a webcast with O'Reilly that is free and open to the public. We'll be discussing in greater detail the three techniques I highlighted at the Expo: continuous deployment, split-testing, and five whys. Here's the promo; more information is available on their site.

How to Build a Lean Startup, step-by-step
Get started with a detailed guide to three key lean startup techniques: continuous deployment, rapid split-testing, and root cause analysis (five why's). This webcast will cover the theory of how lean startups work, implementation details, and case studies. Participants will come away with a specific plan of action for how to apply these techniques to their product, company, or startup.
Register here.

May 29 - the Lean Startup Workshop. I am particularly excited about this, as it will be a really in-depth discussion. The workshop will go all day and will be for a carefully screened audience. If you'd like to register, you have to take the survey. At the end, you'll be given the opportunity to participate in a customer validation exercise where you can reserve a spot, or just sign up to be notified when applications will start.

I'll continue to post about additional events as I get them scheduled. Looks like I'll be at TiEcon 2009 in mid-may, and at an event to be announced in Austin in early June.

Thanks for reading, attending, commenting and questioning. I'm continually inspired by your entrepreneurial passion and insight. Thank you.