Showing posts sorted by relevance for query definition of startup. Sort by date Show all posts
Showing posts sorted by relevance for query definition of startup. Sort by date Show all posts

Monday, June 21, 2010

What is a startup?

I think most people have a fairly specific image that gets conjured up when they hear the word startup. Maybe it’s the “two guys in a garage” made famous by HP, or the idea of Jobs and Wozniack walking barefoot and shaggy through the Homebrew Computer Club. Maybe it’s the more recent wunderkinds like Zuckerberg or Brin and Page. What all of these pictures have in common is a narrative that goes something like this: scrappy outsiders, possessed of a unique genius, took outrageous risks and worked incomprehensible hours to beat the odds.

But this cinematic view of entrepreneurs is flawed in many ways. Let’s start with the most basic. It leads people to mistakenly believe that any time they see two guys in a garage attempting the impossible, that’s a startup. Wrong. It also causes them to miss the numerous other kinds of startups that appear in less-glamorous settings: inside enterprises, non-profits, and even governments. And because both small businesses and startups have a high mortality rate, sometimes these images lead us to believe that any small business is a startup. Wrong again.

So let’s begin with a definition of a startup that captures its essential nature, and tries to leave behind the specific associations of the most famous startups.

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

Let’s take each of these pieces in turn. First, I want to emphasize the human institution aspect, because this is completely lost in the “two guys in a garage” story. The word institution connotes bureaucracy, process, even lethargy. How can that be part of a startup? Yet, the real stories of successful startups are full of activities that can rightly be called institution-building: hiring creative employees, coordinating their activities, and creating a company culture that delivers results. Although some startups may approach these activities in radical ways, they are nonetheless key ingredients in their success.

Isn’t the word human redundant in this definition? What other kinds of institutions are there, anyway? And yet, we so often loose sight of the fact that startups are not their products, their technological breakthroughs, or even their data. Even for companies that essentially have only one product, the value the company creates is located not in the product itself but with the people and their organization who built it. To see proof of this, simply observe the results of the large majorities of corporate acquisitions of startups. In most cases, essential aspects of the startup are lost, even when the product, its brand, and even its employment contracts are preserved. A startup is greater than the sum of its parts; it is an acutely human enterprise.

And yet the newness of a startup’s product or service is also a key part of the definition. This is a tricky part of the definition, too. I prefer to take the most expansive possible definition of product, one that encompasses any source of value for a set of people who voluntarily choose to become customers. This is equally true of a packaged good in a grocery store, an ecommerce website, a non-profit social service or a variety of government programs. In every case, the organization is dedicated to uncovering a new source of value for customers, and cares about the actual impact of its work on those customers (by contrast, a monopoly or true bureaucracy generally doesn’t care and only seeks to perpetuate itself).

It’s also important that we’re talking innovation, but this should also be understood broadly. Even the most radical new inventions always build upon previous technology. Many startups don’t innovate at all in the product dimension, but use other kinds of innovation: repurposing an existing technology for a new use, devising a new business model that unlocks value that was previously hidden, or even simply bringing a product or service to a new location or set of customers previously underserved. In all of these cases, innovation is at the heart of the company’s success.

Because innovation is inherently risky, there may be outsized economic returns for startups that are able to harness the risk in a new way – but this is not an essential part of the startup character. The real question is: “what is the degree of innovation that this business proposes to accomplish?”

There is one last important part of this definition: the context in which the innovation happens. Most businesses – large and small alike – are typically excluded by this context. Startups are designed to confront situations of extreme uncertainty. To open up a new business that is an exact clone of an existing business, all the way down to the business model, pricing, target customer, and specific product may, under many circumstances, be an attractive economic investment. But it is not a startup, because its success depends only on decent execution – so much so that this success can be modeled with high accuracy. This is why so many small businesses can be financed with simple bank loans; the level of risk and uncertainty is well enough understood that a reasonably intelligent loan officer can assess its prospects.

Thus, the land of startups is a unique place, where the risks themselves are unknown. Contrast this with other high-risk situations, like buying a high-risk stock. Although the specific payoff of a specific risky stock is not known, investing in many such stocks can be modeled accurately. Thus a decent financial advisor can give you a reasonably accurate long-term expected return for a set of risky stocks. When the “risk premium” is known, we are not in startup land. In fact, when viewed in retrospect, most startups appear like no-brainers. Probably the most famous example today is Google: how did we ever live without it? Building that particular product was not nearly has risky as it seemed at the time; in fact, I think it is a reasonable inference to say that it was almost guaranteed to succeed. It just wasn’t possible for anyone to know that ahead of time.

Startups are designed for the situations that cannot be modeled, are not clear-cut, and where the risk is not necessarily large – it’s just not yet known. I emphasize this point because it is necessary to motivate large amounts of the theory of the lean startup. Fundamentally, the lean startup is a methodology for coping with uncertainty and unknowns with agility, poise, and ruthless efficiency. It is a completely different experience from the equally hard job of executing in a traditional kind of business, and my goal is not to disparage those other practitioners – after all, most startups aspire to become non-startups someday.

Still, these differences matter, because the “best practices” that are learned in other contexts do not transplant well into the startup soil. In fact the most spectacular startup failures result when people were in a startup situation but failed to recognize it, or failed to recognize what it meant for their behavior.

This definition is also important for what it excludes. Notice that it says nothing about the size of the company involved. Big companies often fail because they find themselves in a startup situation but are unable to reorient in time to cope with this situation; this specific pathology is explored in The Innovator’s Dilemma. This kind of crisis can be precipitated by many external factors: macroeconomic changes, trade policy, technological change, or even cultural shifts. But most often, the entrant of a startup into a previously calm market precipitates this kind of crisis. This has significant implications for general managers in enterprise, about which you can read more at HBR: Is Entrepreneurship a Management Science?

Thursday, September 29, 2016

Announcing the 2016 Lean Startup Week Program

Guest post by Jennifer Maerz, contributing editor of Lean Startup Co. 

The Lean Startup team has been hard at work finalizing the details of this year’s Lean Startup Week. Each year, we bring you new case studies from Silicon Valley startups (and beyond), government agencies, and global enterprise companies, along with expert advice from seasoned entrepreneurs and newcomers alike.

If you’re thinking about joining us at the conference for your annual innovation training on Oct. 31-Nov. 6 in San Francisco, we’ve got a pass for everyone.

Welcome to Lean Startup Week 2016 


TL;DR: Before you dive into the details, here’s a quick look at what you can expect during your week with us:
  • On Oct. 31, kick off the week with a choice of Startup Tours, a Lean UnConference, or an Enterprise Training session. 
  • On Nov. 1, join our morning activities, including a live Q&A breakfast with Eric Ries, a half day of master classes (i.e., hands-on workshops), and our evening Ignite reception. 
  • Our core main conference days are on Nov. 2 & 3. You’ll hear powerful keynotes on the big stage and get practical lessons during our breakout sessions. 
  • On Nov. 4, join a day of coworking at WeWork or attend WMD, a growth and marketing conference hosted by our friends at 500 Startups. 
  • Finally, close the week out by applying everything you learned at Lean Startup Week at Startup Weekend on Nov. 4-6

There are four ways to attend the conference: grab a Gold Pass for the full seven-day experience; a Silver Pass gives you access to the two-day main conference on Nov 2 & 3; a Bootstrapper Pass, which is reserved for very early-stage startups and small non-profits (it’s the equivalent of a Silver Pass, but you’ll need to apply for it); and if you can’t travel to the Bay Area, you can join one of our free livestream meetups and see our main-stage talks live on November 2 & 3.

