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, June 17, 2010

No departments

Big companies have departments. Startups are companies. Startups aspire to become big companies. Therefore, startups should have departments. Right?

Why do companies have departments? There are a lot of reasons: ladder of advancement, sharing of best practices, functional specialization. Each of these benefits also exists in startups, which is why most startups are also organized in departments. But I have come to believe that because of the unique context of startup land, the payoff is a lot smaller than it is for larger companies. Meanwhile the drawbacks of functional departments can cause real and lasting harm.

I once worked at a startup with an exceptional functional department system. The leaders of each department were world-class experts in their respective fields. The team hired only the best and the brightest. Looking back after a few years, it’s evident that many of the people who worked in these departments have gone on to do incredible things in industry. They are leaders, visionaries, founders and managers having tremendous success.

Yet talent organized improperly can lead to failure. I was an engineer on the engineering team. We had to work closely with artists on an art team. We sat in different parts of the building, ate lunch separately, spoke a different specialized jargon, and generally didn’t understand each other. According to the Waterfall methodology in which we worked, this shouldn’t have been a problem. After all, we rarely had to work on the same project at the same time. The art team would often be involved in the specification phase of a new feature, since they were responsible for the look-and-feel of the product. Then we’d build the feature, which would often include tools that were intended for the art team to use to build the parts of the product that they were responsible for (in video game parlance, this is the “art path” that allows artists to get their work into the production product).

Sure, some communication was necessary, especially as artists had to be trained on new tools periodically. But according to the theory, this should have been covered by the various specs and documentation we were rigorous about producing.

If anyone has ever worked in an environment like this, you’ll probably be able to imagine the things that can go wrong. For one, the engineers consider the artists stupid; the artists consider the engineers arrogant. Not a lot of trust builds up that can be used when real disagreements emerge. Instead, there’s a positive feedback loop of bad feelings. And like feedback on a simple microphone sound system, this would occasionally boil over into screeching.

I remember one such meeting vividly. I was the junior guy on a project team; I was called in to do some technical due diligence for reasons that were obscure to me, because the team already had much more senior engineers assigned to it. I was invited to a feature decision meeting, where the team was closing in on a detailed spec. The meeting was tense. The artists on the team had called in the big guns, and VP-level folks were there to explain the importance of certain aspects of the visual design that threatened to be cut. I eventually realized that I was there as part of the same plan – the art team has specifically requested someone technical but unimportant to be able to render opinions that might undermine their more senior opposition. Not to be outdone, the technologists on the team had also brought their big guns, and the meeting was packed with employees of every level – from VP’s all the way down to me.

As the meeting progressed, the temperature kept rising. At first, I couldn’t even follow the recriminations back-and-forth. Eventually, though, I realized what was at issue: the art team was insisting that the UI for this feature have rounded corners. Incredibly, they were willing to bring the company to a standstill to protest that this was an absolutely essential feature. Even more surprisingly, the engineering team was equally vocal about their contention that adding rounded corners would add weeks of development time to the project, which would have pushed it out way past its hard deadline, effectively killing it. On the surface, this was a ludicrous dispute – both sides were willing to kill the project rather than proceed with (or without) a minor UI tweak. Were they just crazy?

I don’t think so. This meeting was just the latest in a series of escalating skirmishes that had taken place over many months. The feedback loop looked something like this. The art team would create a spec for a feature, detailing the UI as best they could. The engineering team would then build that feature, mimicking the UI as close as they could using the current primitives supported by the system. When the art team would review the final product, they were inevitably outraged – it deviated from the spec in ways they considered major. So there would be a lot of scope negotiation at the very end, when it is most expensive. Sometimes, the art team would win the argument, and the engineers would pull a few all-nighters to make them happy, but feeling betrayed at the new additions to the spec. Sometimes the engineering team would win, and the art team would have to accept (and be held responsible) for a feature that didn’t really work the way they wanted, feeling betrayed at the violation of their agreement.

As an isolated incident, this wouldn’t be a big deal. But scope negotiations between departments are an example of an “iterated prisoner’s dilemma” situation, where the same parties repeatedly negotiate, and rely on their previous experience to inform their choices in the current round. Unfortunately, the equilibrium in this particular setup has one overriding outcome: longer and more detailed specs. Here’s why.

