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...

A new way to recruit for (and find) startup jobs

In my work, I come across a lot of great startups. A common question I get asked is "do you know someone amazing that we can hire?" Similarly, I get pinged by many colleagues, friends, and fans who are looking to find a job with a startup. I do my best to play matchmaker, but as those of you who have ever tried to fill a job in a startup know, the most important and elusive quality for a startup hire is fit. Unfortunately, as any good recruiter will tell you, this is not an easy thing to assess as an outsider.

So I used to wind up spending a lot of fruitless hours trying to play matchmaker, and generally having a hard time. Part of the problem is that I couldn't post a public link. Most of the jobs I come across are not listed in any directory, and most of the candidates are not officially looking - many don't even have a resume. Great startups are always hiring, if the fit is right. They may not have an open req for a specific job, but if the right amazing person walks in the door, they will always find something productive for them to do.

To solve this problem, I asked a friend to collaborate with me in building a new tool. It's incredibly simple, and it's called joblink.tw. Think of it as a bit.ly for jobs. Using it to recruit takes less than a minute.

joblink.tw lets you post a description of a job without having to reveal the name of the company who is offering it, or the contact information of the hiring manager. Who wants that stuff posted on the internet? Instead, each joblink has a form that allows anyone who's interested to contact the poster. The actual exchange of information occurs in private, in email.

The same process works for job candidates. Know someone who'd make a great engineer at a startup? Just write a few words about them, set their email address as the private recipient, and tweet about it. They can turn off these contacts at any time.

To see a list of the jobs that I've posted on joblink.tw so far, take a look at my joblink profile. joblink.tw also supports oauth, so you can log in with your twitter credentials. If you do, you can have your joblinks broadcast on the joblinktw twitter account. For updates about joblink.tw or to see joblinks that others have posted, follow on twitter.

So far, this tool has saved me countless hours, and made quite a few interesting connections. That means it's accomplished all of my goals for it. If anyone else finds it useful, too, that will prove a huge plus. And if anyone has feedback, please feel free to use our integrated uservoice forum or just post a comment on this post. I'd be happy to make it better (regular readers will recognize joblink as a minimum viable product).

Techstars brings The Lean Startup to Boulder

I'm very excited to announce a pair of events that will kick off a very busy fall speaking tour. I'll be in Boulder for two days. I'll let David Cohen of Techstars, who organized the trip, describe the plan:

On August 19th, Eric will be speaking at a dinner in Boulder. The event will include a talk from Eric on The Lean Startup over dinner, followed by moderated table discussion and then final Q&A with Eric. Tickets are available now and include dinner. A discounted price is available for early stage entrepreneurs and students.

On August 20th, Eric is leading a half day in-depth workshop on the Lean Startup. This is a great chance to really go deep on some of the concepts behind building Lean Startups. A very limited number of tickets are also available for this workshop. Early bird pricing expires on August 6th, so register early.

Traveling to new startup hubs is one of my favorite things about being able to do this full-time. I want to thank Techstars for putting this event together and giving me a chance to experience the scene, even if it lacks a name. For what it's worth, I like Silicon Mountain.

Brad Feld also had some thoughts on this event on his blog. I thought I'd share a little bit of that, too:

I’ve been interested in different approaches to software development going back to 1987 when – in my first company Feld Technologies – my partner Dave Jilk and I started talking about “semi-custom software development” (way ahead of its time). During the same period (1987 – 1990) and I did some work at MIT under Eric von Hippel on “user driven innovation with regard to software development” which today would probably fall under the heading of “open source software development approaches.”

In 2002 I became exposed to the idea of “agile software development” and subsequently was a first round investor in Rally Software which is now the market leader in Agile application lifecycle management software. Building on this, I’ve recently become fascinated with the notion of continuous deployment, a concept that has been popularized by Eric Ries and others.

Read the rest...

And for those of you who are in Colorado but don't know what my speaking events are like, please take a look at some previous posts. We've got slides, video, audio and twitter commentary. That way, you can know what you're in for in advance.

As usual, if you're a reader and can attend, please come say hello. Thanks!

(Speaking of the fall tour, if you're interested in hosting or organizing a lean startup event near you, feel free to drop me a line. So far, I'm going to be on the east coast at least three times, and in Europe twice. Stay tuned for more details.)

Embrace technical debt

Financial debt plays an important and positive role in our economy under normal conditions. Yet, especially in times like these, it’s easy to rail against the badness of being in debt; it’s a very human feeling. Remember Hamlet?

LORD POLONIUS:
Neither a borrower nor a lender be;
For loan oft loses both itself and friend,
And borrowing dulls the edge of husbandry.