And now, on to the details…

Monday, October 31: Startup Tours, Enterprise Training, Unconference 


We’ll welcome all Gold Passholders with a mix of Startup Tours, an enterprise-focused training session, and an attendee-led Unconference (in partnership with Lean Startup Circle).

Gold Passholders can head off on the track of their choice: either tours of groundbreaking startups like Pivotal and the non-profit Defy Ventures, among other offerings, or enterprise training with Lean Startup Co. at Breather.

The enterprise training session is a new offering this year that we’re especially excited about: our expert faculty will host five hours of customized master classes for corporate intrapreneurs in a limited-capacity, intimate classroom setting.

In the evening, we’ll have a Halloween-themed Lean Startup Night happy hour. It’ll be held at Runway from 5–6:30 pm with special guests (including Eric Ries) to be announced soon.

Tuesday, November 1: Healthy Performance Practices, Master Classes, Ignite Opening Reception 


We’ll start with icebreakers that’ll energize your mind and body. Choose from running a 5K with ultrarunner Zoe Romano (who ran the Tour de France route), performance breathing with Stanford’s Robert Lee, or meditation and yoga classes with our awesome Lean Startup team members Stacy Conlon and Dave Cunningham.

At the Nasdaq Entrepreneurial Center, Eric will join serial entrepreneur Jason Calacanis (LAUNCH Media) for a Q&A session with attendees. 

Once we’ve helped you get into the right mental space, we’re diving into a half-day of master classes. These workshops will be led by Lean Startup’s rock star expert network and are dedicated to the issues our community regularly tackles.

These sessions, which range from the basics of the methodology to more advanced topics, are excellent opportunities for your team to get hands-on Lean Startup training together while interacting with mentors who’ve been with Lean Startup for years.

In the evening, we’ll host our popular Ignite talks, where select members from our international community have the chance to entertain us with five-minute talks about an aspect of Lean Startup pertinent to the work they’re doing. The Ignite Opening Reception is the official kickoff of Lean Startup Week for all levels of badgeholders. It’s also a great way to learn about all the various ways people are using Lean Startup in a format favoring short attention spans. We pulled from a diverse group of Ignite applicants: folks doing great work in city government, global non-profits, parenting & pregnancy support, and other areas where innovative practices have had a huge impact.

Wednesday, November 2 (Main Conference Day 1, All Pass Holders): Keynote Sessions, Speed Mentoring, Networking Dinners 


Because we have a full week together this year, we decided to kick off the main conference with a single track of activities broken up into four keynote blocks. Now everyone has a chance to hear and absorb a variety of stories and case studies. We have a fantastic lineup of keynote speakers, including industry vets Guy Kawasaki, IBM’s Phil Gilbert, GV’s Jake Knapp, and Microsoft’s Tren Griffin, and rising star founders such as Hint Water’s Kara Goldin, General Assembly’s Matt Brimer, and Breather’s Caterina Rizzi.

Whether these entrepreneurs are speaking about a relatively young business or an internationally established company, the overarching theme here is growing and scaling innovation techniques. It’s no longer enough to have an idea and put a product together. These experts from across industries and around the world will share how they’ve built long-term strategies for innovation into the core and culture of what they do, from tech to telecommunications to government to morning dance parties(!). 

Talks by these prophetic leaders will be broken up into the following four sessions: the definition of and practical issues facing the modern startup, the application of Lean Startup with other methodologies, scaling Lean Startup practices, and Lean Startup put into practice, from corporate to government and non-profit.

We’ll also be offering Speed Mentoring on Nov. 2. All attendees will have the chance to work through specific issues with one of 40 amazing experts from a variety of industries in 20-minute sessions (advance registration will be required, we’ll release the list of mentors over the next few weeks).

And we’ll close the day with a conversation between Eric and Lean Startup Co. faculty member Phil Dillard about the current state of Lean Startup.

We’ll have plenty of co-working opportunities throughout the conference, but if you’d like to concentrate your networking skills over dinner and drinks, you can sign up for one of our Lean Startup Week networking dinners on Nov. 2.

Thursday, November 3 (Main Conference Day 2, All Pass Holders): keynote talks from Airbnb & GE; breakout sessions on startup, enterprise & DIY tracks; mini-intensive sessions; The Startup Chat live; closing sessions 


Nov. 3 will be a day of breakout sessions—discussions, presentations, and fireside chats—themed along specific tracks so you can choose the topics most applicable to your organization. We’ve labeled these sessions as startup, enterprise, or DIY.

DIY is meant to cover a number of different topics, from design to government to funding, as well as the future of work, social good, and government. (Kelvin Kwong of Jawbone will discuss how to design behavior changes in your customers, for example.)

The startup track will feature founders from places like Kit (acquired by Shopify) and 18F sharing how they’ve built their organizations so you can learn how they’ve achieved their level of success. 

For enterprise sessions, we have some great case studies from pros inside Pearson, Telefonica, and Cisco who’ll also discuss team collaboration and leadership development.

Although we’ve focused these groupings for easier scheduling, we highly recommend crossing the hall between startup, enterprise, and DIY chats to get a little of everything—or send your team members to different sessions and compare what you’ve learned at the end of the day.

In the late afternoon, we’ll host intensive sessions at Breather. These four 45-minute interactive discussions will take small groups through such specific topics such as Lean marketing, Lean government orgs, and the founding of Breather.

Also on Nov. 3, we’ll have two special keynotes: from Joe Zadeh, VP of product at Airbnb, and Viv Goldstein from GE’s FastWorks program who will also engage in a joint conversation about intrapreneurship in their organizations.

Throughout the day, we’ll also have some quickie sessions on offer, where you can learn about, say, best practices for live blogging or take a stab at meditation during your lunch hour. And speaking of eating, we’ve invited some of San Francisco’s tastiest food trucks to park on the Pier 27 lot, so there’s no way you’ll go hungry.

We’ll close out the day with AOL co-founder Steve Case, Eric, and MIT Sloan Management Review editor-in-chief Paul Michelman in a sure to be fascinating conversation about the future of entrepreneurship (and, if you’ve been following Eric’s work this year, you know the future of the Long Term Stock Exchange will be involved in that discussion, too).

Friday, November 4-Sunday, November 6: 500 Startups’ WMD conference, Techstars’ Startup Weekend bootcamp 


A Gold Pass gives you access to 500 Startups’ Weapons of Mass Distribution, a one-day conference focused on specific tactics for growing and scaling your startup.

Or if you’d like some team time to collaborate on ideas cooked up during Lean Startup Week, we’re offering coworking options at WeWork and RocketSpace for the day.

Finally, put everything you’ve learned with us into action during a Techstars’ Startup Weekend to cap off Lean Startup Week. This is an excellent opportunity for Gold Pass teams to put ideas into motion and test out those new Lean Startup tools in an environment that fully supports trial, error, and rapid experimentation.

And if you can’t make it to San Francisco this year, we’ll bring Lean Startup Week to you. Sign up to host a livestream meetup or join one that our friends at General Assembly is hosting at their 11 campuses around the world, including New York, Los Angeles, Sydney, Singapore, and London. 

Hope to see you in SF this fall, 
The Lean Startup Week Team

Thursday, September 20, 2012

Workshop: Lean Startup in the Enterprise with Giff Constable, Jeff Gothelf and Josh Seiden

This post was co-written by Eric Ries and Sarah Milstein, co-hosts of The Lean Startup Conference.

