Building a new startup hub

Last week, I had a unique opportunity to spend some time in Boulder at the behest of TechStars. It was a great experience to see a relatively new startup hub in action - and thriving. It's easy to take Silicon Valley for granted. The startup scene here can be ostentatious and serve as an echo chamber, amplifying the cool trend of the week into a deafening roar. But there's no denying the level of support for entrepreneurs that we enjoy. I've written a little bit about the origins of Silicon Valley because I think it's important for us to understand how we got here in order to make sure we preserve what is best about our community.

Traveling to Boulder I had the feeling of stepping back in time. It felt like I was watching a new startup hub in the process of being created. The companies I spoke to all agreed that the community there was extremely supportive, especially in the critical ulta-early-stage. That community is, by all accounts, relatively new - less than five years old according to several folks I asked. Even more impressive is that the culture there seems to have been the conscious creation of just a few people.

On my brief visit, the results were impressively on display. If you watch the video/audio below, you'll get to see some of the questions I was asked after my presentation. On the whole, I found them unusually sophisticated - and mostly rooted in the actual practice of entrepreneurship. I also did quite a bit of asking questions myself. I spent most of my time with TechStars, who were my hosts for the trip. Their model looks like a key ingredient in the startup brew there. Every summer, they bring approximately 10 companies to Boulder for an intense "accelerator" experience (don't call it an incubator, or you'll get dirty looks). They don't invest a lot of money; just enough to keep them going through the summer. They take common stock, not preferred, a fact that the entrepreneurs mentioned to me many times. And they expose the startups to a vast network of mentors, none of whom get paid for their involvement.

Some of the mentors are based in Boulder, but many are not. As a result, the companies get a lot of exposure to VC's, investors, and partners in larger, more traditional startup hubs. And, as one entrepreneur put it to me, "we understood that a big part of our responsibility in the program was to make sure the mentors have a good experience, by taking their advice to heart and giving them a feeling of being part of our evolution as a company." As a result, for a lot of these companies, Boulder is just a gateway to San Francisco. TechStars encourages them to go wherever opportunities take them. But even the companies that move on have had a taste of life in Boulder (it looks awfully nice). And every year, it looks as if one or two entrepreneurs from the program decide to stay.

That strikes me as a really smart formula for building a startup hub. First, pick a place that entrepreneurs (and other creative class-types) would love to live. Great weather, a strong university, outdoor sports, cafe culture, good restaurants - you get the idea. Then, create an encouraging environment for early-stage companies. You don't need massive amounts of capital available for VC investment - modest amounts will do. Accept that many successful companies are going to want to be backed by big-name firms in other cities. Instead, focus on getting them ready for that stage. Provide early seed capital, and be the ones to make those introductions. Make your city a gateway to other opportunities, so that entrepreneurs can increase their access by starting there. And do your customer development. If you talk to early-stage entrepreneurs who randomly landed in Silicon Valley, you'll hear just how hard it is to break into the scene here. Because you're not asking entrepreneurs to forsake those bigger cities, it's a no-brainer to give your city a shot.

Anyway, those are my thoughts after having spent only a few days in Boulder. You can see that it stimulated a lot of ideas; you'll have to evaluate the veracity of those ideas on your own. In the meantime, let me keep my promise of some multimedia. I did my best to capture video and audio; a YouTube playlist and Slideshare slidecast are below:



Slides (with audio):

2009 08 19 The Lean Startup TechStars Edition

View more presentations from Eric Ries.

And, as usual, I wanted to share some of the audience reaction with my commentary. These quotes are, as is my custom, straight from twitter.

My biggest thanks goes to the people who generously sponsored scholarships for others to attend the dinner and workshop, Thank you so much!

ericries: special thanks once again to @fancy_free and @KISSmetrics for sponsoring scholarships for the #leanstartup workshop in Boulder.

I'm also excited to share two long-form reviews from actual attendees. I'm always excited to see how these ideas are expressed by entrepreneurs in their own words:

petewarden: Another blog post, this one on the @ericries Lean Startup Workshop I attended: http://bit.ly/4UWuf #leanstartup

tmarkiewicz: Notes from the Lean Startup Dinner with @ericries http://bit.ly/80kKW #leanstartup

And I can never resist sharing some positive feedback. I hope you'll indulge me - I need to have a copy of these testimonials for the record:

neilsimon: Thanks @ericries for the #leanstartup tips last night. Articulate, inspirational.

jdegoes: Great talk from @ericries last night. Inspiring ideas: real-time biz metrics; safe continuous deployment; A/B split testing. #leanstartup

feverishaaron: @ericries thanks for droppin' facts at the #leanstartup dinner. Learned a lot and enjoyed the discourse.

KevinMSmith: Excellent discussion on #leanstartup w/@ericries. If you get a chance go see him. If you don't get a chance , MAKE ONE. He's that good.