Technical debt works the same way, and has the same perils. Here’s one of my favorite introductions to the subject, courtesy of Martin Fowler:

In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The human tendency to moralize about debt affects engineers, too. Many conclude that technical debt is a bad thing, and that teams that incur technical debt are sloppy, irresponsible or stupid.

In this post, I want to challenge that idea, by talking about real-world situations where debt is highly valuable. I hope to show why lean and agile techniques actually reduce the negative impacts of technical debt and increase our ability to take advantage of its positive effects. As usual, this will require a little theory and a willingness to move beyond the false dichotomy of “all or nothing” thinking.

I won’t pretend that there aren’t teams that take on technical debt for bad reasons. Many legacy projects become completely swamped servicing the debt caused by past mistakes. But there is more to technical debt than just the interest payments that come due. Startups especially can benefit by using technical debt to experiment, invest in process, and increase their product development leverage.

In a startup, we should take full advantage of our options, even if they feel dirty or riddled with technical debt. Those moralizing feelings are not always reliable. In particular, try these three things:

Invest in technical debts that may never come due.
The biggest source of waste in new product development is building something that nobody wants. This is a sad outcome which we should work very hard to avoid. Yet there is one silver lining when it does happen: we wind up throwing out working code, debt-riddled and elegantly designed alike. This happened quite often in the early days of IMVU.

For example, I’ve talked often about our belief that an instant messaging add-on product would allow IMVU to take advantage of a network effects strategy. Unfortunately, customers hated that initial product. The thousands of lines of code that made that feature work were a mixed bag – some elegantly designed and under great test coverage, others a series of hacks. The failure of the feature had nothing to do with the quality of the code. As a result, many technical debts were summarily cancelled. Had we taken longer to get that feedback by insisting on writing cleaner code, the debt would have been much deeper.

Accept that good design sometimes leads to technical debt anyway.
Discussions of technical debt are usually framed this way (again from Martin Fowler):

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.

This framing takes for granted that the quick and dirty approach will incur significantly more technical debt than the slow and clean approach. Yet other agile principles suggest the opposite, as in YAGNI and DoTheSimplestThingThatCouldPossiblyWork. Reconciling these principles requires a little humility.

Most of us think we know a good design when we see it. Unfortunately, no matter how much up-front analysis we do, until the design is tested by actual practice, we can't really know. Outside the world of hypothetical examples, it's more important to make continual progress than to build the ultimate design.

For example, at a previous virtual world company, we spent years developing an architecture to cope with millions of simultaneous users. Unfortunately, we made two critically flawed assumptions: that customers would primarily consume first-party assets that we shipped to them on CD and that they would tend to congregate in a relatively uniform way. Neither assumption proved remotely accurate. The design failure meant that there was constant thrashing as the servers struggled to provision capacity according to the “elegant” algorithm we’d designed.

As in many scalability decisions, we’d have been much better off investing in agility, so that we could change the architecture in response to actual customer demand, rather than trying to predict the future. That’s what Just-in-time Scalability is all about. Sometimes quick and dirty actually incurs less debt.

Leverage product development with open source and third parties.
Financial leverage refers to investing that is supplemented by borrowed money. Similarly, product development leverage refers to situations in which our own work is fortified by the work of outsiders. For example, early on at IMVU, we incorporated in tons of open source projects. This was a huge win (and we were delighted to give credit where it was due), because it allowed our initial products to get to market much faster. The downside was that we had to combine dozens of projects whose internal architectures, coding styles, and general quality varied widely. It took us a long time to pay off all the debt that incurred – but it was worth it.

In addition, third-party services and API’s enabled us to do more with less, but at a cost: taking on the technical debt of products and teams outside our direct control. We’re not accustomed to accounting for technical debt that occurs in code that we don’t write, but this is short sighted. It’s important to learn to see the whole system that makes our product work: human as well as machine, internal as well as external.

For example, IMVU’s early business model was made possible by Paypal’s easy self-serve and open access payment system. However, we’ve often had to put up with unreliable service, caused by their inflexible internal architecture. We had to live with their technical debts without being able to repay them. It was still a good trade.

Not all debts are created equal.
Interest rates vary, so we should be selective about taking on new debts. Given the choice between incurring technical debt in a particular end-user-visible feature and incurring the same level of debt in a core system, I’d much prefer the former. Here’s why:

• There’s a chance that I’ll never have to pay for that particular debt, because the feature may have no value for customers.
  
  
• It’s possible that the feature, even with debt, might be good enough, and therefore not need revision for a long time. Technical debt manifests as rigidity or inflexibility. When modifying a part of the product afflicted by debt, the work requires a lot of extra – and unpredictable – clean up. But if a given feature is rarely modified, its debt is much less expensive.