On December 4 at The Lean Startup Conference, three of New York's top UX designers will lead a workshop we're really excited about, Lean Startup in the Enterprise. We hope our Q&A here with two of them here today gives you a taste of their sensibility and what you can expect from their session. Gold and Platinum Passes get you into the workshops, and this one is particularly suited to people who are implementing Lean Startup ideas is established companies.

Coincidentally, NewContext—the presenter of this year’s Lean Startup Conference--announced today that these designers, all of them founders of Proof, have joined their company. The crew comprises: Jeff Gothelf, author of the upcoming O'Reilly book Lean UX: Getting Out of the Deliverables Business; Josh Seiden, who was previously the program director for LUXr’s New York City practice, was responsible for design at Liquidnet, and is a founder and past President of the Interaction Design Association (IxDA); and Giff Constable, who has built and marketed consumer applications, games, and enterprise software for many of the biggest companies in the world.

Josh and Jeff answered some questions for us this week:

What aspect of lean startup methods most inspires you?

Josh: I'm really inspired by the customer development angle of Lean Startup. As a designer, my focus has always been on helping teams see value through the eyes of the user. It's exciting for me that the Lean Startup community shares this definition of value.

Jeff: The ability to get a realistic look at our proposed ideas much earlier than ever before. Also, the role of the customer in the process makes the focus of the effort about them—what works best to solve their needs—as opposed to what is best for those involved in the business.

What makes it hard for companies to implement this process?

Josh: So many companies measure employee productivity by measuring output. How many lines of code did you write? Did you deliver the specification on time? But these outputs do not create value. It takes a big shift in management culture to allow teams to pursue value directly—in other words, to measure teams based on the outcomes of their work. 

Jeff: Lean teams need many lines of support from their organizations but the most important one is the freedom to experiment and fail. Without that, the entire build/measure/learn loop collapses into a sea of red tape and CYA activities. Teams need to know that it's safe for them to run experiments, learn from those and then run some more. This freedom is new to many managers who are used to traditional command-and-control styles of management. Lean teams cannot be micromanaged. 

What will people take away from your workshop?

Josh: We're really excited by the potential of Lean Startup in the enterprise, and we know lots of other folks share that enthusiasm. We'll be sharing case studies and techniques, and we expect a lively discussion with others who are putting these methods into practice. This is going to be a very responsive session, so we're hoping that folks come ready to ask questions and share lessons.

Jeff: Attendees of our workshop will hear case studies from the enterprise about how other organizations have tackled the challenges of implementing Lean Startup and what the outcomes were. In addition, we will open the floor to a conversation with our attendees to get a sense of where they're struggling, what's worked/failed for them and sources for their inspiration. Attendees will take away a tactical list of tools and techniques to start implementing these ideas in their organizations the next day. 

Giff, Jeff and Josh are all popular speakers. These videos should give a sense of why. Here’s Giff on “Excuses, Excuses, Excuses." Jeff on “Demystifying Design." Josh on “Replacing Requirements with Hypotheses."

If you’re thinking about registering for The Lean Startup Conference, bear in mind that we’re selling early-bird tickets in blocks. When this block sells out—as of this posting, the current block is nearly gone--the price goes up. Register now for a Gold or Platinum Pass to attend the workshops!

Friday, July 9, 2010

Founder personalities and the “first-class man” theory of management

At any given time, something like four percent of the US population is engaged in some form of new-company-creation. And that narrow definition of entrepreneurship doesn’t count all of the managers inside established companies who are effectively engaged in the same process of building an internal startup (see What is a startup? for my more expansive definition).

What motivates all these entrepreneurs? Typical explanations tend to focus on the well-known anecdotes and larger than life archetypes we have in mind: the twenty-something college dropouts (men, of course) from Stanford inventing some radical new technology. The academic research tells a very different story.

What do entrepreneurs look like? Are they born or made? This is a hard question. I think the root cause of that difficulty is that we tend to conflate two different questions into one. First, what causes someone to attempt entrepreneurship instead of a more traditional career path? And second, what attributes make someone likely to be a successful entrepreneur?

The difficulty lies in this paradox: many of the attributes that increase the likelihood of becoming an entrepreneur actually impede startup success.

Let’s start with the startup personality attributes. The academic research here is extraordinary. Here are the personality traits that are positively correlated with likelihood to pursue entrepreneurship: extraversion, skepticism, need for achievement, risk taking, desire for independence, locus of control, self efficacy, overconfidence, representativeness (the tendency to over-generalize from small samples), and intuition.

I think most of those factors correspond to our shared image of what an entrepreneur is supposed to look like. But many other attributes (especially demographic realities) cut against that stereotype. For example, Vivek Wadhwa and others have shown that most entrepreneurs are much older than we expect. Career experience and industry expertise are both positively correlated with entrepreneurship: contrary to stereotype, most entrepreneurs are not young and inexperienced outsiders. And unlike some psychological factors, these experience-based factors also increase the odds of the subsequent venture being successful.

It is in the psychological factors that we find the most paradox. For example, consider the propensity for risk-taking. Research has demonstrated the obvious: that people who have greater tolerance for risk or ambiguity are more likely to attempt entrepreneurship. That’s not too surprising. But does a risk-taking attitude actually lead to more startup success? The studies that have looked at this question in particular have found a negative correlation between risk-taking behavior and startup success.

That doesn’t strike me as shocking. And, although this hasn’t been subjected to a great deal of study (yet), I believe this same pattern will be found in a variety of other entrepreneurial characteristics: overconfidence, determination to succeed, perseverance, and even the desire to be in control. All of these factors are helpful in getting people to take the plunge, but all of them cause serious impairment of decision-making down the road. Think of the startups you know who are caught in a reality distortion field, heading full-speed off a cliff. Most likely, you will find the above attributes in excess supply.

I believe this is also why breakthrough success stories in entrepreneurship often feature a “classic” zany entrepreneur paired with someone you wouldn’t expect to be taking those kinds of risks. We often talk about this as the “visionary” and “the quant” or the “leader” and the “manager.” But I’m not convinced those labels are right at all. I think it much more likely that we’re seeing the embodiment – in the form of personality - of the “problem team/solution team” organizational structure. One team is in charge of carrying out the vision as currently specified, and one team is constantly asking the skeptical questions: who is the customer? Are we solving the right problem?

Although we have historically viewed this structure in startups by focusing on the personalities of the founders, I think that reflects our current, relatively poor, understanding of how startups work. We can do better by focusing on process instead of personality. We can consciously organize startups to become much more resilient organizations. Otherwise, we risk having them degenerate into cults of personality.

In the early twentieth century, before the advent of scientific management, the overriding management philosophy was that of the first-class man (and they were always men). The idea was, for any job, if you can simply find an individual with just that right combination of virtues, talents, and experience, you could safely delegate all decisions to them. Sound familiar? This kind of reasoning is almost impossible to disprove. If you empower someone to make decisions and then something goes horribly wrong, does that disprove the first-class man theory? Probably not; it’s much easier to blame the particular person who made the mistakes. In fact, making mistakes is seen as “proof” of being second-class.

In management jobs related to operations – that is, the people tasked with actually making and distributing physical products – this kind of thinking is now considered ludicrous, thanks to a century of progress. Our modern philosophy of management has this core belief (taken straight from scientific management) at its heart: that the performance of companies is determined by the systems they create, not just the people they hire. No amount of individual superstardom can overcome a badly organized factory, because the weight of the system eventually overwhelms any well-intentioned but poorly organized resistance.