The art team feels burned that they didn’t get what they asked for. Last time, the engineers weaseled out of their commitments by point out areas where the spec didn’t specify what was really important to the artists. So this time, they are going to spell out what’s important in even greater detail, to leave less wiggle room.

The engineering team feels burned too, and feels that they were blamed for deficiencies in the spec as if it was their fault that the technology doesn’t really support what the artists want to do. So they react in two ways. First, they actively encourage a more detailed spec, and are more aggressive about pointing out possible inconsistencies. This forces the art team to make concrete decisions about stuff they don’t really care about. Second, the engineering team starts to pad their estimates, knowing that each feature in the spec is not really done when they think it’s done – there’s going to be inevitable scope creep from the art team when they finally see the final result.

What are the consequences of this more detailed spec? For one, it takes a lot longer to create, meaning that the projects themselves get larger in order to rationalize the increased investment in planning. Second, the extra detail obscures the artists’ original intent in specifying the feature, so the engineers are even more likely to miss the big picture and build the wrong things. And lastly, it removes the engineering team’s ability to find breakthrough solutions that might deliver most of the value at a fraction of the cost. They can’t use any discretion for fear of breaking the spec’s contract, even if the changes would probably go unnoticed or even be in the company’s best interests. The lack of trust (and the procedure of the Waterfall methodology) makes it very difficult to ask for clarification or changes in the spec while the implementation is underway.

This feedback is a nasty trap, and it’s just how this room full of otherwise rational adults wound up in a screaming match about rounded corners. It was painful to watch. Now, part of the reason I remember this particular meeting so well is that I wound up doing something considered really radical at the time. I suggested that we change the underlying architecture of our UI system so that the artists would be able to build their own UI pieces themselves and then integrate them into the product without requiring new code every time. It took an incredible amount of politicking and arm-twisted, but I did eventually get the teams to agree to that solution. I’m proud of that contribution, but the reason I tell that part of the story is not to show off, but rather to be able to tell you what happened next. Although both teams got something valuable about the new system, neither was very happy. I had successfully defused the situation, and by reducing the feedback loop between the artists spec and its implementation, I was able to help them realize their goals better. As a technical fix, it was brilliant. As a solution to the underlying problem, it was useless.

Neither side liked me very much for having "fixed" their problem. In particular, the artists felt like I had created a lot more work for them – they were used to having other people grapple with implementation details for them, and now they had to do it themselves. They either had to hire a developer onto the art team itself (unthinkable) or learn those development skills themselves (which was, to be fair, really hard). The engineering team wasn’t happy either. Creating this new architecture was a fair bit of work, and they couldn’t shake the feeling that I had basically sided with the enemy, giving them tools that would require a lot of engineering support but basically deprive the engineering team of any credit for the resulting features.

I’ve now come to believe that this confrontation was a direct result of the partition between the departments in this company, and that rather than seek technical solutions to the disagreement, I would have been better off working to break down those walls.

Let me tell one more story from that same company. I mentioned before the art path, the set of tools the engineering team was required to build and maintain for the art team to be able to create content. Because the art team was considered an internal customer (and “friendly” to boot), we didn’t waste a lot of time making the tools easy to use. Instead, we spent time making sure the exact behavior of the tools were well documented – by engineers, naturally.

This led to some pretty bizarre situations. One time I remember in particular, an engineer fixed a bug that was causing artists’ creations to render in our 3D environment with a skewed rotation. The details aren’t important, but it turned out that under certain relatively common conditions, the objects would come out completely upside-down.

I’m sure this engineer was expecting to be treated as a hero by the art team, since he had just fixed a major bug. But instead he was reviled. Why? The artists had known about this bug for ages, but had just assumed it was a natural part of the system. They had learned that the best way to solve problems is through trial-and-error, doing whatever it takes to get the object to look right. So sometimes the object would come out upside-down, sometimes not. When it did, they’d just invert their original work so that after the upside-down transformation, it looked right. Sure, there was a lot of randomness in whether they would need to take this extra step, but this was nothing unusual. From their point of view, the tools were full of meaningless jargon and bizarre incantations that resulted in nearly random behavior. This bug was not even considered a major one, since at least it had a deterministic fix.

But now you can see what happened when the bug was fixed. A large, but mostly random, sample of objects started rendering upside-down! This required either that we leave the bug in place, or that the art team go back and rework all those thousands of upside-down objects. Neither solution is particularly alluring.