lmckeogh: Best $50 I've spent in last yr as unempl. prod mgr. #leanstartup dinner Boulder full of useful info that I want to apply [echo @roger_tee]

ultimateboy: #leanstartup was the most invigorating event I've ever attended. Thank you @ericries for drastically altering my perception of agile startup

Thank you all so much for your kind words. I was really overwhelmed this time. Now for some actual content:

jeantabaka: Really liked @ericries answer to adding in quality while still a startup #leanstartup

If you want to hear the exact question and answer, check the video. This was a question about how we convinced our investors to "allow" us to invest in quality after we'd shipped the initial buggy version of IMVU. That's always a tricky relationship to navigate, but we found a way to get our investors on board with that program by practicing a form of radical transparency. When they could hear the customers' complaints in their own voice, it became clear when it was time to up the quality level. We also had the benefit of many lean practices that break out of the "time, quality, money - pick two" paradox. (You can learn more about that by reading The engineering manager's lament.)

Here are two more questions that I really enjoyed answering:

roger_tee: At #leanstartup dinner w/ Eric Reis. Asked where I find visionary early adopters who pay 4 buggy beta SW. Killer answer.Ask me. #bdnt

nbauman: When to split test? Anytime anyone on the team thinks it could make a macroscopic change. Define macroscopic change! #leanstartup

I could recap these - but just go watch the video already!

And one last specific practice that came up at this session:

feverishaaron: UI, design and programmers are all in the same department, all have the same title, and all are evaluated the same. #leanstartup

We organized our engineering team at IMVU to try and maximize cross-functional collaboration. That meant getting designers, programmers, and QA folks to cross-train and work together as peers. By expressing these values as part of the formal structure of our department as well as the formal evaluation system, I think we went a long way towards reducing the usual internecine conflict between these groups.

Let me close with one last thought. I think it speaks for itself:

peterhoskins: At least have the courage to make new mistakes. #leanstartup

Thanks to everyone who participated and helped make these great events!

Marching through quicksand

I have been spending a lot of time lately talking to people in various media companies: editors and agents, executives, journalists, producers and directors. It’s a fascinating time to see content industries in action, because they are facing a constantly changing landscape and are really trying to keep up. In other words, they are facing conditions of extreme uncertainty, just like startups. So I generally feel right at home in these conversations.

Most pundits and the people I ask for advice fall into one of two camps. One is explaining the world as it used to work: the importance of gatekeepers, the scarcity implied by limited distribution, and the resulting quality bar that the industry is so proud of. The other revels in the world as we all know it will be someday: limitless distribution enabled by new technologies, the importance of collaborative filters, and on-demand availability of all content for end-users. The problem with engaging with either camp as an author (or “content creator”) is that neither camp is really addressing the world as it exists today. The old models are broken, and we do not yet have new models to replace them. For established media empires, this is a scary fact. But, as any startup can tell you, this opens up a tremendous set of opportunities for the rest of us.

As I talk to established media companies, their responses are surprisingly uniform. I have in mind an image of each industry marching along in lock step, one after the other. I place them roughly in this order:

Movies > Television > Books > Music > Magazines > Radio > Newspapers

Each industry is watching the one in front of it sink into the quicksand. Their reaction seems to be relief that at least they are not as bad off as the industry in front of them. Thus does everyone enjoy a nervous chuckle at the plight of newspapers. But this relativism obscures one essential fact: everyone is sinking! It’s just taking some longer than others. What accounts for the difference? Mostly it is the time and expense required to create the means of distribution for that industry. Because it is much more expensive to launch a Hollywood movie than a printed book, for example, it’s taking digital technology longer to work its way through the complete supply chain for that industry. But make no mistake, disruptive innovation has happened, and the established supply chains are going to change accordingly.

So let’s turn our attention from what may happen in the future to what is definitely happening in the present. Here are a few of my observations from the trenches:

Personal brands are displacing organizations brands. I used to be skeptical of all this talk of “personal brand.” But I now believe it is at the center of the disruption changing the face of media. Because of the incredible array of information available, we have a desperate need for filtering mechanisms. But the traditional media brands simply aren’t good enough. Does anyone really watch the full NBC lineup anymore? Or follow all of the New York Times columnists equally? It’s an artifact of the old large-batch distribution mechanisms that we bundle all this somewhat-related content together.

This is good news for everyone except those who have huge legacy investments in large-batch distribution. Customers will get to consume the content they want, and support the producers of that content directly, rather than having to rely exclusively on intermediaries. And once you have a relationship with an author, musician, or journalist, it will be quite easy for them to offer new products and services – and for you to give them feedback that helps them shape ever more interesting (and ever more profitable) offerings. But there is a serious drawback: finding new creators is getting difficult. There are just too many of them out there.

Now, helping potential customers discover new things they might like is the job of the discipline of marketing. But that job is changing dramatically, and this brings us to the next major problem facing traditional media organizations:

Media companies are failing at marketing. Most of the people I meet in marketing at traditional media companies are struggling with the realization that their new job is to cultivate new personal brands and to constantly explore new ways to help people discover and deepen their engagement with those brands. The key tools of this new marketing are: targeting, filtering, and customer insight. Mass blasts of information are ineffective, because the broadcast channels are suffering from information overload (even in social media). There are too many products clamoring for attention.

But the same technologies that make life difficult for traditional marketers also offer them unprecedented new opportunities. Test-marketing is now easier than ever before, thanks to leveraged distribution channels like AdWords and Facebook. Scaling up successful tests is easy for the same reason. Most importantly, it’s now possible to have detailed analytics on exactly what’s happening to messages and ideas as they flow through word-of-mouth channels. In the old days, the brand manager of a consumer packaged goods product had to spend energy inferring the effectiveness of their television ads through a combination of trailing indicators (like market share) or time-consuming market research. No longer. Anyone who puts out a marketing message today and doesn’t know exactly what happens to it is suffering from willful ignorance (what I term Datablindness).

Gatekeepers are overloaded. Gatekeepers, who decided what material was published, where dollars were invested, and had a tremendous responsibility for predicting future consumer demand, dominated the world of traditional media. All successful media companies had at their heart a series of editors, producers, and agents tasked with discovering and developing new talent. Look at the stories of the current generation of aging superstars in any industry. They all have a story of how they were discovered, how their first breakthrough work was cultivated by a skillful (or lucky) individual gatekeeper. You can’t turn on a television these days without hearing about how this happened to Michael Jackson. But the idea of artists being discovered is heading towards obsolescence in a world when anyone can start a personal brand anytime, anywhere. The new “discovery” will be a continuous series of events, starting with a niche following and, for the successful artists, gradually transitioning into mainstream success. It will look much more like the technology life-cycle adoption curve than like a tournament system – and that is a good thing for creators of all sizes.

I’ve met a lot of gatekeepers in the past few months. They all have one thing in common: the world’s most painful case of information overload. Ever-more artists and authors are petitioning them. As the costs of production fall, it’s getting easier and easier to send in a proposal or even a complete work. And thanks to the radical transparency enabled by the internet, the quality of these proposals is actually constantly rising, to the point that it’s almost impossible to judge the quality of the final product – because all the proposals look polished and professional, even the terrible ones.

Thus, the selection criteria for gatekeepers has moved almost entirely away from the content itself and to an elusive quality called the “author’s platform” (in publishing; each industry seems to have its own version of this same concept). This is the total number of activities that the author has engaged in – other than writing – that causes people to give them attention. Think of it this way: every person on earth is ranked on a scale from zero to Oprah. When she says to buy something, millions of people do it. How many people follow your recommendations? This is an important question, but it’s not directly related to the kind of content an author actually produces. Unfortunately, this content-less decision-making process is inhibiting the ability of media companies to develop interesting new content at the very time when this supposed expertise should serve as their one true competitive advantage.

Despite all the energy invested in talking to authors about the size of their platform, very few gatekeepers have a rigorous set of metrics for measuring it. My blog has over 14000 subscribers, for example. Is that a lot? I have given more than two-dozen paid speeches this year – is that a lot? When I reviewed a recent product development book, it immediately shot up to Amazon sales rank 300. Is that good? These are pretty interesting anecdotes, but they are hardly the kind of serious approach that these questions deserve. In the absence of real data, gatekeepers are having to rely on much more tenuous indicators. And as everyone’s attention starts to focus on those same indicators, their value is being diluted. Which leads to the next problem:

We need new status indicators. One of the legacy functions of the established order that has not been adequately addressed is the creation of status indicators. For example, the best book reviewers only review books published by the best publishers, which only accept manuscripts from the best agents. These reviews can launch good books onto the big mainstream bestseller lists, which then provide self-sustaining growth (similar to the dynamics of App Stores). Even if a self-published book was every bit as good as one published by a top-tier press, how would the reviewers know? They can’t even consider 99% of published books already. And how could they possibly review a blog? The problem is that there are no other metrics they can look at to judge the content of a book to know if it’s worth reviewing.

We faced this same problem in entrepreneurship and venture capital, but we are getting past it. Seed-stage investors are learning the metrics of traction, and are getting better at identifying those companies that are really achieving validated learning about customers. They can make smart investments even if the entrepreneurs are not well credentialed or have a product/idea that is outside the mainstream of what investors are expecting As this change has rippled up the venture industry, it has meant a lot more worthy companies are getting funded than just a few years ago.

The biggest lost opportunity of all, though, is this one: we no longer need to rely on scarcity or status-oriented measures to filter which projects should get the green light. Just like in the world of startups, we can start to use micro-scale pilot programs, executed in lean fashion, to gather real facts for making ROI decisions about new project investment. Most publishers are still caught up in an outdated “vision vs. metrics” argument, which is already obsolete here in Silicon Valley. We’ve learned that data can be used as a reality-check against vision without diluting the mission or reverting to “sum of all features” focus groups.