Yet we tolerate our modern version of the first-class man theory in the management of more “fuzzy” topics, especially innovation and entrepreneurship. When we look back on this period in history, it will seem just as ludicrous to future entrepreneurs as pre-scientific management looks to us.

I am determined to do everything I can to hasten the arrival of that day. If you’re part of the Lean Startup movement, then you’re actually making it happen. Thank you.


All of the academic research alluded to in this essay is drawn from Scott Shane’s General Theory of Entrepreneurship which is a fantastic and wide-ranging overview of the state of the art in academic research on entrepreneurship.

Monday, April 29, 2013

How to Get Picked as a Speaker for The Lean Startup Conference


This post was written by Sarah Milstein, co-host of The Lean Startup Conference.

We’re looking for speakers for the 2013 Lean Startup Conference. Last week, we announced that our short application form was live. Today, we’re following up with answers to frequently asked questions we’ve received since then, because the answers will help your application succeed. If you’re a Lean Startup veteran, feel free to skim the beginning, as this is mostly stuff you already know.

1) Can you tell me more about your audience? The Lean Startup Conference is an event by entrepreneurs for entrepreneurs—except that our definition of “entrepreneur” may be different from the one you have in mind.

Eric has talked often about recognizing a startup as an organization designed to create a new product or service under conditions of extreme uncertainty. Most commonly, that’s uncertainty about whether you can build the product at all (what MBAs call “technical risk”) or whether anybody will use or buy it (“market risk”). Although every organization faces some uncertainty in developing new stuff, the conditions are not always extreme. For example, when your company adds another blade to its disposable razors, the product’s technical development, marketing and sales will follow relatively predictable paths.

But that’s not to say that every established company developing personal grooming products is operating risk-free. What if your company is concerned that emerging customer pressure and local laws will make disposable razors difficult, if not impossible, to sell in the U.S. in ten years? Now you may be facing several kinds of risk. Will you be able to think up alternative products? If so, will customers be interested in the new ideas and able to incorporate those products into their daily routines? If so, will you be able to manufacture those products efficiently—or at all?

So when we say our conference is by entrepreneurs for entrepreneurs, we’re talking about people in any kind of organization—for-profit, non-profit, governmental, education, startup, Fortune 1000—who are responsible for developing products and services beyond the edge of what your organization can know through its or its competitors’ existing experience.

Often, in very young organizations, those people are simply the founders. In more established places, they may have nearly any job title. And in any organization, they can be technical, but they can fill other roles altogether. What they share is a need to learn a lot very quickly and the ability to adjust—sometimes subtly, sometimes radically--after incorporating new lessons.

2) Ok, I get it: the “startup” part of “Lean Startup” can be a lot of things other than two people in a garage with a couple of laptops. So what kinds of talks do all these entrepreneurs find valuable? Our attendees are hungry to learn more about the “lean” part of “Lean Startup”—how to learn quickly and effectively to reduce all that extreme uncertainty (the MBAs call this “de-risking”; it would be fair to call the MBAs “language assassins”).

Now, “lean” is often used to refer to a company’s financial situation, so it might make you think of a bootstrapped or under-funded organization. But when we talk about “lean,” we’re referring to the processes a company can use, when developing a new product or service, to learn quickly about the questions it has. (If you’re getting the sense that “Lean Startup” is neither “lean” nor “startup” as you’ve considered those words before, you’ve got the right idea.) We also care that those learning processes are as cheap as possible, so that you can try the maximum number of things as you’re learning before you run out of cash. “As cheap as possible,” though, is relative and may mean spending many thousands or millions of dollars to learn what you need to know.

For example, if your publishing company is thinking of putting out a coffee table book in the U.S. about cooking with insects, you might reasonably ask: Will anybody buy this? (You know you can produce such a volume; the processes you already use for publishing lavish books on baking cakes nearly all apply here.) One way to find out if anybody will buy the book is to go ahead and publish it. Commission the writer and photographer, assign an editor to develop the book with them, find people to test the recipes, get a copyeditor to review the final text, have production people layout the pages and correct the photos, hire a freelance indexer, get a pro to  proofread the whole thing, and then ship it off to China for printing (and probably send a production expert to oversee the run). Oh, and your salespeople have to make sure bookstores will stock it, and your marketing and PR people will have to make sure readers know it exists. From the time you decided to find out if anybody will buy it until the time you’re able to actually test the idea using this approach is approximately two and a half to three years. Not to mention $200,000 in staff time and hard costs.

Or you could work with the writer to create a blog, see if it can attract a readership, and then test whether those readers will pre-order a book—which you can do before you’ve put ten seconds of effort into creating a print volume. Total time elapsed? Two to six months, and as a bonus, the readers test the recipes for you. Note that this isn’t a free process. You may have to pay the writer and photographer, and perhaps you’ll spend some money on training the writer to use blogging software and social media tools that help them build a following.  Generously, it might cost you $20,000. In other words, you could test ten book ideas for the cost of publishing one. And because you can run your tests simultaneously, you could learn in several months rather than over the course of a decade or two which are worth investing more in.

At The Lean Startup Conference, our attendees are keenly interested in ideas like the blog approach—that is, they’re looking for ways they can quickly and cheaply generate and test more ideas to learn faster. There are a few ways your talk can help them:

  • You can provide advice on how a significant challenge—like a seemingly intractable and long-term development cycle—can be approached in new ways using Lean Startup methods. Last year, Danny Kim talked about how his company, Litmotors, was rapidly testing the market for totally new kinds of cars. While most of our attendees are not in the automotive sector, they could see ways to apply Litmotors’ thinking in their own organizations. Similarly, Diane Tavenner talked about the way Summit Schools had run short-term experiments within the fairly drawn out cycle of a school year. And Jessica Scorpio shared the way GetAround had used prototyping to test their very big idea.

  • You can give hands-on advice for a particular process that helps people learn, like A/B testing. Maybe you’ve got technical advice for getting the most out of A/B testing on software projects. Or maybe you’ve done A/B testing with a food-delivery service and you have advice about how to run real-world A/B tests. Or maybe you've realized that A/B testing has some significant problems that most people aren't aware of. Last year, Janice Fraser and Laura Klein ran a workshop on tools that you can use to validate ideas. Adam Goldstein talked about a particular live-chat tool that Hipmunk has used to learn more quickly than they realized was possible. Matt Brezina shared techniques for learning when you’re developing a mobile app—an environment that many people think resists rapid development.

  • You can give advice about working with other people when you’re using Lean Startup techniques. Perhaps you got fired up about MVPs two years ago, but it took nine months to convince your boss that there would be value in selling a product that didn’t yet exist—and now you can share the secrets of getting other people on board much more quickly. Last year, speakers from Intuit, Meetup, Knod.es, Neo, Change.org and BloomBoard all talked about how you can build internal support for Lean Startup. Dan Milstein talked about using the 5 Whys technique—and gave key advice for doing it better with your team.

  • You can give counter-intuitive advice on implementing Lean Startup techniques. Last year, the co-founders of Back to the Roots talked about their innovation accounting and how they were ignoring sales metrics in order to grow. Charles Hudson shared his hard decision to pivot from the iPhone to Android platform for his company’s games. Jocelyn Wyatt and Tendai Charasika both gave specific examples of how getting out of the building had yielded surprising results.

  • You can give advice about applying Lean Startup ideas to business areas other than product development. Last year, Stephanie Hay and Leah Busque both talked about Lean Startupping their marketing processes. George Bilbrey gave insight on using the methods on a sales team.