Again, this led to lots of mutual recriminations. Why didn’t the art team come to the engineers and tell them of this bug as soon as it manifested? Why aren’t they smart enough to figure out what the tools actually do? On the other side, why don’t the engineers just deliver tools that work like they’re supposed to? Other more established companies have tools that are intuitive to use, why can’t we?

The solution to this problem is actually really simple. Just create an art path team, composed of some artists and engineers. Force them to live and work in the same physical space, force the engineers to actually do some art production, and force the artists to actually learn what the technical limits of the tools are. As the team gets traction, simply rotate members from both departments through this team, so that the knowledge they gain is eventually diffused through both organizations. And hold the leaders of that team – artists and engineers alike – accountable for a set of clear goals for the tools that are important to the company.

There’s nothing intrinsically difficult about this problem, just as their was nothing intrinsically difficult with the “rounded corners” problem I discussed earlier. The barrier to doing the right thing is the entrenched ideas originating from departments. Who would lead this team? Who would they report to? How would we ensure that the team was faithful to the best practices of both the art team and the engineering team? And plus, do we really want to be cross-training engineers in art and artists in engineering? Isn’t that a waste of time? After all, both teams are already too busy, how can we afford to pull people off and waste time?

This is another variation of the time/quality/money fallacy – the very quality problems that a team like this would address are currently wasting time and causing the team to be “too busy” to invest in the solution. So: enough with functional departments at startups. Let's start holding people accountable solely for their contribution to the only thing that matters: validated learning about customers.

Wednesday, June 2, 2010

The Five Whys for Startups (for Harvard Business Review)

I continue my series for Harvard Business Review with the Lean Startup technique called Five Whys. Five Whys has its origins in the Toyota Production System. I've written about this before in some detail, but this was an opportunity to try and frame it for a general business audience. After all, Five Whys is the most general, most transferable technique in the toolkit, because it can act as a natural speed regulator for any kind of work. (If you're curious about the theory behind this idea, see Work in small batches.)

The Five Whys for Start-Ups - The Conversation - Harvard Business Review

Root cause analysis and preventive maintenance are concepts we expect to see in a factory setting. Start-ups supposedly don't have time for detailed processes and procedures. And yet the key to startup speed is to maintain a disciplined approach to testing and evaluating new products, features, and ideas. As start-ups scale, this agility will be lost unless the founders maintain a consistent investment in that discipline. Techniques from lean manufacturing can be part of a startup's innovation culture.

One such technique is called Five Whys, which has its origins in the Toyota Production System, and posits that behind every supposedly technical problem is actually a human problem. Applied to a start-up, here's how it works....
Read the rest of The Five Whys for Start-Ups.

You can view previous essays in this series here:

Monday, May 31, 2010

Thank you

The past month has been an incredible roller coaster: #sllconf was a trending topic (briefly topping Justin Bieber before the wifi in the hotel gave out), the Web 2.0 Expo Intensive rocked, the mainstream media has started writing about the Lean Startup, and - most of all - the movement continues to grow and evolve. Having had a few weeks to recover from the adrenaline crash, I find myself full of gratitude.