Consider this question: what percentage of all books that are purchased does the buyer actually finish reading cover-to-cover? I'm not sure we really know the answer - yet. But thanks to new distribution technologies like the Kindle, we will soon. And that will open up an interesting new way to value books. If a previously unknown title has a higher-than-average customer engagement across a wide demographic, it might merit additional investment – even if the total number of units sold is quite small.

And as we consider specialized niche topics, like business, technical or educational content we can get even more precise. If our goal is to teach, persuade or inform with our content, we can measure our success at those goals. There is no reason why all written content that is produced today for those purposes couldn’t be split-tested – at least to a segment of its audience. Digital versions of these books could have built-in comprehension tests and mini-feedback forms, all of which could evaluate the level of understanding of the reader. Even if only a small percentage of readers or viewers participate, we will be able to get an accurate read on the effectiveness of each piece of digital content.

It’s time for us to start thinking of every piece of content – books, blogs, albums, TV shows, movies, everything – as a new little startup. We have to look at fundamental business questions right from the start: what is the right audience? What is the right revenue model? And, most importantly, what could we do right now to answer the riskiest of these questions. In other words, what is the minimum viable product?

Just like with startups, this is a hybrid question. If our goal is just to create a blog or a YouTube video as a hobby, there’s no need for this kind of rigorous process. And if you want to write the great American novel – and don’t care if anyone reads it – you don’t need this either. But for the rest of us, who create content because we care passionately about having an impact on the world, we need to rethink the process by which we do it. We can’t just delegate the business questions to some media executive.

For people raised in a traditional media environment, this probably sounds scary. In fact, traditional media specialized in keeping authors and creators in a kind of bubble world, so they could “focus on their creativity” but that in reality served to keep them in a constant state of dependency. That made sense in an era where ownership of the means of distribution was more important than ownership of the means of production. But we don’t live in that world anymore. Fellow creators, trust me – this new world is incredibly liberating. Sure, you have to pay attention to your own business, you need to own your own brand, and you need to engage in dialog with your customers. But guess what? Every minute you spend on those activities is spent actually honing your ability to shape the world through your art.

I have no illusions that this new order is going to quickly displace the old. In fact, it’s not even clear that would be a good thing. What matter is that somebody steps into the void being created by this disruption. If traditional media companies adapt, so much the better. If not, there are plenty of alternatives.

So, to all those struggling with how to build an information-distribution channel in this brave new world, let me make a few concrete suggestions. First off, every customer who interacts with any of your creators should have the option to subscribe to all of their future work, every time they interact. For bonus points, make this a paid subscription. Your creators should always have a simple way to talk to current and potential customers in any segment. Make it easy to “pilot” new work with a test community of actively engaged readers, and provide a mechanism for measuring the impact of these pilots. And anytime you strike a deal for digital distribution of any content, insist that your creators be given real-time access to the big-picture metrics: not just downloads, but engagement, retention and replay.

The media companies that will make the transition in the coming years will be the ones that embrace this principle and devote themselves to helping creators, authors and artists develop as entrepreneurs as well as craftspeople. If they don’t, there are a new breed of lean startups who understand this deep in the bones ready to take their place.

The Promise of the Lean Startup

I'm honored to have a guest post on GigaOm to introduce the concept of the lean startup to their audience. It's the most general-purpose overview I've written so far, and although it was a lot less specific than my usual, I wanted to share it here, too. I'll share an excerpt and then I'd like to ask, once again, for your help.

Here's the excerpt:

Today’s high-tech entrepreneurs have at their command more than just the ability to invent new technologies — they have mastered the discipline and the methodology required to harness those technologies in order to serve customers. Such a combination of new technology and new understanding is unlocking new opportunities. In order to maximize such opportunities, this generation of entrepreneurs combines extremely low costs with faster cycle times to produce what I call lean startups.

[...]

The ultimate goal of a lean startup is to identify where its vision intersects with what reality can accommodate. It is neither a capitulation to “what customers think they want” nor a willful ignorance of conditions on the ground. It is a company built to learn.

As a consequence, this new startup is relentlessly metrics-driven. It tries out new ideas with a fraction of customers in order to prioritize using facts, not opinions. Its unit of progress is that of validated learning about its customers. Because this radical notion of progress is located firmly in the heads of its employees, and not in any artifacts they produce, the lean startup is employee-centric and knowledge-obsessed. It is a truly fun place to work.

This article also appeared on BusinessWeek.com.

Read the rest of the article here...

I have written several guest posts for other blogs that I haven't cross-posted here, including for VentureBeat, O'Reilly Radar, and The Four Hour Workweek. When I do this in the future, should I cross-post or not? I would welcome your feedback in the comments.