I’m sure you see the theme emerging here: our attendees want your advice, based on your experiences. They don’t need to be convinced that Lean Startup provides a compelling alternative to traditional product development, so we are not looking for talks about the fact that you’ve had success with Lean Startup in an unexpected sector or in a part of the world outside San Francisco. But if you’ve applied Lean Startup ideas, and you have experience to share that other people can use, our attendees may derive inspiration from an unusual context, like a story from the pharmaceutical industry or a startup in Nigeria. 

Hopefully, you've also noticed that checking out last year's talks can be a good way to get a sense of what we look for. (The talks linked here all all take you to videos from last year.)

Our talks range from five minutes to three hours, and we structure them based on the information you have to share, so don’t worry too much about length. Focus instead on the advice you can give. 

3) Cool—advice is key. Any particular themes you’re interested in this year? We’re looking for entrepreneurs’ stories from around the world and from different sectors that share deep learning. As this is the fourth year of the conference, and as noted above, we’re moving away from talks about the fact that somebody has applied Lean Startup in a place or company that’s unexpected and are instead focusing on advice from those people. If you need a theme to guide you, ask yourself: What advice can I give other people to help them achieve growth in their organizations?

Based on attendee requests, some of our talks this year will be more in-depth and targeted to segments of our audience. So if you have advice that you think is relevant only to people working in established corporations, or only to government employees, or only to non-profit leaders, or only to innovative educators, or only to engineers, no prob—you can indicate that in your application.

Do note that the conference is a no-hype zone (no pitches, no launches). Really, it's a place to learn and connect with other entrepreneurs. In addition to talks, the program will include peer-to-peer events for sharing ideas and meeting other entrepreneurs, along with structured mentoring.

4) I’m not a coder; should I bother to apply? Glad you asked. About half of our attendees are not technical, and very few of our talks focus on technical processes. So, no, you absolutely do not have to be a developer to give a talk. That said, we do have room this year for a handful of tech talks. So if you’ve got advice to share on implementing a continuous deployment framework, for example, we’re all eyes.

5) Do I have to follow the directions on the application form? Ok, nobody has asked this question yet. But I include it because we pretty consistently find that about a quarter of all applicants blow off the most important part of the form: the link to the two- to three-minute video you have made for us.

Note that that is not “the link to your website” or “the link to a video of you speaking at another conference” or “the link to a video of you being interviewed on tv.” We require that you create a video for us, and we give explicit directions on how to do so. Once you’ve come up with your talk idea, the video itself should take just a few minutes to create. Don’t let it be a barrier to applying. Do follow the directions. Applications are due by May 9 May 16 (we extended the deadline after Kathy Sierra volunteered to provide training for our speakers).

We look forward to reviewing your ideas.

Tuesday, April 14, 2009

Validated learning about customers

Would you rather have $30,000 or $1 million in revenues for your startup? Sounds like a no-brainer, but I’d like to try and convince you that it’s not. All things being equal, of course, you’d rather have more revenue rather than less. But all things are never equal. In an early-stage startup especially, revenue is not an important goal in and of itself.

This may sound crazy, coming as it does from an advocate of charging customers for your product from day one. I have counseled innumerable entrepreneurs to change their focus to revenue, and many companies who refuse this advice get themselves into trouble by running out of iterations. And yet revenue alone is not a sufficient goal. Focusing on it exclusively can lead to failure as surely as ignoring it altogether.

Let’s start with a simple question: why do early-stage startups want revenue? We all know why big companies want revenue – it’s one of two critical halves of the formula for profit. And big companies exist to maximize profit. Don’t startups exist for the same reason? I think such reasoning is an example of the “startup dollhouse fallacy” – that startups are just shrunken-down big companies. In fact, I don’t think revenue is in and of itself a goal for startups, and neither is profit. What matters is proving the viability of the company’s business model, what investors call “traction.” Demonstrating traction is the true purpose of revenue in an early growth company. (Of course this is not at all true of many profitable small businesses, but they are not what I mean by startups.) Before I explain what I mean, let me add an important caveat: traction is not just important for investors. It should be even more important to the founders themselves, because it demonstrates that their business hypothesis is grounded in reality. More on that in a moment.

Consider this company (as always, a fictionalized composite): they have a million dollars of revenue, and are showing growth quarter after quarter. And yet, their investors are frustrated. Every board meeting, the metrics of success change. Their product definition fluctuates wildly – one month, it’s a dessert topping, the next it’s a floor wax. Their product development team is hard at work on a next-generation product platform, which is designed to offer a new suite of products – but this effort is months behind schedule. In fact, this company hasn’t shipped any new products in months. And yet their numbers continue to grow, month after month. What’s going on?

In my consulting practice, I sometimes have the opportunity to work with companies like this. Diagnosis is easy: they are exceptionally gifted salesmen. This is an incredible skill, one that most engineers overlook. True salesmen are artists, able to hone in on just those key words, phrases, features, and benefits that will convince another human being to give up their hard-earned money in exchange for even an early product. For a startup, having great sales DNA is a wonderful asset. But in this kind of situation, it can devour the company’s future.

The problem stems from selling each customer a custom one-time product. This is the magic of sales: by learning about each customer in-depth, they can convince each of them that this product would solve serious problems. That leads to cashing many checks. Now, in some situations, this over-selling would lead to a secondary problem, namely, that customers would realize they had been duped and refuse to re-subscribe. But here’s where a truly great sales artist comes in. Customers don’t usually mind a bait-and-switch if the switched-to product really does solve an important problem for them. These salesmen used their insight into what their customers really needed to make the sale and then deliver something of even greater value. They are closing orders. They are gaining valuable customer data. They are close to breakeven. What’s the problem?

This approach is fundamentally non-scalable. These founders have not managed, to borrow a phrase from Steve Blank, to create a scalable and repeatable sales process. Every sale requires handholding and personal attention from the founders themselves. This process cannot be delegated, because it’s impossible to explain to a normal person what’s involved in making the sale. The founders have a lethal combination of insight about what potential customers want and in-depth knowledge about what their current product can really deliver. As a result, potential customers are being turned away; they can only afford to engage with the customers that are best qualified.

And what of the product development team? They are busy too, but they are not creating value for the company. They are trying to build a product to an ever-changing spec, based on intuitions from the founders about what might be able to sell itself. Worse, the founders are never around – they are too busy going out and selling! Without access to customer data, or even a clear product owner, the product development team keeps building feature after feature based on what they think might be useful. But since nobody in the company can clearly articulate what the product is, their efforts result in incoherence. Worst of all, their next-generation product is so bad they are not allowed to try it out on any customers. The team is thus completely starved of any form of external feedback.

Let me describe a different company, one with only $30,000 in revenue (again, pure fiction). This company has a large long-term vision, but their current product is only a fraction of what they hope to build. Compared to the million-dollar startup, they are operating at micro-scale. How does that stack up?

First of all, they are not selling their product by hand. Instead, each potential customer has to go through a self-serve process of signing up and paying money. Because they have no presence in the market, they have to find distribution channels to bring in customers. They can only afford those (like Google AdWords) that support buying in small volume.

Compensating for these limitations is the fact that they know each of their customers extremely well, and they are constantly experimenting with new product features and product marketing to increase the yield on each new crop of customers they bring in. Over time, they have found a formula for acquiring, qualifying, and selling customers in the market segments they have targeted. Most importantly, they have lots of data about the unit economics of their business. They know how much it costs to bring in a customer and they know how much money they can expect to make on each one.

In other words, they have learned to grow renewable audiences. Given the data they’ve collected about these early customers, they are also able to estimate with modest precision how big the market is for their product in its current form. They may be at micro-scale now, but they are in a very good position to raise venture money and engage in extremely rapid growth.