First of all, the Startup Lessons Learned conference exceeded my wildest expectations. I could barely keep up with the reaction in the weeks leading up to it; the transition from cynicism to hype almost caused whiplash. Sean Murphy has an excellent and comprehensive roundup of resources about the conference: all of the slides, videos, summaries, notes and write-ups are listed on his blog here. I'd like to call special attention to Kurt Carr's perspective (let's hope he finishes his five-part series):
Now that I’m back in Ohio (I was one of the token foreigners in a room full of Silicon Valley residents), I have found myself reliving and rethinking much of what I saw there. It has taken me a while to integrate what I learned into my experiences but I think that I have gotten at least the MVP version of that integration completed. These posts are the result.

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

It’s not that I was ignorant of the fundamentals of Lean Startup thinking, but that hearing these fundamentals discussed by some very intelligent, experienced folks helped me transform and internalize that knowledge. I had really debated about whether there was any value in spending the time and money to fly to San Francisco when there was a perfectly serviceable simulcast going on in Cleveland. All I can tell the folks who attended the simulcasts is that I’m not missing either the time or the money.
(You can read the rest of his posts on his blog: Introduction, Part 1, Part 2.) All video from the conference is available for free at Justin.tv here. It's in reverse-chronological order, so start with page 3 or just use Sean's handy reference..

I am grateful to everyone who helped make this event a success, especially my co-organizers Charles Hudson and David Sachs. Erin Turner helped organize the dozens of simulcast venues. All of those venues had their own local organizers who deserve our thanks as well (especially those in distant time zones who had the stamina to watch live). And a special thanks is due to all of our presenters, panelists, and mentors. You are the ones that consistently blew the audience away.

One of the themes of the conference was that we all stand on the shoulders of giants. I'd like to supplement that with some personal thank-yous.

Steve Blank has been a mentor to me for several years. He had the courage to speak out about the need for a rigorous theory of entrepreneurship long before that was a popular idea. When I first encountered customer development, it was considered pure lunacy by mainstream entrepreneurs and VC's. He inspired me to take a deeper look at what we all thought we understood about startups. We all owe him our thanks for persevering. His latest project, to reform the teaching of entrepreneurship worldwide, will have no less an impact. Do you know the difference between Durant and Sloan? If not, you'd better watch video of his talk ASAP. And then you can buy a t-shirt.

Kent Beck is deservedly famous for his many contributions in the software industry. His characteristic humility and clear thinking were on display as he casually demolished one sacred cow after another. Although many of the non-technical folks in the room didn't understand what was happening in the moment, plenty of hackers were on high alert. By the time he was done, he had launched a new Agile Manifesto:
Team vision and discipline over individuals and interactions (or processes and tools)
Validated learning over working software (or comprehensive documentation)
Customer discovery over customer collaboration (or contract negotiation)
Initiating change over responding to change (or following a plan)
And he made it seem like no big deal. Of course ideas have to evolve and change. How often do you see that level of intellectual honesty on display? Thank you, Kent.

Randy Komisar is someone I am pleased to consider a friend and mentor. We were colleagues briefly at KPCB, where Randy has been working not just with individual companies, but also working to change the mindset of entrepreneurs everywhere. Unfortunately, the video of our sllconf conversation is not online (due to technical problems), but we have a physical tape backup which we are endeavoring to get online soon. In the meantime his two books, The Monk and the Riddle and Getting to Plan B are both a must-read.

There are so many more people to thank: Sarah Milstein and the Web 2.0 Expo team for their tireless efforts to give us a fantastic stage in San Francisco (my keynote and Steve Blank's are both online), Steve Lohr at the New York Times for two great pieces on the Lean Startup concept (The Rise of the Fleet-Footed Start-Up and What Start-Ups Can Teach Big Companies), Pui-Wing Tam of the Wall Street Journal for exposing the larger movement to a mainstream audience (with minus points for calling me a guru), Harvard Business School professor Tom Eisenmann who has helped behind the scenes, conference sponsors (especially Steve Anderson), Mark Graban and the Lean Enterprise Institute, my comrades-in-arms and fellow-bloggers (you know who you are, including David Binetti for correcting my spelling), and my family and friends who have supported/put up with me during this intense roller coaster.

Most of all, I wanted to say a huge thank you to all of you: readers, entrepreneurs, agents of change. I get more credit than I deserve for being in the right place and the right time, putting your aspirations and frustrations into words. Together, I believe we are changing the face of entrepreneurship. If that's true, it's primarily due to your hard work, building companies and testing new ideas. Entrepreneurship is the life-blood of our global civilization. We all owe you. Thank you.



Ad unblocked, will come back on page reload
To unblock this ad, click left button in the bar above

Thursday, May 20, 2010

Philosophy Helps Start-Ups Move Faster (WSJ on the Lean Startup)

The Wall Street Journal covers the Lean Startup movement in today's paper. Although the article is a bit me-centric, I think they did a good job capturing the fact that this is more than just the bloggers and writers, but represents a shift in thinking among entrepreneurs all over the world. The article includes comments from Kevin Dewalt and Drew Houston. Even Marc Andreessen weighs in. I think this means we've officially diffused our first major misunderstanding (that lean means cheap and small) - congratulations. Apparently, the article is in today's print edition (in the Bay Area section), but I'm in the wrong time zone to see it.


Here's an excerpt:
Philosophy Helps Start-Ups Move Faster - WSJ.com

Silicon Valley entrepreneurs and venture capitalists often churn out how-to business books and fancy themselves as management gurus, but few see their methodologies adopted. Eric Ries is experiencing something different.

...
"Eric is espousing a different way to build companies," says Kevin Dewalt, 40, an entrepreneur in Arlington, Va., who has organized three Lean Startup meetings for Beltway entrepreneurs since October 2009. All the events sold out, says Mr. Dewalt, adding, "We've realized entrepreneurship is a unique management science.'

Mr. Ries's Lean Startup philosophy aims to help new companies make speedier decisions by taking a more disciplined approach to testing products and ideas and using the resulting customer feedback.

Sunday, May 2, 2010

The Lean Startup Intensive is tomorrow at Web 2.0 Expo

I'm extremely excited that tomorrow is the Lean Startup Intensive at Web 2.0 Expo. This is basically your last chance to sign up, and if you do so, the fine folks at TechWeb have offered me a last minute 25% discount code that you can use: websf10lean25.

The agenda for the day is below. As you can see, this is a new collection of speakers and case studies, in an intimate venue, which should allow maximum dialog between presenters and attendees.
Session 1 9:00-10:15
Eric Ries: Welcome & Introduction to Lean Startup 9:00-9:30
Steve Blank: Customer Development 9:30-10:15

AM Break 10:15 - 10:45

Session 2 10:45-12:00
Sean Ellis: Product/Market Fit & the Startup Pyramid 10:45-11:30
Matt Brezina: Xobni case study, "The 5 stages of Xobni's growth and 5 pivots along the way" 11:30-12:00

Lunch 12:00 - 1:00

Session 3 1:00-2:15
Dave McClure: Startup Metrics 1:00-1:35
Dan Martell & Ethan Bloch: Flowtown Case Study 1:35-1:55
David Binetti: Votizen Case Study 1:55-2:15

PM Break 2:15 - 2:45

Session 4 2:45-4:00
Panel: Investing in the era of the lean startup 2:45-3:45
- Moderator: Dave McClure
- Panelists: Ann Miura-Ko, Josh Kopelman, Jeff Clavier
Hiten Shah & KISSmetrics team: Case study 3:45-4:15

Joint session with the Applied Communilytics Intensive (including Q&A with Eric Ries, Sean Power, and Alistair Croll) 4:15-5:00
 I hope you'll join us. If you do, please come say hello.

PS. For those of you planning to attend the full Web 2.0 Expo, I'll also be presenting a keynote on the main stage on Tuesday at 4:45pm: "The Lean Startup: Innovation Through Experimentation. Not Just for Startups Anymore."

Thursday, April 29, 2010

Video update on the Startup Visa Act

The Startup Visa Act continues to gain momentum on Capitol Hill, thanks to grassroots support of all of you. Without lobbyists or PACs, we're getting the word out in DC and nationwide that we have an opportunity to act - this year - to create jobs right here in America by supporting entrepreneurship and innovation. As bills in both chambers of Congress pick up supporters and co-sponsors, it's more important than ever for citizens who care about this issue to call, write, and tweet their representatives.

On our most recent trip to DC, the Startup Visa team produced two new videos to encapsulate our work to date, and hopefully inspire future action. They feature two of the rock stars of the Startup Visa team, Shervin and Brad, looking like, well, rock stars. Please take a look and, if you're as inspired as I am, please take a moment to help spread the word, embed these videos, or take another action outlined below. Thanks!

Shervin Pishevar, activism at 30,000 feet.
"My big belief in the Startup Visa Act: Entrepreneurship is very much representative and symbolic of what America's all about."




Brad Feld, the Startup Visa Act.
"When you think bout the economic stress and economic crisis we've been going through in this country, and you think about future economic growth, there's no question that entrepreneurship and innovation is a huge driver of future success."



Want to get involved? We have a list of ways on the StartupVisa website:
  1. Go to our campaign page & tweet your support NOW! (<30 sec)
  2. Write your local newspaper & tell them you support the Startup Visa Act
  3. Call your senators & let them know you support Startup Visa legislation
  4. Add the Startup Visa Widget to your blog or website
  5. Follow the #startupvisa hash tag on Twitter and voice your support
  6. Contribute to Startup Visa so we can spread the word!

In particular, we are also working on a letter of support from university presidents and entrepreneurship professors across academia. If you know someone who might be willing to sign on to that letter, please contact Brad Feld, who is organizing the letter.

Monday, April 26, 2010

Lean Enterprise Institute webinar, April 28

I can barely write, as I'm still recovering from the amazing but overwhelming Startup Lessons Learned conference last Friday (great summary here). I'll follow up with a more detailed post later, but for now let me just say: thank you to everyone who participated, spoke, sponsored or helped organize. It exceeded my expectations totally.

Want to learn more about lean startups? Want to talk about applying the lessons beyond software, internet, and small companies? The Lean Enterprise Institute, the official keepers of lean, are hosting a free webinar on Wednesday, April 28. Details are below. This will be a unique cross-cultural meeting between entrepreneurs and traditional lean experts. I believe we have much to learn from each other.

920 people from over sixty countries have already signed up to attend - help us break 1000 by registering here.
Lean Startups
Lean mindsets and methods for innovation in any company
a free webinar featuring:
Eric Ries
April 28, 2010 at 2:00 PM EDT

The "Lean Startup" is the application of lean thinking to the process of innovation in startup companies — defined as a type of business where both the problem (customer need) and the solution (product) are unknown. Traditional product development efforts often invest millions of dollars and years of time into one fixed product concept that is assumed to meet known customer needs — creating a high level of risk that the "waste of overproduction" occurs and creating a product that customers reject. The "Lean Startup" methodology, instead, tests new ideas early and cheaply, with early and frequent customer feedback. Critical to product success is creating a learning feedback loop that's company-wide, continuously testing new ideas so that idea failure doesn't have to equal company failure. Iterating more quickly is the key to success rather than having the one initial perfect concept.

Since successful startups grow into larger mature companies, how do the lessons from "Lean Startups" apply? How can businesses of all shapes and sizes use lean methods to be innovative and disruptive? Where a startup is a high uncertain opportunity in a highly uncertain business, how can more stable businesses use these methods for their new uncertain products or ideas? How do familiar lean manufacturing mind sets and philosophies for quality management, training, and problem solving contribute to innovation?

Specifically, you will learn:
  • How to define "value" in an innovation setting
  • What is a "minimum viable product" and why is that preferable to big batch
    development?
  • How to create a blame-free development culture that encourages learning, root
    cause problem identification, and improvement
  • How a process focus can lead to discipline, not bureaucracy
  • How to apply the right learnings from "Lean Startups" to a non-startup environment
Who Should Attend:
This webinar is designed for a broad audience: everyone who is interested in learning how companies with unknown problems and solutions can use rapid P-D-C-A cycles to better understand and meet customer needs. This is intended for anybody who is working on new innovations, whether that means continuous improvement at the front lines, or new product development in a mature manufacturing company.
I hope you'll join us. More information is available here.

Sunday, April 18, 2010

Four myths about the Lean Startup

Myth: Lean means cheap. Lean startups try to spend as little money as possible.

Truth: The Lean Startup method is not about cost, it is about speed. Lean Startups waste less money, because they use a disciplined approach to testing new products and ideas. Lean, when used in the context of lean startup, refers to a process of building companies and products using lean manufacturing principles applied to innovation. That process involves rapid hypothesis testing, validated learning about customers, and a disciplined approach to product development.

Myth: The Lean Startup methodology is only for Web 2.0/internet/consumer software companies.

Truth: The Lean Startup methodology applies to all companies that face uncertainty about what customers will want. This is true regardless of industry or even scale of company: many large companies depend on their ability to create disruptive innovation. Those general managers are entrepreneurs, too. And they can benefit from the speed and discipline of starting with a minimum viable product and then learning and iterating continuously.

Myth: Lean Startups are small bootstrapped startups.

Truth: There’s nothing wrong with raising venture capital. Many lean startups are ambitious and are able to deploy large amounts of capital. What differentiates them is their disciplined approach to determining when to spend money: after the fundamental elements of the business model have been empirically validated. Because lean startups focus on validating their riskiest assumptions first, they sometimes charge money for their product from day one – but not always.

Myth: Lean Startups replace vision with data or customer feedback.

Truth: Lean Startups are driven by a compelling vision, and they are rigorous about testing each element of this vision against reality. They use customer development, split-testing, and actionable analytics as vehicles for learning about how to make their vision successful. But they do not blindly do what customers tell them, nor do they mechanically attempt to optimize numbers. Along the way, they pivot away from the elements of the vision that are delusional and double-down on the elements that show promise.

Saturday, April 17, 2010

Sneak preview, KISSmetrics (and more)

Hear the CEO of KISSmetrics give a sneak preview of what he'll be presenting at the Startup Lessons Learned conference on April 23 (we're less than a week away!):




Conference updates continue to pour in:
  • Want to see more preview videos? Take a look at our new sneak-preview site, sponsored by KISSmetrics.
  • We've updated our list of simulcast locations (see below). Thanks to volunteer organizers around the world, the conference is now available on every continent (well, except Antarctica) and in almost fifty cities. Most of these events are free, but they do require that you RSVP. An up-to-date list of simulcast locations is always available at http://sllconf.com/streaming.
  • Our sponsors continue to support the conference as well as deserving entrepreneurs. Three premier early-stage venture investors have joined forces to sponsor the event: Baseline, Floodgate, and First Round Capital. In addition to supporting their portfolio companies in coming to the event, they also have taken the additional step of underwriting a limited number of discounted tickets that are available to the general public. The latest batch, sponsored by First Round, is available here.
Thanks again to all of our amazing sponsors, volunteers and staff who are working very hard to make this event a reality.

Africa
Asia
Europe
North America
Oceania
South America

Wednesday, April 14, 2010

Sneak preview, Grockit

Hear the CEO of Grockit give a sneak preview of what he'll be presenting at the Startup Lessons Learned conference on April 23:

Monday, April 12, 2010

The Lean Startup Intensive at Web 2.0 Expo SF (May 3, 2010)

I'm discovering the truth of the old saying, "when it rains, it pours." I keep waiting for the tide of interesting people, opportunities, and ideas to ebb - but so far it has done nothing but accelerate. Thank you all so much. Just one year ago, I gave my first big conference talk at the 2009 Web 2.0 Expo in San Francisco. I had no idea what to expect, and the response was truly humbling. So I am particularly excited that the Lean Startup is a big part of this year's Web 2.0 Expo. Steve Blank and I are both giving keynotes in the main conference track. And for those who want more than just the overview, we're offering the Lean Startup Intensive on the first day of the conference: May 3, 2010.

We've built the Intensive into an all-star program designed to give a comprehensive overview of the methodology, taught by its leading practitioners. Unlike the conference on April 23, the Intensive does not assume any prior knowledge of lean startups, and is designed for a wide audience. Anyone who's thinking of attending the Expo will get something out of it. I believe it will be the first time each of the following speakers will be presenting a full session back-to-back: Steve Blank, Dave McClure, Sean Ellis, Hiten Shah, Dan Martell, as well as an investing panel which we'll announce soon. Here's an excerpt from the official program:
“A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.”
All entrepreneurs face the same fundamental challenges:
  • How do we know if we’re making progress?
  • How do we know if customers will want the product we’re building?
  • And, if they do, how do we know what kind of value we can create with it?
But because every startup also strives to become an institution, answering these questions requires more than just disciplined thinking at the whiteboard. It requires the coordination of many different people, working in concert to answer them. In other words, it requires management.
[...]

This event brings together the leading thinkers and practitioners of the Lean Startup movement. The goal is to provide a complete introduction to the theory as well as a grounding in advanced techniques that you can put to immediate use.

This program is designed for people who have a stake in creating great products: engineers, designers, product managers, marketers and businesspeople—from companies of any size. And, of course, for present or future entrepreneurs who are hoping to do more than punch a lottery ticket.

Read the rest here...

I'm incredible excited about the lineup, and think it'll provide the world's first comprehensive introduction to these ideas. If you're thinking of attending the Web 2.0 Expo, I hope you'll consider spending your first day with us. 

To sweeten the deal, we also have a special 25% discount code which you can use for either the Intensive itself or for a whole Expo pass. The code is websf10ls25 and can be redeemed here. And there are still a (very) few application spots open for a complete conference pass scholarship; details are available here.

So yes, there are two major lean startup events coming up in San Francisco in the next month. Both are going to be amazing, so take your pick. And, as always, if you do decide to stop by, please say hello and let me know you're a reader. I'm looking forward to meeting you.