Now for my request. I get asked regularly to do guest posts, and I'm quite often at a loss for topic ideas. I know the audience on this blog, and I've become comfortable writing in the long-form style I normally use here. I've struggled to come up with topics that work in the shorter-form world of traditional and news-oriented blogs. So, if you have a topic suggestion, please post it as a comment. Ideally it'd be something you think would be useful to a general business or tech audience and could be addressed in a short piece or possibly in a series.

Thanks again for your continued support. Your feedback means a lot to me, so keep it coming. I know I've had a lot of events-related posts lately, but I'm doing my best to keep it balanced with more substantive essays. Am I getting the mix right? Please let me know in the comments. Thank you.

Related articles by Zemanta

• The Promise of the Lean Startup (gigaom.com)

Fall speaking tour starts tomorrow

Tomorrow morning, I hop on a plane to Boulder, Colorado to kick off the largest speaking tour I've ever attempted. I'm doing my best to keep the sidebar of events updated, for those that are interested in coming. I'll continue to post updates, slides, and video as I get them.

After Colorado, in September I'll be in DC for Gov 2.0 Summit - my first of two trips to DC. The second trip to DC will come a week later as part of Geeks on a Plane Europe. The exact itinerary hasn't been announced yet, but it will include a stop at Seedcamp in London. Back in the US, I'm really honored to be giving the Entrepreneurial Thought Leader lecture at Stanford on Sep 30.

Most of October will be taken up by a second trip to Europe. I don't have cities and dates to announce yet, so stay tuned. That trip should culminate in a week of events around Oredev in Sweden the first week of November. I'll announce details as soon as they are confirmed.

In November, I'm doing two events at the Web 2.0 Expo NYC, immediately followed by an event or two in Boston - details to be announced. On December 10, we'll have the third Lean Startup workshop with O'Reilly, also in NYC. There'll be a November tech talk at Facebook, for those of you in Palo Alto. Unconferences? We've got those too - please say hello if you make it to foo camp or The Lobby.

And, just to give a sneak peak, in February I'll be traveling down under. Can't say any more, yet, but will have details announced soon.

Given that so many of the travel logistics are still up in the air, if you're interested in hosting an event nearby one of these stops, please get in touch. I'll do my best to accommodate. And, as always, if you're a reader and can attend, please come say hello. Bring your tough questions and your feedback. I really value both.

One last note. Some of these events are expensive, some are free. For the costly ones, I'm doing my best to make scholarships available. Joe Mathes set a great example by sponsoring a ticket to the Boulder workshop out of sheer generosity. Thanks, Joe! If you're interested in sponsoring or in seeking a scholarship, just drop me an email.

Hope to see you soon!

Introducing the Lean Startup Cohort subscription program

Over the past few months, I have been engaged in another customer discovery exercise with passionate early adopters of the lean startup methodology. I am now ready to move into the customer validation phase. This idea is the brainchild of several venture-backed startups that participated in the lean startup workshops. I like it because it will allow companies that want to engage with me directly to also get support from their peers. Although it is expensive, it is significantly cheaper than my very limited consulting practice. So if you're a lean startup earlyvangelist, read on.

Here's the pitch: a group of 10 companies would meet once a month for six months to develop their capacity to run lean. Each company would enroll two leaders in the series, one on the technology side, one on the business side. These companies would be carefully screened for fit, readiness, and to ensure that competitors are not in the same group.

At each half-day meeting, we'd work as a group on a specific lean startup technique. In particular, we would cover customer development, continuous deployment, minimum viable product, and actionable metrics. In between sessions, this cohort of companies would have the opportunity to act as a learning community, sharing what they've learned and supporting one another as they try to put the techniques into practice. Each month, we'd hold each other accountable for making changes to our product, process, and team. I would also be available to the participants to answer questions one-on-one and act as an advisor to each company. This program would be by subscription only; each company would pay $3000/month. Each half-day session would be held in downtown San Francisco in the late afternoon; dinner is included.

Because of the cost and intensity of this program, it is designed for startups with significant venture backing or who have reached profitability. I continue to work on additional programs and products for bootstrapped and angel-backed startups, as well as for enterprise and future entrepreneurs. If you have thoughts about a product you'd like to see created, please feel free to drop me a line.

If you're interested in participating in the inaugural Lean Startup Cohort, please click Here to fill out an application.