Our million-dollar startup, by contrast, is stuck in the mud.

Stories like these are what has led me to this definition of progress for a startup: validated learning about customers. (Steve calls this just Customer Validation, but I like to emphasize the learning aspect, so I accept a far more awkward phrase.)

This unit of progress is remarkable in several ways. First of all, it means that most aggregate measures of success, like total revenue, are not very useful. They don’t tell us the key things we need to know about the business: how profitable is it on a per-customer basis? What’s the total available market? What’s the ROI on acquiring new customers? And how do existing customers respond to our product over time?

Secondly, this definition locates progress firmly in the heads of the people inside the company, and not in any artifacts the company produces. That’s why none of dollars, milestones, products or code can count as progress. Given a choice between what a successful team has learned and the source code they have produced, I would take the learning every time. This is why companies often get out-competed by former employees (Palm vs Handspring to name just one), even though the upstart lacks all of the familiar resources, tools, processes, and support they used to have. (Incidentally, it’s also why these upstarts often get sued for bogus reasons. Companies can’t believe they didn’t steal any of their “precious” assets.)

But learning is a tricky thing to quantify, which is why the word “validated” is so important in this definition. Validation comes in the form of data that demonstrates that the key risks in the business have been addressed by the current product. That doesn’t always mean revenue, either. Some products have relatively obvious monetization mechanisms, and the real risks are in customer adoption. Products can find sources of validation with impressive stats along a number of dimensions, such as high engagement, viral coefficient, or long-term retention. What’s important is that the data tell a compelling story, one that demonstrates that the business is on a solid economic footing. (It being so easy to convince yourself that you’re in one of these “special case” businesses, I do recommend you give revenue a long, hard look first.)

For example, I’ve talked a few times about how IMVU raised its first venture round with monthly revenues of around $10,000. This wasn’t very impressive, but we had two things going for us:
  1. A hockey stick shaped growth curve. People often forget the most important part of the hockey stick: the long flat part. We had months of data that showed customers more-or-less uninterested in our product. We were limping along at a few hundred dollars a month in revenue. All this time, we were continuously changing our product, talking to customers, trying to improve on our AdWords spend. Eventually, these efforts bore fruit – and this was evident in the data. This lent our claims about learning and discovery credibility.

  2. Compelling per-customer economics. We had only a small number of customers – if memory serves, only a few thousand active users. But a little math will show that we were making over a dollar per-user per-month. Our cost to acquire a customer on AdWords was only a few cents. Our eventual VC’s were quick to grasp what this meant (in fact, they understood it better than we did): that if our product achieved significant scale, it would be wildly profitable.
These two aspects could be plotted on one simple graph, which tells this equally simple story: if there is a market out there for this kind of product, we are the team that will find it and profit from it. That turned out to be a compelling investment thesis, despite our micro-scale results.

Let’s return to my example of the million-dollar-revenue company. If you find yourself in this kind of situation, what can you do? I’d suggest a few things, each rooted in the idea of breaking down the wall between the two halves of this company.
  1. Go on an agile diet quickly. With a product development team that is not shipping, any agile methodology will surface major problems quickly. Force anyone who is in customer contact to take the role of the Product Owner and insist that they deliver something new on a short regular interval.

  2. Get product into customers’ hands. The sales strategy currently leaves many customers completely un-served (those that don’t qualify for the founders’ personal time). Start using some of those customers as guinea pigs for a self-serve version of the product. Even if the product is absolutely terrible, it will establish a baseline against which the product development team can try and improve.

  3. Build tools for the sales team that reduce the time investment required for each sale. Instead of devoting all product development efforts to building a full-blown product, try building just those parts of the product that would allow the current sales process to go a little faster. For example, could we develop a simple landing page that would allow customers to pre-qualify for sales time? Iterating on these kinds of features has two benefits: it frees up time for the founders and simultaneously starts getting building a feedback loop with the product development team. Pretty soon, the text on that landing page is going to become an effective explanation for what the product does, because if it’s not the salesman will have to spend time re-explaining the product to potential customers. Time-to-complete-a-sale is not a bad metric for validated learning at this stage.
This last point is especially important. Although this kind of team may understand their customers well, they don’t yet know how to talk to them in a standardized way. Without that, they probably won’t achieve significant scale. (For more on how this plays into the process of scaling up, see the Customer Creation stage of the customer development model.) Perhaps they’ll be able to hire someone especially skilled in the marketing skills needed to find this positioning. But in the meantime, by iterating on their product with customers, they have a chance to get there on their own.

Monday, October 19, 2009

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.

Tuesday, September 15, 2009

Gov 2.0 Summit wrap-up

I had an incredible time at the Gov 2.0 Summit in Washington DC last week. I've never seen such a mixed crowd of entrepreneurs, vendors, and policy makers all in one place. There was quite an exchange of ideas. I was thrilled to be included.

I promised to post the slides for my highly abbreviated version of the lean startup presentation, so here they are. As usual, I'll include some of the real-time comments and some of my thoughts below.



Given the time constraints, I organized my presentation around two simple ideas:

STARTUP = EXPERIMENT

FASTER STARTUPS = MORE EXPERIMENTS PER DOLLAR

I tried to make clear my usual definition of a startup, one that has nothing to do with size of company or sector of the economy. But judging from the twitter comments, it's not clear if I was able to make that case. It may be that it will prove a lot harder to make this point in DC than elsewhere:
aptuscollab: Too bad all you #g2s folks got up and left when Eric Ries took the stage. Dude is smart, his lessons apply to internal projects as well.
That's the nice thing about Twitter. You get the straight scoop, no sugar-coating. Any public speaker that doesn't take advantage of it is really missing out.

On to what seems to have stuck:
kwooleyy: #g2s Showed startup OODA loop developed by USAF pilot John Boyd
I included two Boyd-inspired books in the recommended reading list on the right-hand side of this blog: Certain to Win and Boyd: The Fighter Pilot Who Changed the Art of War. With a number of military men and women in the audience, I couldn't resist a plug. Boyd's ideas have inspired a lot of the principles underlying my work.
whorunsgov: Eric Ries: Startups fail not because the technology works, but because no one wants the tech. once it launches. #g2s
The very abbreviated version of Customer Development (channeling Steve Blank).

nickvitalari: Lean startups mean more experiments for dollars and human capital invested #ngenera #g2s
I'm trying to keep hitting on the theme of the human capital waste when we invest our smartest and most creative people into a venture that builds something that nobody wants. Every bit as true for government as for enterprise - and even the two guys in a garage.
dhinchcliffe: Lean startups go faster. Do course correction called a "pivot". - @ericries "Most exciting time in history be an entrepreneur." #g2s
For more on the pivot, see Pivot, don't jump to a new vision. I don't see how it could more a more exiting time to be an entrepreneur, and certainly can't imagine another time when entrepreneurship was more important to our country's future economic prosperity.

marciamarcia: The L word (learning) onstage at #g2s from @ericries. Finally. Startup=Experiment. http://startuplessonslearned.com
Amen! It's natural at a gathering like this to focus on new technology and applications. A lot of conversation was about what "the federal government" should do. But it's all too easy to lose sight of the fact that any government, even one as large as the US, is made up entirely of people. And so the right questions to ask, when we're talking about fostering innovation in any human institution, are: how can we foster a culture of learning and discovery? And it's my hope that the lean startup can provide some guidance in that direction.

Thanks to everyone who made the summit such a great event!


Monday, November 18, 2013