The opposite is true with debt in a core system; it’s much more likely that this debt will slow down our ability to make changes later on. For example, an unreliable library deep in the core will manifest as intermittent defects all throughout the product, each of which is hard to localize and debug. Side-effects that reduce agility are the most damaging symptoms of technical debt.

Lean vs. debt
In the world of physical goods, the leaner a supply chain is, the less debt is required to operate it. This makes lean supply chains more robust in the face of the unexpected: if sales suddenly dry up, they are stuck with less unsold inventory and simultaneously have less debt to service. The just-in-time nature of the value chain reduces risk in the face of uncertainty and is also more capital efficient.

A similar relationship applies to technical debt. Teams that practice an agile or lean development process are able to minimize the accumulation of technical debt without sacrificing speed, because they work in smaller batches. They also take better advantage of debt, because they find out sooner if a particular investment has paid off. Traditional development teams, by contrast, often build and deploy large systems before learning if their early choices were sensible, and therefore wind up with a much larger debt to pay. In fact, by the time they become aware of it, they’ve already started to pay significant interest on that debt.

Invest in speed instead of features or debt
This relationship between lean and debt opens up new approaches for dealing with technical debt. The usual debate is phrased as an either-or choice between taking more time to “build it right” or taking a shortcut and incurring more debt. But those are not our only two options. Taking on technical debt does allow investing energy elsewhere, but other new features are not the only option.

We can trade technical debt for process improvement, too. If that improvement pays off (by reducing the batch size of our work, for example), it becomes easier to address all technical debt in the future – including the debt just incurred. And because any particular debt might never come due, this is a better trade. To take one concrete example, it’s often worthwhile to write test coverage for legacy code even without taking the time to refactor.

This reverses the standard intuition about what engineering activities add value, which usually concludes that test coverage is a form of necessary waste but a refactoring is value-added work. However, a refactoring (by itself) might go stale or introduce unintended side-effects. Adding test coverage will make it easier to refactor in the future and also reduce our fear of making changes elsewhere.

Investing in the dynamics of development is more valuable than investing in the static status quo. Startups are always moving, so invest in moving faster and better.

Technical debt in the real world
So far, all of these considerations have been framed in the form of abstract either-or tradeoffs. Real life seldom presents such comparable choices. Instead, we balance lots of unknowns. How much technical debt will a particular approach incur? How likely will customers ultimately use that feature? How painful will it be to refactor later? How much will it slow us down in the meantime? And how much more expensive would it be to do it right? Oh, and how likely is it that the “right” approach actually is?

Luckily, there are better options for these complex decisions than picking an easy extreme, like “never incur technical debt” or “anything goes.” Instead, we can choose a disciplined approach to making proportional investments in prevention and paying down debt, such as Five Whys. They work by focusing our energy on making process and technical changes in precisely those areas that are causing the biggest waste and slowdown.

This is better than making abstract choices about where to invest: better design, paying down old debts, or better process. Instead, techniques like Five Whys teach us to view the entire application and product development team as one integrated system. From this holistic viewpoint, we can optimize accordingly.

Once we can see opportunities for truly global efficiency gains, all that remains is to ensure our team actually makes room for those investments. To do that, we add specific speed regulators, like integrating source control with our continuous integration server or the more elaborate dance required for continuous deployment. This produces a powerful combination: the speed of just-in-time experimentation wedded to a discipline of rigorous waste-reduction.

One last thought. When I talk and write about the advanced product development process at IMVU today, like the cluster immune system or the disciplined approach we take to split-testing and interaction design, it may sound as if we had that capability from the start. Nothing could be further from the truth. The early IMVU was riddled with legacy code and technical debt. We spent endless hours arguing about whether we’d made the right choices in the past. And with the benefit of hindsight, it’s clear that we often made serious mistakes. As one engineer recently told me, “Once we had money in the bank and were near-profitable, I think we would have been well-served by increased up-front product and technology planning. As a culture, we hadn’t yet learned how to make long-term decisions.” He’s right.

In the end, what mattered wasn’t that we did everything right, but that our fundamental approach was flexible and resilient. At no point did we stop everything and do a ground-up rewrite. Instead, we incrementally improved our process, architecture, and infrastructure, always learning and adjusting. The blur you see today is the result of the beneficial compounding interest of that approach applied with discipline over many years. Trust me, it’s a lot of fun.

(This post was tremendously enhanced by a number of early readers from the Twitterverse. You know who you are. Thanks so much.)