Revisiting the Software Design Manifesto (and what's changed since then)

My recent article on technical debt and its positive uses generated a fair bit of controversy. One of the topics that raised heated debate was whether I had conflated technical design with product design, because I made the admittedly counter-intuitive claim that sometimes good technical design actually leads to increased technical debt. You can follow some of that debate here and here; I continue to believe that this idea is correct.

The argument itself got me thinking a lot about design and its role in building products. As a profession, we have a set of intuitions about what good design looks like, and I've come to believe that some of these intuitions have become obsolete. In this post, I'd like to explore the reasons why.

I thought a good place to start was with the origins of the idea that "software design" should be considered a discipline in its own right, on par with computer science, software engineering, and computer programming. Over the years, many people have advocated for this idea, but I wanted to go back to an early source: Mitch Kapor's original Software Design Manifesto. We owe a lot to this seminal document. Re-reading, I was struck by how much of it we now take for granted. And as Kapor himself points out, the core ideas have even older origins:

The Roman architecture critic Vitruvius advanced the notion that well-designed buildings were those which exhibited firmness, commodity, and delight.

The same might be said of good software. Firmness: A program should not have any bugs that inhibit its function. Commodity: A program should be suitable for the purposes for which it was intended. Delight: The experience of using the program should be pleasurable one. Here we have the beginnings of a theory of design for software.

This simple three-part framework underlies almost all discussions about technical design today, and it was clearly on display in the recent debates over technical debt. What's interesting to me is how much we have tended to focus on Firmness and Delight as the key elements of technical design. A Firm design is one that works reliably, that has a transparent internal structure, and is easy to change. Great engineers see it and smile. And Delight is a similar feeling, but for a different constituency: the end-user. In the more than ten years since the original Manifesto, we've made strides in both areas. User-centric and interaction design, test-driven development, continuous integration, services-oriented architectures - the list goes on. Although some of these practices are counter-intuitive, they all have been gradually adopted as their benefits become clear.

But what about Commodity? I think this is the area where our intuitions are most out of step with the new reality we are living in. In antiquity just as much as in the early days of software engineering, Commodity was rightly understood as a mostly static quality. Sure, during the requirements and specification phases, there might be a lot of prototyping and iterating. But once the design was locked and implementation began, the intended purpose was relatively well understood and not subject to revision.

To be clear, that didn't mean that the design didn't change. Kapor addresses that directly:

In general, the programming and design activities of a project must be closely interrelated. During the course of implementing a design, new information will arise, which many times will change the original design. If design and implementation are in watertight compartments, it can be recipe for disaster because the natural process of refinement and change is prevented.

These principles are every bit as true today as then. What's changed is that these interactions used to be confined primarily to the implementation phase of the project. The kinds of "new information" in the quote above are implementation details. The design may call for a certain look-and-feel that is impossible to implement, or has negative performance implications, which would require changes in the design, which might uncover additional issues, etc. This back-and-forth would continue up until the project entered its certification phase. Over time, if everything's working right, the magnitude of the design changes should become smaller and smaller, as the team converges on the final design.

But notice something interesting about this process. At no point is the overall purpose of the design changing. It doesn't start life as a toaster and end the design process as a microwave. Of course, it's possible that after the product is shipped and customer feedback is solicited, the next product design might be different. But think of the time-scale involved - in antiquity as well as a few decades ago. Building a cathedral takes years, and so even if the design of one cathedral affects the next, that's not particularly relevant to practitioners in the here-and-now. The same is true of a traditional waterfall-style IT project (although hopefully measured in months or years, and not decades). Yet a huge class of modern software projects are being developed in a very different context.

When it becomes possible to build products "live" with customers, the cycle time changes and design becomes a much more dynamic process. We still struggle to create Firm software that is defect-free, and it still requires customer insight (and maybe some customer development) to discover what will Delight. But it's Commodity that has become the most unstable. Every time we execute a product pivot - changing some elements of our vision but not others - we change the very purpose of the product being designed. My belief is that it's this increase in the rate of change that is what is causing our technical design intuitions to go haywire. It's like our compass no longer points to true north (like on Lost).

Let me quote an example that I used recently:

Remember IMVU's initial IM add-on product? It had a pretty good technical design. Here why:

- it kept each IM network in its own separate module, and made it really easy to add new IM networks by composing a set of common objects
- it separated the underlying transport from the IM "session" itself, so it was robust in the face of the underlying client acting strangely, going away, or even having conversations switch clients altogether
- it compacted all of its information into brief, human-readable text messages that could be sent over any IM network in the clear

Those were strictly technical design decisions, and I think they were really good. Unfortunately, when we realized the product design was not what customers wanted, we had to pivot to a new product. But we had to bring that old codebase with us. Now the assumptions and abstractions that had served us well started to serve us badly. When we became a standalone network, it didn't matter how easy it was to add new networks, since we never did. And having the session abstracted from the transport made debugging much harder. Worse of all, the plaintext codes we were used to sending were considered non-authoritative, since they could be pulled off a third-party network. This made the actual transport much more difficult on our first-party network than was really necessary.

As a result, we have had to be constantly refactoring this design, a little bit at a time, to smooth out these rough edges. These design changes feel a lot like the interest payments incurred by technical debt. My argument is that there is no distinction to be had. That "good design" turned out to be technical debt, after all.

What I object to most is the idea that technical design is a linear quantity. There's no such thing as "improving the technical design" in any absolute sense. You can only improve it with regard to whatever the purpose of the current product is. When that purpose is changing, we're necessarily chasing a moving target.

There are huge opportunities that become unlocked when we recognize this change. For one, we have to abandon any pretense of a linear design process, that imagines that we'll design something, implement it, and then get feedback on it. As has been going on in the world of manufacturing for many decades now, we have to engage in these activities concurrently. This is called set-based concurrent engineering (SBCE). [1] We also have to recognize the important impact of batch size on the work that we do. When we work on a product in small increments, we accelerate feedback to each participant who works on the product. This includes the designers as well as the engineers and product managers. This is what allows them to have a constant stream of insights about the true Commodity of their design, and to change it when it's time to pivot.

This has big implications for where we should spend energy. As I mentioned in the technical debt piece, our choices are usually framed as a set of either-or trade-offs between quick-and-dirty hacks and slower but more elegant designs. Lean methods present a third option: to invest in our process so that our design gets more feedback sooner and is more adaptable to changes in purpose. (The economics of these process trade-offs are discussed in the Principles of Product Development Flow.)

Returning to the subject of technical design, this yields a new criteria for a good dynamic technical design. It should still be Firm, and still promote Delight for our current customers. But it should also be resilient to changes in purpose, even dramatic ones. That means that the internal design of the product is now inseparable from the process that is used to build it. It is time for software design to grow up, the same way manufacturing had to evolve beyond Taylorism. And as with all scientific evolutions, it's not that the old principles are discarded or proved to be false. What's new is that we have learned to apply those principles in new contexts, like the extreme uncertainty that is the soil in which startups grow. We may have to change our practices to adapt to this new reality, but that doesn't mean we don't owe a debt of gratitude to those who helped us get here. So, in that spirit: thanks, Mitch. We'll do our best to leave the next generation something of comparable value.

[1] For more on SBCE, see this MIT Sloan Management Review article. Here's an excerpt:

In a previous article, we called Toyota’s product development system the “second Toyota paradox.” TPS was the first; its features seem wasteful but result in a more efficient overall system, such as changing over manufacturing processes more frequently (presumably inefficient) in order to create short manufacturing lead times. The second paradox can be summarized in this way: Toyota considers a broader range of possible designs and delays certain decisions longer than other automotive companies do, yet has what may be the fastest and most efficient vehicle development cycles in the industry.

Traditional design practice, whether concurrent or not, tends to quickly converge on a solution, a point in the solution space, and then modify that solution until it meets the design objectives. This seems an effective approach unless one picks the wrong starting point; subsequent iterations to refine that solution can be very time consuming and lead to a suboptimal design.

By contrast, what we call “set-based concurrent engineering” (SBCE) begins by broadly considering sets of possible solutions and gradually narrowing the set of possibilities to converge on a final solution. A wide net from the start, and gradual elimination of weaker solutions, makes finding the best or better solutions more likely. As a result, Toyota may take more time early on to define the solutions, but can then move more quickly toward convergence and, ultimately, production than its point-based counterparts.

Minimum Viable Product: a guide

One of the most important lean startup techniques is called the minimum viable product. Its power is matched only by the amount of confusion that it causes, because it's actually quite hard to do. It certainly took me many years to make sense of it.

I was delighted to be asked to give a brief talk about the MVP at the inaugural meetup of the lean startup circle here in San Francisco. Below you'll find the video of my remarks as well as the full slides embedded below. But I wanted to say a few words first.

First, a definition: the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Some caveats right off the bat. MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don't need the MVP. In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Second, the definition's use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense. As I talked about in a previous interview, IMVU's original MVP took us six months to bring to market. That was a pretty big improvement over a previous company, where we spent almost five years before launching. Yet in another situations we spent two weeks building a particular feature that absolutely nobody wanted. In retrospect, two weeks was way too long. We could have found out that nobody wanted the product a lot sooner. At a minimum, a simple AdWords smoke test would have revealed how utterly bad the concept was.

Without further ado, the video:


Slides are below:

Minimum Viable Product

View more presentations from Eric Ries.

The Steve Jobs method

Image via CrunchBase

It's been a long time since I did a post that was primarily a link to another blog with commentary, but I came across something today that I really want to share. One of the most common questions I get about the lean startup methodology is, "but what about Steve Jobs?" When I try to unpack what people mean by the question, here's my best take on what they are asking: "Look, Steve Jobs doesn't go out and ask customers what they want. He doesn't put out crappy, buggy products and then ask for feedback. And he doesn't shy away from big-bang launch events. He tells customers what they want, and he gets it right. So how do you reconcile his success with the lean startup, which seems to suggest the opposite?"

I rarely give a satisfactory answer to this question, because I don't know Steve, nor have I worked at Apple or Pixar. So I can't speak for what happens on the inside. Luckily, neither can most of the questioners who pose that conundrum to me. We all seem to have a mythical sense of how Jobs works, based mostly on speculation and our very human desire to believe in heroes.

My normal answer is that I don't really think that's how Apple products are built. Plus, the premise of the question misunderstands the lean startup, too. Like any good pundit, that lets me pivot back to talking about something I do know about.

So imagine my delight when I saw this blog post with excerpts of a Steve Jobs interview. Here's the key quote:

Steve Jobs on why Apple doesn’t do market research - Bokardo
It’s not about pop culture, and it’s not about fooling people, and it’s not about convincing people that they want something they don’t. We figure out what we want. And I think we’re pretty good at having the right discipline to think through whether a lot of other people are going to want it, too. That’s what we get paid to do.

The key phrase for me is "having the right discipline to think through whether a lot of other people are going to want it." That's what so many techniques that I advocate are all about: customer validation, minimum viable product, vision pivots, and even throwing away working code. Getting customer feedback is emphatically not about abandoning your vision or abdicating responsibility for innovating. Instead, it's about testing visionary ideas against reality, to discover what really works. Put another way, feedback's not about you - it's about them. When a customer tells you how they feel about your ideas, that doesn't tell you anything about your ideas. It tells you something about what that customer thinks and feels. Figuring out whether and how to incorporate that new information into your vision is your job. As Steve says, "That’s what we get paid to do."

Now, I can't speak to what process Steve Jobs uses to get his team to do this market assessment. Maybe they do it at the whiteboard. Maybe they just have great gut instincts. Or maybe there is the occasional potential customer or early prototype involved. But I'm willing to make some guesses. Here's how I make sense of their success. From here on out, this is strictly my imagination talking. To be clear, I don't know if Apple really works this way.

First, note the important use of work-in-progress constraints (kanban). As Steve says in the source interview:

Apple is a $30 billion company, yet we've got less than 30 major products. I don't know if that's ever been done before. Certainly the great consumer electronics companies of the past had thousands of products. We tend to focus much more. People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.

Having so few products means Apple can dedicate enormous resources to each project once it gets the green light. But it also means they have to be very careful kill projects if they are not trending towards something great. Which comes to the second major principle: halt work that leads to more waste, even if it means abandoning sunk costs. This is a version of the andon cord technique from lean manufacturing. Steve describes it like this:

At Pixar when we were making Toy Story, there came a time when we were forced to admit that the story wasn't great. It just wasn't great. We stopped production for five months.... We paid them all to twiddle their thumbs while the team perfected the story into what became Toy Story. And if they hadn't had the courage to stop, there would have never been a Toy Story the way it is, and there probably would have never been a Pixar. "We called that the 'story crisis,' and we never expected to have another one. But you know what? There's been one on every film.

These two principles combine to free up tremendous resources for raw R&D and innovation, because so few people are stuck working on "death march" internal projects or maintaining low-success released products. What do all those other people do? For one, capacity development. Apple has a track record of creating lots of interesting enabling infrastructure, like Quicktime and Bonjour, which sometimes become key to their products and othertimes not. My guess is they have lots of people constantly working on interesting new tools for their designers to play with. Those new capabilities must translate into a constant stream of prototypes - most of which turn out to be utterly bad ideas.

The real question is: how do they evaluate a prototype to know if it's a good idea? If they were an unknown web 2.0 startup, they could release the app and see how customers respond. But that would be a disaster for Apple, so whatever testing they do has to happen in secret and behind closed doors. (For startups that are tempted to mimic this behavior, I suggest reading the great account of the early Apple in Founders at Work.) Regardless, they must cull a lot of bad ideas for every one that we hear about. Holding his team to a high standard for what constitutes a great idea is what I imagine to be the most value-creating part of his job.

Most executives, especially in startups, don't have the courage to hold their teams to a high standard for new products or features. Just because something looks pretty, or feels like a good idea, or has a lot of sunk cost in it, does not mean it should be pursued. Not even if it's generating revenue. The only efforts a new product team should be expending are those that lead to validated learning about customers. Here's hoping Steve will share those techniques with us someday. In the meantime, I hope some of you will find the lean startup a helpful framework.

Overall, here are the lessons I take from (the imaginary) Steve Jobs:

• Hold your team to high standards, don't settle for products that don't meet the vision, iterate, iterate, iterate.
  
• Be disciplined about which vision to pursue; choose products that have large markets.
• Discover what's in customers' heads, and tackle problems where design is a differentiator.
• Work on as few products as possible, keep resources in reserve for experimentation.
• Start over (pivot) if you find yourself with a product that's not working.
  

As I said, applying these principles in a startup is different from a very high profile public company. I've tried to abstract them a little so we can examine them at a level where they might translate. So far, everything I see is compatible with what I believe. So thanks, Steve, for the inspiration, the great products, and the great advice. Here's hoping future innovators who will follow in your footsteps are reading today.

Time for me to sign off - my Macbook Air is really burning up my lap. Hey, Steve, seriously, this viable product is a little too minimal...