Lean Startup Where You’d Least Expect It

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

We were excited by the response at last year’s Lean Startup Conference to Diane Tavenner’s eye-opening talk on her experience implementing Lean Startup methods at Summit Public Schools, the California charter for which she is CEO and co-founder. Diane’s work suggests that even educational organizations—notoriously bureaucratic and slow—can effectively implement Lean Startup methods. As part of our expanded program this year, we’re looking more deeply at the role Lean Startup methods can play in transforming education and other mission-driven organizations (more on the latter below). To introduce the themes of Lean Startup in education, we’ve invited Diane and Steven Hodas of the New York City Department of Education’s iZone, to a webcast conversation, Testing Lean Startup in Education; both will also be speakers at this year’s conference. Join them on November 21 at 9a PT, along with conference co-host Sarah Milstein. As always, the webcast is free with registration, and we’ll be holding live Q&A, so come with your questions.

For background, we invite you to watch Diane’s talk from last year’s Lean Startup Conference, where she discussed devising an ongoing, iterative development cycle for Summit’s math curriculum, which she reorganized around the principle of student self-designed learning. She and her staff have set a goal of 100% graduation rates from 4-year colleges for Summit students (only 24% of California students even finish high school with the necessary qualifications to attend college at all, let alone complete a degree). At this year’s conference, she’ll provide an update on that initiative.

Steven will be speaking at the conference for the first time this year. He heads the Markets initiative for the New York City Department of Education’s iZone, where he fosters demand for innovative solutions to challenges in education. We asked Steven to talk about his biggest success in implementing Lean Startup methods in the largest school district in the nation, operating with a $25 billion budget. Here’s what he had to say about the importance of community buy-in:

One of the things we’ve had consistent success with is a structured process for collecting and distilling the experience of those who live with the problem on which we’re working. They’re the target lead users of whatever product or process we develop.

We work with firms like IDEO, the Parsons DESIS Lab, and the Public Policy Lab to conduct what is basically ethnographic or field research. It’s not rocket science, but it is a particular skill-set and methodology for drawing out stories and then analyzing them for common threads and deeper or unstated implications.

We then formulate what we’ve learned into a problem definition, which we issue to our communities as a provocation, rather than specification. Depending on the specifics of the process we’re employing, we make the underlying research available to them as well, and bring the stakeholders in for user testing of the work as it’s being developed. This was key in both our GapApp Challenge and School Choice Design Charette. In the first, the target users were middle school math teachers and curriculum coaches. In the second, the audience was 8th-grade students and parents.

Clearly, this process helps put the ‘V’ in our MVP. But perhaps more important, it forces us (and by extension the solution providers) into an empathetic posture. It’s anecdotal in the best sense—small data that’s very rich—and because we took the time to ask and listen, increases the likelihood that they’ll invest more depth and persistence in trying what we offer, and provide more valuable feedback for the next iteration.

And about those failures…?

We haven't had any failures yet, but we've fallen most short (so far) in finding ways to get people—particularly in the central bureaucracy—to accept, let alone embrace, velocity. When you take the “quick” out of quick-and-dirty you just have “dirty.”

Steven and Diane will discuss their most successful, not to mention dirtiest, strategies on November 21 at 9a PT. Register to join us.

Our recent webcast, Lean Impact: Bringing Lean to Mission-Driven Orgs, touched on similar themes. Featuring 2013 Lean Startup Conference speakers Akash Trivedi of KivaZip and Christie George of New Media Ventures, it's a very good starting point for anyone in an organization dealing with potentially competing interests, limited resources, long development cycles, and a desire to create measurable change. Here are a few highlights of that conversation:

Christie, on identifying and knowing your customer: One of the biggest challenges in the social sector in general is around who the customer is. Customer development is such an important part of Lean methodology, and in the social sector there is a real difference between, say, the beneficiary of a service and the traditional customer, who may be paying, who's the donor. I feel passionately about us, as a sector, figuring out how to navigate this distinction. I don't have any easy answers. At root, most social entrepreneurs I know are in the social sector to create change in the world, and so who they care about and who they are really oriented toward is the beneficiary of the service or the product. There is a kind of complicated dynamic when the person that's paying for the service may actually care about a different thing. So the real starting point for me is the introduction of [Lean Startup] principles into the social sector, but into the philanthropic sector as well, so that folks who are considering contributions in this space actually understand that this methodology can yield better, more impactful solutions.

Akash, on the importance of not doing what doesn’t work: [Not] proving your hypothesis is not a failure. Not getting data is a failure. There have been plenty of examples that I've seen where I was really excited about an idea but where the data just proved otherwise. And actually if you put me on the spot, the things I'm most excited about on Zip are the things we decided not to do versus the things that we did to, because to me, as Christie said, when you're tackling some of these abstract fundamental problems that so many people are depending on, you don't have the luxury of getting it wrong. You need to come up with the most optimal, relevant solution, and I think the best way to do that is to cut out what doesn't work.

Christie, on getting buy-in in a hierarchical organizational structure: I've seen organizations do this really with examples. Everyone is susceptible to what other people are doing, and I've often found that if you're in a hierarchical institution the best way to do that is to kind of say, “Hey, look at this experiment that these guys ran over here.” In the social sector we're increasingly seeing more people be vocal about the things that worked and that didn't, and that's like any buy-in process, giving people examples of its working in other places is one way of actually getting buy in when you're otherwise just being stonewalled on the issue.

Akash, on metrics that help organizational learning:
This might be kind of controversial, but one of the metrics we're using is a proxy for impact, believe it or not, is Net Promoter Score. Net Promoter Score is a tool that for-profit companies like Apple, Google, will use to measure their brand strength. And while it's certainly not directly related to impact in some senses, when we think about impact as a nonprofit traditionally and as it pertains to Kiva, you think about the delta in income created, employment opportunities created, are you sending kids to school, all those sorts of things. But I think in a world where, as Christie mentioned, feedback loops are quite long, and in the world that we're navigating, which is quite abstract, and there are no comparables, knowing that our customers, both our trustees and our borrowers, are happy is actually a pretty good proxy for letting us know whether we're moving in the right direction.

--
Register to join Steven and Diane for our free webcast on November 21. Join all four speakers at The Lean Startup Conference, December 9 – 11 in San Francisco. We sell tickets in blocks, and when one block sells out, the price goes up. Register today for the best price possible.


Sunday, December 7, 2008

The hacker's lament

One of the thrilling parts of working and writing in Silicon Valley is the incredible variety of people I've had the chance to meet. Sometimes, I meet someone that I feel a visceral connection with, because they are struggling with challenges that I've experienced myself. In a few cases, they are clearly smart people in a bad situation, and I've written about their pain in The product manager's lament and The engineering manager's lament.

Today I want to talk about another archetype: the incredibly high-IQ hacker who's trying to be a leader. (As always, this is a fictionalized account; I'm blending several people I've known into a single composite. And please forgive the fact that I use male pronouns to describe the archetype. There is terrible gender bias in our profession, but that's a subject for another day. Suffice to say, most of the hackers I've known have been men. As a last disclaimer, please consult the definition of the word hacker if you're not familiar with the controversies surrounding that term.)

It's common to find a hacker at the heart of almost any successful technology company. I know them right away - we can talk high-level architecture all the way down to the bits-and-bytes of his system. When I want to know about some concurrency issues between services in his cluster, he doesn't blink an eye when I suggest we get the source code and take a look. And as soon as I point out an issue, he can instantly work out the consequences in his head, and invent solutions on the fly.

This kind of person is used to being the smartest person in the room. In fact, it's a rare person who can be subjected to recurring evidence of just how stupid the people around them are, and not become incredibly arrogant. Those who have the endurance are the ones that tend to lead teams and join startups, because you just can't be successful in a startup situation without empathy. I would characterize them as intolerant but not arrogant.

When a startup encounters difficult technical problems, this is the guy you want solving them. He's just as comfortable writing code as racking servers, debugging windows drivers, or devising new interview questions. As the company grows, he's the go-to person for almost everything technical, and so he's very much in demand. He throws off volumes of code, and it works. When scalability issues arise, for example, he's in the colo until 2am doing whatever it takes to fix them.

But life is not easy, either. As the company grows, the number of things he's called on to do is enormous, and the level of interruptions are getting intense. It's almost as if he's a country that was immune to the economic theory of comparative advantage. Since he's better at everything, he winds up doing everything - even the unimportant stuff. There's constant pressure for him to delegate, of course, but that doesn't necessarily work. If he delegates a task, and it gets messed up, he's the one that will get called in to deal with it. Better just to take care of it himself, and see that it's done right.

When you're the physical backstop putting dozens of fingers in the damn to prevent it from bursting, you might get a little irritated when people try to "help" you. The last thing you need is a manager telling you how to do your job. You're not very receptive to complaints that when you take on a task, it's unpredictable when you'll finish: "you try getting anything done on schedule when you're under constant interruptions!" Worst of all, your teammates are constantly wanting to have meetings. When they see a problem with the team's process, why don't they just fix it? When the architecture needs modifying - why do we need a meeting? Just change it. And we can't hire new engineers any faster, because you can't be interviewing and debugging and fixing all at the same time!

The picture I'm trying to paint is one of a bright individual contributor stretched to the breaking point. I've been there. Trust me, it's not a lot of fun. And I've also been on the receiving end; and that's not much fun either. Yet, quite often these dynamics play out with ever-increasing amplitude, until finally something drastic happens. Unfortunately, more often than not, it's the hacker who gets fired. What a waste.

What's wrong with this picture?

One of the most exhilarating things about a startup is that feeling of intense no-holds-barred execution. Especially in the early days, you're fighting for survival every day. Every day counts, every minute counts. Even if, in a previous life, you were a world expert in some functional specialty, like in-depth market research or scalable systems design, the compressed timeline of a startup makes it irrelevant. You get to figure things out from first principles all the time, experiment wildly, and invest heavily in what works. From the outside, it looks a lot like chaos. To a hacker, it looks a lot like heaven.

But even a tiny amount of success requires growth. Even with the highest standards imaginable, there's no way to hire just genius hackers. You need a diversity of skills and backgrounds. Suddenly, things slow down a little bit. To me, this is the critical moment, when startups either accept that "process = bureaucracy" or reject that thinking to realize that "process = discipline." And it's here that hackers fall down the most. We're just not naturally that good at thinking about systems of people; we're more comfortable with systems of computers.

If you've ever been abused by a bad manager in your career, it's easy to become traumatized. I think this is the origin of the idea among hackers that managers are idiots who just get in the way. The variations on this theme are legion: the pointy-haired boss, the ivory-tower architect, and of course the infinite variety of marketroids. But whenever groups of people assemble for a common purpose, they adopt process and create culture. If nobody is thinking about it, you're rolling the dice on how they turn out. And, at first, it's OK if the person who's doing that thinking is part-time, but eventually you're going to need to specialize. The alpha-hacker simply can't do everything.

Even in the areas that hackers specialize in, this go-it-alone attitude doesn't work. Building a good application architecture is not just coding. It's more like creating a space for other people to work in. A good architect should be judged, not by the beauty of the diagram, but by the quality of the work that the team does using it. The "just fix it" mentality is counter-productive here. Every bug or defect needs to go through the meta-analysis of what it means for the architecture. But that's impossible if you're constantly fire-fighting. You need to make time to do root cause analysis, to correct the systemic mistakes all of us tend to make.

And taking on too many projects at once is a classic sub-optimization. Sure, it seems efficient. But when there is a task half-done, it's actually slowing the team down. That's because nobody else can work on the task, but it's costly to hand it off. Imagine a team working from a forced-rank priority queue. Naturally, the best person should work on the #1 priority task, right? Not necessarily. If that person is subject to a lot of interruptions, as the people working on the less-important tasks finish, they're forced to keep working down the list. Meanwhile, the #1 task is still not done. It would have been faster for the team as a whole to have someone else work on the task, even if they were much slower. And of course there's the secondary benefit of the fact that as people work on tasks they don't know anything about, they learn and become more capable.

The reason this situation reaches a breaking-point is that it's constantly getting worse. As the team grows, the number of things that can go wrong grows with it. If a single person stays the bottleneck, they can't scale fast enough to handle all those interruptions - no matter how smart they are. And the interruptions themselves make looking for solutions increasingly difficult. Each time you look for solutions, you see a conundrum of this form: you can't hire because you're too busy, but you can't delegate because you can't hire.

All is not lost, though. When I get involved in companies that struggle with this problem, here is the kind of advice I think can help:
  • Introduce TDD and continuous integration. This is one of the bedrock practices of any lean startup, and so it's a common piece of advice I give out. However, it's particularly helpful in this situation. Without requiring a lot of meetings, it changes the perspective of the team (and its leadership) from fire-fighting to prevention. Every test is a small investment in preventing a specific class of bugs from recurring; once you've been successful at building this system, it's pretty easy to see the analogy to other kinds of preventative work you could do. It also helps ratchet down the pressure, since so many of the interruptions that plague the typical hacker are actually the same bugs recurring over and over. TDD plus continuous integration works as a natural feedback loop: if the team is working "too fast" to produce quality code reliably, tests fail, which requires the team to slow down and fix them.

  • Use pair programming and collective code ownership. These are two other Extreme Programming practices that are explicitly designed to counteract the problems inherent in this situation. Pair programming is the most radical, but also the most helpful. If your team isn't ready or able to adopt pair-programming across the board, try this technique instead: whenever anyone is becoming a bottleneck (like the proverbial hacker in this post), pass a rule that they are only allowed to pair program until they are not the bottleneck anymore. So each time someone comes to interrupt them, that person will be forced to pair in order to get their problem solved. In the short term, that may seem slower, but the benefits will quickly become obvious. It's another natural feedback loop: as the interruptions increase, so does the knowledge-transfer needed to prevent them.

  • Do five whys. This is a generalization of the previous two suggestions. It requires that we change our perspective, and instead treat every interruption as an opportunity to learn and invest in prevention.

  • Hire a CTO or VP Engineering. A really good technology executive can notice problems like the ones I'm talking about today and address them proactively. The trick is to hire a good one - I wrote a little about this in What does a startup CTO actually do? Sometimes, a great hacker has the potential to grow into the CTO of a company, and in those cases all you need is an outside mentor who can work with them to develop those skills. I've been privileged to have been the recipient of that kind of coaching, and to have done it a few times myself.
At the end of the day, the product development team of a startup (large or small) is a service organization. It exists to serve the needs of customers, and it does this by offering its capabilities to other functions in the company, and partnering with them. That's only possible if those interactions are constructive, which means having the time and space for people of different backgrounds and skills to come together for common purpose. That's the ultimate task for the company's technology leadership.

I strongly believe that all hackers have the innate ability to become great leaders. All that's required is a shift in perspective: at their root, all technology problems are human problems. So, fellow hackers, I'd love to hear from you. Does this sound familiar? Are you ready to try something different?