Lessons Learned

A real Customer Advisory Board

2009-10-26T08:29:00.000-07:00

A reader recently asked on a previous post about the technique of having customers periodically produce a “state of the company” progress report. I consider this an advanced technique, and it is emphatically not for everyone.

Many companies seek to involve customers directly in the creation of their products. This is a lot harder than it sounds. Hearing occasional input is one thing, but building an institutional commitment to acting on this feedback is hard. For one, there are all the usual objections to customer feedback: it is skewed in favor of the loud people, customers don’t know what they want, and it is fundamentally our job to figure out what to build. All of those objections are valid, but that can’t be the end of the story. Just because we don’t blindly obey what our customers say doesn’t absolve us of the responsibility of hearing them out.

The key to successful integration of customer feedback is to make each kind of collection part of the regular company discipline of building and releasing products. In previous posts, I’ve mentioned quite a few of these, including these most important ones:

having engineers post on the forums in their own name when they make a change
routinely split-testing new changes
routinely conducting in-person usability tests and interviews
Net Promoter Score

Each of these techniques is fundamentally bottoms-up. They assume that each person on the team is genuinely interested in testing their work and ideas against the reality of what customers want. Anyone who has worked in a real-world product development team can tell you how utopian that sounds. In real life, teams are under tremendous time pressure, they are trying to balance the needs of many stakeholders, and they are human. They make mistakes. And when they do, they are prone to all the normal human failings when it comes to bad news: the desire to cover it up, rationalize the failure away, or redefine success.

To counteract those tendencies, it helps to supplement with top-down process as well. One example is having a real Customer Advisory Board. Here’s what it looks like. In a previous company, we put together a group of passionate early adopters. They had their own private forum, and a company founder (aka me) personally ran the group in its early days. Every two months, the company would have a big end-of-milestone meeting, with our Board of Directors, Business Advisory Board, and all employees present. At this meeting, we’d present a big package of our progress over the course of the cycle. And at each meeting, we’d also include an unedited, uncensored report direct from the Customer Advisory Board.

I wish I could say that these reports were always positive. In fact, we often got a failing grade. And, as you can see in my previous post on “The cardinal sin of community management” the feedback could be all over the map. But we had some super-active customers who would act as editors, collecting feedback from all over the community and synthesizing it into a report of the top issues. It was a labor of love, and it meant we always had a real voice of the customer right there in the meeting with us. It was absolutely worth it.

Passionate online communities are real societies. What we call “community management” is actually governance. It is our obligation to govern well, but – as history has repeatedly shown – this is incredibly hard. The decisions that a company makes with regard to its community are absolute. We aspire to be benevolent dictators. And unlike in many real-world societies, our decisions are not rendered as law but as code. (For more on this idea, see Lawrence Lessig’s excellent Code is Law.) The people who create that code are notoriously bad communicators, even when they are allowed to communicate directly to their customers.

A customer advisory board that has the ear of the company’s directors acts as a kind of appeals process for company decisions. As I mentioned in “The cardinal sin of community management,” many early adopters will accept difficult decisions as long as they feel listened to. As a policy matter, this is easy to say and very hard to implement. That’s why the CAB is so valuable. They provide a forum for dissenting voices to be heard. The members of the CAB have a stake in providing constructive feedback, since they will tend to be ignored if they pass on vitriol. In turn, they become company-sanctioned listeners. By leveraging them, the company is able to make many more customers feel heard.

The CAB report acts as a BS detector for top management. It’s a lot harder to claim everything is going smoothly, and that customers are dying for Random New Feature X when the report clearly articulates another point of view. Sometimes the right thing to do is to ignore the report. After all, listening to customers is not intrinsically good. As always, the key is to synthesize the customer feedback with the company’s unique vision. But that’s often used as an excuse to ignore customers outright. I know I was guilty of this many times. It’s all-too-easy to convince yourself that customers will want whatever your latest brainstorm is. And it’s so much more pleasant to just go build it, foist it on the community, and cross your fingers. It sure beats confronting reality, right?

Let me give one small example. Early in IMVU’s life, IM was a core part of the experience. Yet we were very worried about having to re-implement every last feature that modern IM clients had developed: away messages, file transfer, voice and video, etc. As a result, we tried many different stratagems to avoid giving the impression that we were a fully-featured IM system, going so far as to build our initial product as an add-on to existing IM programs. (You can read how well that went in another post here.)

This strategy was simply not working. Customers kept demanding that we add this or that IM feature, and we were routinely refusing. Eventually, the CAB decided to weigh in on the matter in their board-level report. I remember it so clearly, because their requests were actually very simple. They asked us to implement five – and only five – key IM features. For weeks we debated whether to do what they asked. We were afraid that this was just the tip of the iceberg, and that once we “gave in” to these five demands there would be five more, ad infinitum. It actually took courage to do what they wanted – as it does for all visionaries. Every time you listen to customers, you fear diluting your vision. That’s natural. But you have to push through the fear, at least on occasion, to make sure you’re not crazy.

In this particular example, it turned out they were right. Just those few IM features made the product dramatically better. And, most importantly, that was the end of IM feature creep. Nobody even mentioned it as an issue in subsequent board meetings. That felt good – but it also gave our Board tremendous confidence that we could change the kind of feedback we were getting by improving the product.

This technique is not for everybody. It gets much harder as the company – and the community – scales, and, in fact, IMVU uses a different system of gathering community feedback today. But, if your community is giving you a headache, give this a try. Either way, I hope you’ll share your experiences, too.

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

2009-10-23T05:27:00.000-07:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Myth: Entrepreneurship Will Make You Rich

2009-10-19T10:27:00.000-07:00

I have a new guest post on GigaOm today, called Myth: Entrepreneurship Will Make You Rich. Here's an excerpt:

One of the unfortunate side effects of all the publicity and hype surrounding startups is the idea that entrepreneurship is a guaranteed path to fame and riches. It isn’t. Building a startup is incredibly hard, stressful, chaotic and –- more often than not –- results in failure. That doesn’t mean it’s not a worthwhile thing to do, just that it’s not a good way to make money.

A more rational career path for money-making is one that rewards effort, in the form of promotions, increased security, salary and status. Startups, unfortunately, punish effort that doesn’t yield results. In fact, the biggest source of waste in a startup is building something nobody wants. While in an academic R&D lab, creation for creation’s sake will often get you praise, in a startup, it will often put you out of business.

So why become an entrepreneur instead of developing technology in an R&D lab? Three reasons: change the world, make customers’ lives better and create an organization of lasting value. If you only want to do one of these things, there are better options. But only startups combine all three.

Take this fictional example of a Seedcamp attendee (actually a composite), which I will refer to as Hairbrush 2.0...

Read the rest of Myth: Entrepreneurship Will Make You Rich

Also take a look at the great Hacker News discussion of this essay. It includes several gems, including this comment from davidu:

1) Being an entrepreneur, for me, isn't about being wealthy, it's about being successful.
2) Rich is a variable term, and intended to be so.
Entrepreneurship may not make you wealthy, but it can certainly make you rich.
I enjoy the freedom and independence afforded by starting EveryDNS and OpenDNS. Both contain a passion for a system I love, the DNS, and both have let me help millions of consumers around the world. I even like knowing I control the DNS for millions and millions of Internet users. That's an awesome responsibility and it certainly makes me feel rich about everything I do.
And when it comes to money, Eric is only somewhat right. He says you should get a job that rewards and promotes effort. But lots of lawyers and finance kids in New York thought they had stable jobs that would make them rich. Ask them today and most will tell you a different story altogether. Now they hate their jobs and have no job security or path to becoming really wealthy.
So like I said, being entrepreneur, for me, isn't about being wealthy, it's about being successful. That's a measuring stick that's far more important.

and this one from gits_tokyo:

People that I've spoken with in the past more often than not associated the idea of me doing a startup in the tech industry with gaining massive wealth. While I may entertain this, deep down I find it lacking as there's so much more than wealth to be had.
How about, living in a world... some distant future from the everyday-everyday where day-by-day you toil piecing together a vision, one day injecting it into the present, in order to influence a whole new set of social behaviors while also unfolding valuable opportunities. How about, the day of flipping that proverbial switch, releasing this vision out in the wild. How about, the potential of millions interacting with your vision, it becoming a staple part of a users online experiences. There's something undeniably provoking about all this, rush of my life.
Wealth, although a welcomed aside pales in comparison. Hell I would even go so far as to say, in a world where sex is constantly peddled as a cure all, let me say it, sex pales in comparison to the feeling I get from being an entrepreneur.

Inc Magazine on Minimum Viable Product (and a response)

2009-10-19T05:35:00.000-07:00

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

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

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

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

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

Read the rest...

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

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

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

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

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

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

Innovation inside the box

2009-10-11T22:57:00.000-07:00

I was recently privy to a product prioritization meeting in a relatively large company. It was fascinating. The team spent an hour trying to decide on a new pricing strategy for their main product line. One of the divisions, responsible for the company’s large accounts, was requesting data about a recent experiment that had been conducted by another division. They were upset because this other team had changed the prices for small accounts to make the product more affordable. The larger-account division wanted to move the pricing in just the other direction – making the low-end products more expensive, so their large customers would have an increased incentive to upgrade.

Almost the entire meeting was taken up with interpreting data. The problem was that nobody could quite agree what the data meant. Many custom reports had been created for this meeting, and the data warehouse team was in the meeting, too. The more they were asked to explain the details of each row on the spreadsheet, the more evident it became that nobody understood how those numbers had been derived.

Worse, nobody was quite sure exactly which customers had been exposed to the experiment. Different teams had been responsible for implementing different parts of it, and so different parts of the product had been updated at different times. The whole process had taken. And by now, the people who had originally conceived the experiment were in a separate division from the people who had executed it.

Listening in, I assumed this would be the end of the meeting. With no agreed-upon facts to help make the decision, I assumed nobody would have any basis for making the case for any particular action. Boy was I wrong. The meeting was just getting started. Each team simply took whatever interpretation of the data supported their position best, and started advocating. Other teams would chime in with alternate interpretation that supported their position, and so on. In the end, decisions were made – but not based on any actual data. Instead, the executive running the meeting was forced to make decisions based on the best arguments.

The funny thing to me was how much of the meeting had been spent debating the data, when in the end, the arguments that carried the day could have been made right at the start of the emeting. It was as if each advocate sensed that they were about to be ambushed; if another team had managed to bring clarity to the situation, that might have benefited them – so the rational response was to obfuscate as much as possible. What a waste.

Ironically, meetings like this had given data and experimentation a bad name inside this company. And who can blame them? The data warehousing team was producing classic waste – reports that nobody read (or understood). The project teams felt these experiments were a waste of time, since they involved building features halfway, which meant they were never quite any good. And since nobody could agree on each outcome, it seemed like “running an experiment” was just code for postponing a hard decision. Worst of all, the executive team was getting chronic headaches. Their old product prioritization meetings may have been a battle of opinions, but at least they understood what was going on. Now they first had to go through a ritual that involved complex math, reached no definite outcome, and then proceeded to have a battle of opinions anyway!

When a company gets wedged like this, the solution is often surprisingly simple. In fact, I call this class of solutions “too simple to possibly work” because the people inside the situation can’t conceive that their complex problem could have a simple solution. When I’m asked to work with companies like this as a consultant, 99% of my job is to find a way to get the team to get started with a simple – but correct – solution.

Here was my prescription for this situation. I asked the team to consider creating what I call a sandbox for experimentation. The sandbox is an area of the product where the following rules are strictly enforced:

Any team can create a true split-test experiment that affects only the sandboxed parts of the product, however:
One team must see the whole experiment through end-to-end.
No experiment can run longer than a specified amount of time (usually a few weeks).
No experiment can affect more than a specified number of customers (usually expressed as a % of total).
Every experiment has to be evaluated based on a single standard report of 5-10 (no more) key metrics.
Any team that creates an experiment must monitor the metrics and customer reactions (support calls, forum threads, etc) while the experiment is in-progress, and abort if something catastrophic happens.

Putting a system like this in place is relatively easy; especially for any kind of online service. I advocate starting small; usually, the parts of the product that start inside the sandbox are low-effort, high-impact aspects like pricing, initial landing pages, or registration flows. These may not sound very exciting, but because they control the product’s positioning for new customers, they often allow minor changes to have a big impact.

Over time, additional parts of the product can be added to the sandbox, until eventually it becomes routine for the company to conduct these rigorous split-tests for even very large new features. But that’s getting ahead of ourselves. The benefits of this approach are manifest immediately. Right from the beginning, the sandbox achieves three key goals simultaneously:

It forces teams to work cross-functionally. The first few changes, like a price change, may not require a lot of engineering effort. But they require coordination across departments – engineering, marketing, customers service. Teams that work this way are more productive, as long as productivity is measured by their ability to create customer value (and not just stay busy).
Everyone understands the results. True split-test experiments are easy to classify as successes or failures, because top-level metrics either move or they don’t. Either way, the team learns immediately whether their assumptions about how customers would behave were correct. By using the same metrics each time, the team builds literacy across the whole company about those key metrics.
It promotes rapid iteration. When people have a chance to see a project through end-to-end, and the work is done in small batches, and has a clear verdict delivered quickly, they benefit from the power of feedback. Each time they fail to move the numbers, they have a real opportunity for introspection. And, even more importantly, to act on their findings immediately. Thus, these teams tend to converge on optimal solutions rapidly, even if they start out with really bad ideas.

Putting it all together, let me illustrate with an example from another company. This team had been working for many months in a standard agile configuration: a disciplined engineering team taking direction from a product owner who would prioritize the features they should work on. The team was adept at responding to changes in direction from the product owner, and always delivered quality code.

But there was a problem. The team rarely received any feedback about whether the features they were building actually mattered to customers. Whatever learning took place was happening by the product owner; the rest of the team was just heads-down implementing features.

This led to a tremendous amount of waste, of the worst kind: building features nobody wants. We discovered this reality when the team started working inside a sandbox like the one I described above.

When new customers would try this product, they weren’t required to register at first. They could simply come to the website and start using it. Only after they started to have some success would the system prompt them to register – and after that, start to offer them premium features to pay with. It was a slick example of lazy registration and a freemium model. The underlying assumption was that making it seamless for customers to ease into the product was optimal. In order to support that assumption, the team had written a lot of very clever code to create this “tri-mode” experience (every part of the product had to treat guests, registered users and paying users somewhat differently).

One day, the team decided to put that assumption to the test. The experiment was easy to build (although hard to decide to do): simply remove the “guest” experience, and make everyone register right at the start. To their surprise, the metrics didn’t move at all. Customers who were given the guest experience were not any more likely to register, and they were actually less likely to pay. In other words, all that tri-mode code was complete waste.

By discovering this unpleasant fact, the team had an opportunity to learn. They discovered, as is true of many freemium and lazy registration systems, that easy is not always optimal. When registration is too easy, customers can get confused about what they are registering for. (This is similar to the problem that viral loop companies have with the engagement loop: by making it too easy to join, they actually give away the positioning that allows for longer-term engagement.) More importantly, the experience led to some soul-searching. Why was a team this smart, this disciplined, and this committed to waste-free product development creating so much waste?

That’s the power of the sandbox approach.

A large batch of videos, slides, and audio

2009-10-06T14:25:00.000-07:00

I've been trying very hard to avoid turning this blog into a travelogue. Normally, I try to make my post-event writeups more than just a transcript, by including reactions and comments. On this speaking tour, that's been simply impossible, so I've decided to let the following collection of videos, podcasts, and slides batch up for a little while. If you're interested in more real-time updates during my speaking tour, please tune into my twitter feed.

In the meantime, I hope you enjoy all this multimedia content. In addition to some of my recent talks, you can learn more about the Startup Visa movement and enjoy two really interesting lean startup case studies.

My Stanford Entrepreneurial Thought Leader Seminar courtesy of Stanford Ecorner (audio podcast only for now, video coming soon):

if you'd like to follow along with slides, they are here:

2009 09 29 The Lean Startup At Stanford Entrepreneurial Thought Leader Seminar

View more presentations from Eric Ries.

From high atop the BT Tower in London, this brief BT Tradespace interview:

Why do we need a Startup Visa? A Tale of 2 Erics:

Also in London, I took up a lot of airtime during day two of Seedcamp. You can read highlights on their blog, or watch this short video:

Seedcamp - Day 2 Highlights from Seedcamp on Vimeo.

Or watch my full #leanstartup presentation at Seedcamp in London:

And two bonus videos that are well worth watching (weally):

Timothy Fitz, who worked for me at IMVU, giving an in-depth presentation on the details of the continuous deployment system that we built there.

With accompanying slides:

Continuous Deployment

View more presentations from TimothyFitz.

pbWorks (formerly pbWiki) was one of the first companies that ever invited me to join their advisory board. I like to think that had some small part in causing their subsequent success. Judge for yourself by watching David Weekly's #leanstartup case study (pbWorks):

Thanks to everyone who has helped plan, organize, record and attend these many events!

The curse of prevention

2009-10-05T05:25:00.000-07:00

Beware! I have detected a secret virus in your CPU. Due to an interaction effect between your hardware, solar flares, and quantum flux, this virus will crash your computer and erase your hard drive sometime soon. There is only one way to prevent disaster: you must click the subscribe button over on the right there. Go ahead, I’ll wait.

Did you do it? Good. Now you’re safe from that dastardly virus. How do you know my solution worked? Just wait. See, no crashing. You should really say thank you.

Now, I know some of you didn’t believe my urgent virus warning, and therefore didn’t take my proposed solution. But you’re not safe. That virus is still out there, lurking. It could strike at any minute. And when your computer eventually crashes, you should feel bad that you didn’t listen to me.

OK, I admit it. There is no virus. I did my best to exaggerate this claim without saying anything disprovable, in order to illustrate the curse of prevention. Imagine for a moment that you believed my claim about the dangerous virus. After investing in my proposed solution, you probably would be grateful that I “prevented” the problem from happening. In an example this ludicrous, that hopefully sounds funny. But companies make this mistake repeatedly.

Let’s take a common real-world example. It’s important to invest in good architecture so that your website will scale once customers arrive. If you make that investment, and then customers arrive, and the site stays up, most companies will reward the people who built the architecture and, thus, prevented the scaling problems. That’s every bit as crazy as the bogus claim I made earlier. How do you know the problem was actually prevented? Isn’t it just as possible that it never would have occurred in the first place? Or, if it really was prevented, what was the opportunity cost of choosing to prevent it ahead of time?

In other words, there is a formula for evaluating the success of any proposed prevention:

cost of prevention < (probability of problem occurring) * (cost of problem)

THEN

do it

ELSE

ignore it

The killer thing about this formula is that every single term in it is unknown. And in most situations, there is significant cost involved in negotiating over the right estimates to plug in.

I have been present for these kinds of negotiations many times in my career. They are usually among the most heated arguments a company has. Like other situations that I’ve written about, they tend to devolve into competing all-or-nothing camps. One side insists that we should build things the right way, and that failure to anticipate problems is an abdication of responsibility. But the other side wants to get things done, and doing things right somehow, always, every time seems to involve postponing useful work. Both sides suspect that deep down, secretly, the other side is using their arguments over architecture (or planning, or roadmaps, or specifications) to advance a secret agenda. Ever notice how people’s pet projects seem to be exempt?

Why do they harbor that paranoia? It’s easy to see. Say you want to derail someone else’s project. Just start enumerating corner cases. Imagine everything that might go wrong, and insist that those things be prevented before the project is launched. It’s a win-win: you either dramatically increase the proposed cost of the project, making it easier to get cancelled, or you can rely on some “I-told-you-so’s” when the project does launch and encounters inevitable problems, which gives you credibility in future such arguments. On the other side, if you want a project to go forward, you can suddenly "discover" all kinds of extra efficiencies that make this particular project an especially good deal. In the past, we invested in brilliant architecture, code reuse, refactoring, modular design, etc. that now makes it a simple matter to add this feature without much risk of corner cases. Right.

Managing these situations is hard for any company, but potentially lethal for a startup. There are just so many ways for a startup to fail. I’ve lived through the over-architecture failure – where attempting to prevent all kinds of problems wound up delaying the company from putting out any product at all. And I’ve seen companies fail the other way – the so-called Friendster effect: having a high-profile technical failure just when customer adoption is going wild.

Most of the advice I’ve heard on this topic has been a kind of split-the-difference approach. The theory is that there is some truth in both camps, and the right way to manage the disagreement is to sprinkle a little bit of both into our plans. A little planning, but not too much. Prevent some corner cases, but not others. The problem with this advice, as I’ve experienced it, is that it’s pretty hard to give a rationale for why we should anticipate this problem but ignore another one. To the people being managed that way, it feels like the boss is being capricious or arbitrary. And that feeds the conspiracy feeling that decisions have an ulterior motive.

So I’d like to lay out a systematic way to avoid death-by-corner-case without sacrificing the company’s ability to grow. In other words, a principled way to combine agility with stability.

The first shift required is a change in orientation from prevention to fast response. Many problems are catastrophic only if allowed to fester. Imagine you hear from an engineer that they are worried that a certain payment subsystem is unreliable, and will therefore double-charge some customers. One way to evaluate this fear is to spend time on analysis: how many customers will be affected? What is the maximum amount of overcharging that will happen? How upset will those customers be? How much will it cost to solve this problem now? In this framework, we’ll tend to either invest in the proposed prevention or do nothing.

But there is another way. Imagine we asked the following question: if this problem does materialize in the future, how will we know? In a lot of systems, it might take days or weeks to uncover a problem-in-action. Maybe we already have a mechanism for customers to report this kind of problem, or maybe we could invest in a simple alert counter that increments whenever the problem happens, and sends a notification if it happens often. Then, we’d know immediately if the problem ever manifests, and get a simultaneous report on its severity.

We can also ask: how would we fix the problem if it does occur? If we’re practicing continuous deployment, we can be confident that we’ll be able to rush an emergency fix into production without risking introducing further problems. If not, maybe an investment in that direction would be more warranted. In other words, you can always invest in process, batch size reduction, and agility as an alternative to preventing a specific problem.

There are two principal reasons why this second approach is better. The first is that it allows us to make variable-sized investments in response to a feared corner case. Instead of “do the fix” or “hack it up” we can choose increments of investment anywhere in-between. That gives teams a lot more flexibility in the face of the numerous corner cases that come up. Second, investing in fast response is a more resilient strategy. If we’re wrong about the corner case, the investments we’ve made in fast response will allow us to respond faster to whatever problems do appear. By contrast, most investments in traditional prevention are designed to anticipate and fix a specific problem.

But investing in fast response doesn’t solve the whole problem. That’s because there’s still a lot of judgment involved in choosing the right level of investment to make in any given case. It can feel incongruous to people who are used to the traditional model because it has a built in paradox: you will encounter a lot of cases where you know a problem exists, and you know how to solve that problem, and you are investing time related to that problem but are not investing in the solution. To a lot of smart engineers, that sounds crazy.

That’s why it’s essential to pair the fast response aspect of this approach with a disciplined commitment to root cause analysis. Regular readers of this blog will know the specific methodology I recommend, called Five Whys. But regardless of the technique you use, it’s essential that you get regular feedback about how your prevention decisions are turning out in practice. When you’re heavily investing in prevention, you need to evaluate whether that’s causing your team to go faster. If it’s not, then you’re investing too much in one-off solutions and not enough in process. And if you’re having a lot of problems, you need to have a mechanism for ramping up your investment in prevention to avoid having your whole team dragged down into firefighting. Systems like Five Whys create a natural feedback loop: when you're going too fast, causing a lot of new problems, it slows you down to invest in prevention. As those preventative efforts pay off, the team naturally speeds up.

The most dangerous situation you can find yourself in is investing in prevention and also firefighting all the time. That’s why there is a third essential component to this approach. You need to have a long-term vision of where you’re headed. That’s because not all investments are created equal. In most real-world situations, any particular problem (or proposed problem) will have multiple kinds of solutions that you could invest in. Take your typical scalability bottleneck. It could be fixed by refactoring the code itself, or by partitioning the data horizontally or vertically, or by adding additional capacity at the point of the bottleneck, or by shaping end-user demand, or even by removing the feature itself. At any given point in time, which is the right solution? Here’s my belief: the right solution is always the one that moves you closest to your vision while simultaneously solving the problem. Thus it is unacceptable to choose a solution that solves the problem but makes not progress towards the end-state, just as it is unacceptable to invest in a solution that builds a beautiful vision but doesn’t solve today’s problem. Finding such a solution is sometimes challenging, but that’s the moment when it really pays to spend some time thinking through alternative approaches. In my experience, where there is a will to find a synthesis solution, there is always a way.

Entrepreneurial Thought Leaders (and a request for help)

2009-09-28T08:20:00.000-07:00

There are only two opportunities left this year to see a Lean Startup presentation in the US - for free. In order to make those events the best they can be, I'd like to ask for your help.

This Wednesday, I've been invited to give a lecture as part of Stanford University's Entrepreneurial Thought Leaders Seminar. I'm really honored to be included in this program, as it's one I've admired and enjoyed for many years. They produce fantastic video podcasts, which you can explore here. And in mid-November, I'll be speaking at the Web 2.0 Expo in NYC. Once again, this will be a web2open hybrid session; I'll post details for how to register as soon as I get them.

I'd like to incorporate feedback into these presentations, and so here's my request for help. If you've seen me present in any format (online or in-person), would you take a few minutes to fill out the following short survey?

Click Here to take survey

If you haven't seen any of my presentations before, feel free to take a moment and peruse the video, audio, or slides available on this blog. As always, if you can come to one of these events, please come say hello and let me know that you're a reader. Hope to see you there!

Support the Startup Founders Visa with a tweet

2009-09-19T06:27:00.000-07:00

It's been an exhilarating first day here in Washington DC for the Geeks on a Plane tour. We met a number of policy makers from the White House and State Department, and had a solid Startup2Startup all about government policy and entrepreneurship. After a full day of talking, debating, thinking, and strategizing, we feel about read to take some good old-fashioned action. Will you join us?

In a previous post, I asked readers for suggested topics that the US government needs to know about startups and entrepreneurs, and got some really interesting responses. I've done my best to represent those perspectives in the meetings I've had here over the past two weeks. In my presentation this morning, I emphasized three key areas: reducing the personal cost of failure for entrepreneurs, innovation-friendly legal reforms, and access to the digital means of production (slides from my White House presentation are available at the end of this post).

However, there's one additional issue that has come up throughout the day today. We have a serious structural barrier to entrepreneurship: a glitch in US immigration policy. We can remedy it by creating a special visa for startup founders. The idea is to enable up to 10,000 people per year to enter the United States if they are here to found a company that will employ US citizens. I think the benefits are a no-brainer. Let me quote from Paul Graham's original essay:

The biggest constraint on the number of new startups that get created in the US is not tax policy or employment law or even Sarbanes-Oxley. It's that we won't let the people who want to start them into the country.

Letting just 10,000 startup founders into the country each year could have a visible effect on the economy. If we assume 4 people per startup, which is probably an overestimate, that's 2500 new companies. Each year. They wouldn't all grow as big as Google, but out of 2500 some would come close.

By definition these 10,000 founders wouldn't be taking jobs from Americans: it could be part of the terms of the visa that they couldn't work for existing companies, only new ones they'd founded. In fact they'd cause there to be more jobs for Americans, because the companies they started would hire more employees as they grew.

Brad Feld is working on promoting this idea inside the halls of Congress. Today at Startup2Startup, some additional pieces fell into place. First of all, Dave McClure introduced the idea of modifying an existing immigration program. The EB-5 visa is designed for foreign investors to get a green card if they are willing to bring capital to the US and create at least ten full-time jobs. Unfortunately, this program applies to the investor who holds the capital, and not the entrepreneur who discovers how to put that capital to use. A small change in the law could have a big impact on entrepreneurship in this country, and that's what he proposed. When Dave presented this to the White House and State Department audience, he got a favorable reaction. That's when the second piece clicked, a few hours later. At Startup2Startup, we decided to generate some grassroots momentum to help out. It's actually part of a lean startup story.

David Binetti is an entrepreneur with some credibility in this area, having worked to create the original USA.gov. Recently, he's been engaged in a customer validation exercise around a new concept for a political action-oriented social network. When that concept didn't pan out, he decided to pivot. His latest effort, called 2gov.org, makes it easy to contact your local, state and federal governments with just a tweet. For more on his lean startup journey, you can take a look at this slide presentation. 2gov.org automatically routes your tweet (aggregating it with everyone else who's expressed a similar point of view) to the right legislator or agency. Because it checks your registration against voting rolls, members of congress know that the contacts being received are from actual voters, not just astro-turf. In other words, the service transforms tweets into professional reports that are sent by snail mail, fax, and email - the channels that actually have attention paid to them.

He was at today's event, and the Geeks on a Plane had a brainstorm. Let's use 2gov.org to raise awareness of the Startup Founders Visa movement in congress. To that end, we're tweeting about it, and would like to ask you to join us. If you are a US citizen, tweet your thoughts on the Startup Founders Visa, using the #StartupVisa hashtag and including @2gov. 2gov.org will take care of the rest. In order to have your tweet included in the printed packet that your representative will receive, you'll need to register at 2gov.org (it really only takes a minute).

The Geeks are doing their part. Will you lend us a hand (or at least a tweet)?

2009 09 18 The Lean Startup Geeks On A Plane Edition

View more presentations from Eric Ries.

Testing the new Disqus comment system

2009-09-15T16:55:00.001-07:00

The recent and overwhelming influx of comments on The cardinal sin of community management. Has prompted me to investigate upgrading the comments system on this blog. I reached out to the twitter to gather suggestions, and the clear first choice seems to be Disqus. So I've attempted to install Disqus such that this post should be the very first one it's enabled for. Want to come give it a try? Just drop a comment on this post.

Your help testing is much appreciated! I especially would like your feedback. Should I keep Disqus? Go to another comment system? Or go back to the way it was?

Thanks!

Gov 2.0 Summit wrap-up

2009-09-15T06:39:00.000-07:00

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

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

2009 09 08 The Lean Startup Gov 2.0 Summit Edition

View more presentations from Eric Ries.

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

STARTUP = EXPERIMENT

FASTER STARTUPS = MORE EXPERIMENTS PER DOLLAR

I tried to make clear my usual definition of a startup, one that has nothing to do with size of company or sector of the economy. But judging from the twitter comments, it's not clear if I was able to make that case. It may be that it will prove a lot harder to make this point in DC than elsewhere:

aptuscollab: Too bad all you #g2s folks got up and left when Eric Ries took the stage. Dude is smart, his lessons apply to internal projects as well.

That's the nice thing about Twitter. You get the straight scoop, no sugar-coating. Any public speaker that doesn't take advantage of it is really missing out.

On to what seems to have stuck:

kwooleyy: #g2s Showed startup OODA loop developed by USAF pilot John Boyd

I included two Boyd-inspired books in the recommended reading list on the right-hand side of this blog: Certain to Wi n and Boyd: The Fighter Pilot Who Changed the Art of War. With a number of military men and women in the audience, I couldn't resist a plug. Boyd's ideas have inspired a lot of the principles underlying my work.

whorunsgov: Eric Ries: Startups fail not because the technology works, but because no one wants the tech. once it launches. #g2s

The very abbreviated version of Customer Development (channeling Steve Blank).

nickvitalari: Lean startups mean more experiments for dollars and human capital invested #ngenera #g2s

I'm trying to keep hitting on the theme of the human capital waste when we invest our smartest and most creative people into a venture that builds something that nobody wants. Every bit as true for government as for enterprise - and even the two guys in a garage.

dhinchcliffe: Lean startups go faster. Do course correction called a "pivot". - @ericries "Most exciting time in history be an entrepreneur." #g2s

For more on the pivot, see Pivot, don't jump to a new vision. I don't see how it could more a more exiting time to be an entrepreneur, and certainly can't imagine another time when entrepreneurship was more important to our country's future economic prosperity.

marciamarcia: The L word (learning) onstage at #g2s from @ericries. Finally. Startup=Experiment. http://startuplessonslearned.com

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

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

International tour about to begin

2009-09-14T18:17:00.000-07:00

For my international readers: are you in Washington DC, Paris, Barcelona, London, Amsterdam, Malmo, or even Oulu, Finland? Then you'll have a chance to come discuss the lean startup live and in-person. (What's that you say? DC is actually not a separate country? Fascinating...)

The trip will happen in two separate trips. The first (DC, London for Seedcamp, Amsterdam for PICNIC) is first, with the Geeks on a Plane tour, September 18-25. Each event will feature a cool mix of Bay Area and local speakers (and me, too). Come join us if you can.

I then head back to the USA for a free and open-to-the-public lecture at Stanford University for their Entrepreneurial Thought Leaders Seminar on September 30.

Next up is a second swing through Europe. Exact dates for all events aren't yet pinned down, but here's what I'm working on so far: October 28 for a TBA event in Paris, November 2-7 for a series of events in Malmo, Sweden including Øredev, and ending with a workshop at the Martti Ahtisaari Institute of Global Business and Economics at the University of Oulu.

I'll keep you all posted as more details get added. As always, if you're a reader and can make it to one of these events, please come say hello. Continually love hearing your feedback!

The cardinal sin of community management

2009-09-11T04:27:00.000-07:00

Once you have a product launched, you will the face the joys – and the despair – of a community that grows up around it. I won’t sugar-coat this: it is one of the most difficult and frustrating aspects of building a company online.

There are many articles by many experts (myself included) extolling the virtues of listening to customers. In fact, there are so many of these propaganda pieces that this question might naturally cross your mind: if listening to customers is so great, why do we need so much propaganda? I’ll tell you the honest truth: listening to customers is gruesome, uncomfortable, and painful work. Sure it has its moments, but then so does getting stranded on a desert island.

Yet few products these days can succeed without their online community, and the insight you can gain from interacting with that community is unparalleled, despite the pain. But to take advantage of that learning, you have to avoid the absolutely one and only cardinal sin of community management: not listening.

This probably sounds illogical. Communities care about lots of things, like how good your product is, how much information you give them, how you defend them from trolls, right? And when you’re being pilloried by community members over the latest mistake your company made, it can doubly confusing. After all, people rarely say they are mad because they are not being heard. But just because they don’t say it doesn’t mean that it’s not true.

Let me give an especially painful example. At a certain point in IMVU’s development, we faced a difficult choice. Some of our most passionate early adopters were using IMVU’s user-generated content capabilities to create illicit content. As you can imagine, this was a lucrative customer segment. But it became clear that if IMVU was ever going to become a mainstream business, we had to effectively fire these early customers. The reasons were many and complex, so I won’t rehash them all here. Suffice to say that our partners, vendors, and most importantly regular mainstream customers all found the idea disturbing. So we had to start enforcing new content policies that restricted what kinds of virtual goods could be bought and sold on IMVU.

We did not take this step lightly. We did a lot of analysis to make sure that we were minimizing the number of customers affected. For example, we spent some time researching the usage of virtual goods that would be disallowed under the new policy and were relieved to discover that they accounted for less than 0.1% of all usage. So we felt confident that removing them wouldn’t have too big an impact. We couldn’t have been more wrong.

This single decision wound up costing the company significant revenue and over the course of several months sent its customer growth into decline. We were totally unprepared for the magnitude of what happened. In the end, we managed to repair the damage, but only after losing a lot of time and at significant opportunity cost. This was one of those catastrophes that shouldn’t have happened. We carefully rolled out the change in stages. We did our best to actively communicate why we were making the change, and we tried to put in place policies that treated affected customers fairly.

Yet none of that mattered, because we violated the cardinal rule. We didn’t listen. More accurately, we made our customers feel like we weren’t listening. And until we could make that right, we kept on hemorrhaging business.

The problem was that although very few customers were affected by the changes in policy, many more were anxious about those changes. We tried to be low-key about the roll-out of these changes, so as not to call attention to it, but our silence on the subject simply served to make room for conspiracy theories about what was really going on. And, because the people complaining were yelling and screaming, we thought the right response was to ignore them and wait for them to leave. After all, someone who is writing ten-page posts about how they are going to abandon your product is presumably going to go away, right? That’s why one of the most important maxims in online communities is “don’t feed the trolls.” People who thrive on creating controversy through volume, repetition and hyperbole don’t really want to be heard. They just want attention, and giving it to them just encourages more reckless behavior.

But silence was the worst possible strategy. For months, we made constant product and policy changes, trying to end the controversy without simply undoing our original decision and abandoning the mainstream market. Nothing worked, until we finally had one of our community managers start talking to real customers on the phone. Then the reality of our problem hit us.

Most normal customers – even among early adopters - do not pay attention to the trolls. They don’t participate heavily in the forums, and they don’t send email when they are dissatisfied. They are largely invisible in the normal channels where customer service and community management pays attention. But that doesn’t mean they are not aware of what’s going on, or that they don’t care deeply about it. It turned out that our customers had gotten a clear message, one that we had never intended to send: that IMVU was becoming a teen-only site. We were totally shocked. Adults, even those that aren’t at all interested in racy content, were our best customers. We had built numerous features specifically for them, and often had to contend with charges from teenagers that we were too adult-friendly (these two segments don’t really like hanging out with each other as a rule).

When we actually started listening, things changed fast. First of all, we discovered what was really upsetting our customers. They had come to rely on the fact that IMVU was one of the very few online communications platforms where verified adults could meet one another. This was an unintended side-effect of our earlier content policies, that required age verification before you could buy unrated content from our catalog. It turns out many of our best customers were becoming age verified and then not buying any “adult” content. They enjoyed being treated like adults and having a way to chat online with other adults. Again, this was not about prurient content. Avatars make it possible to meet other people as they would like to be perceived. Mostly, that’s a good thing – many people believe their avatar is a more authentic representation of their true self than their physical appearance. But it also has some drawbacks. In the middle of a serious conversation on the joys of motherhood or the stress of a career you might realize that the person you’re talking to is only 15. That can be a jarring juxtaposition of physical reality that breaks the suspension of disbelief.

It took me a long time to understand that benefit of our product. Most customers couldn’t articulate it; they just knew they were angry that we had ruined it. Except that, from a literal point of view, we hadn’t ruined it. All of the features that enabled that experience were still there. What we had done to ruin it was make our customers feel like they were not welcome anymore. We kept denying that we had done anything wrong, that the features still worked as advertised, and justifying our decisions instead of apologizing. When we finally understood the problem, fixing it was relatively easy. We made a series of very public declarations that IMVU would always support adults, that we appreciated their unique contribution, and that we would always protect the key features that meant the most to them. The fact that pornography was not one of these key features was besides the point. We had summarily turned off one of their features without consulting them and without remorse. Who knew what feature might be next?

So real listening can head off a crisis in progress. But it also has other powers. For example, consider a common case of a minimum viable product. Since this product is necessarily missing a lot of features, those of us who ship them often want to duck the feedback. After all, it’s likely to be something we already know. In fact, I used to have the urge to argue with customers who gave feedback like “hey, idiot, you’re missing feature X.” I used to respond with something like, “I know, but it’s on our road map and we’re already working on it and we don’t really want feedback about that right now and so please get off my back.” You can imagine the field day the trolls had with that.

Eventually, we learned a better way. Feedback that tells you something you already know is still quite valuable. It gives you a hint that you are on the right track, but it also tells you quite a lot about the person giving you the feedback – that they believe in the path that you are on. For an early adopter, having this insight acknowledged and validated is a powerful experience. So we learned to take the time to say “thank you for your suggestion. Thanks to you, we’re going to prioritize feature X.” Then, when feature X finally did come out, every early adopter who suggested it feels an earned sense of ownership over it. Here’s the best part. They will also defend you against future attackers and trolls.

Collectively, an online community has an unlimited amount of time to spend. Even if you and your community managers are a hundred times smarter and more productive than the members of your community, there is absolutely no way that you can keep up with its sheer volume of energy. So you can’t fight an online community and hope to win the argument. The only way to have your point of view prevail is to have members of the community invest their unlimited time and energy in evangelizing it. And that’s what really, truly, actively listening does. It sends a signal to passionate customers that you care, that you want them on your side, and that they are part owners of your vision. In fact, I am convinced that if you could find some of IMVU’s earliest adopters, they would say something like this: “sure, those guys at IMVU HQ were helpful in writing code and stuff, but in the end they were just the hired help. It was really the community who built that product.” Imagine what happens when a troll shows up and starts bad-mouthing you. Those earlyvangelists (to borrow Steve Blank’s phrase) will defend you.

I have seen this dynamic time and again. As a creator of products (and now an author, too), it’s one of the things that keeps me going. When your customers become your allies, there’s almost nothing you can’t accomplish together.

There’s only one catch. You can’t stop listening. If you do, as IMVU found out to our peril, you break the implicit bargain that made you allies in the first place. And when your defenders join forces with your trolls, there’s no way to have your message heard.

That’s why not listening is the cardinal sin of community management. Any other mistake can be overcome: shipping bad product, removing key features, erroneously banning community members, even kicking out a whole segment of customers. And when those allies feel unheard, you simply can’t do anything right. Every little thing becomes a crisis. Choose wisely.

Happy blogiversary (my present: a brand new URL)

2009-09-09T09:09:00.000-07:00

It's official: Startup Lessons Learned has passed the one-year mark. 130 posts (and dozens more that mercifully never saw the light of day), tons of comments, and, of course - you, the awesomest subscribers on the internet. Thank you.

When I first started writing this blog, I made a promise to myself that I would spend more time on the content of the essays than on layout and fancy widgets. I've managed to go a whole year in keeping that promise, even though I get the the occasional teasing about my lame default Blogger theme. Still, it's probably time to start growing up. Today I'm taking the first step, and finally setting the blog up on its own real domain: StartupLessonsLearned.com. I know, it's not a new layout full of Web 2.0 goodness, but it's a start, right?

Back to the content, passing an anniversary is a great time to look back. Luckily, blogs come with an archive, which means you can take your own trip down memory lane. Want to see my very first post? It's a pretty weak homage to Paul Graham. Or how about the first of about a zillion times I used the term lean startup? Read the very first comment (thanks tfitz!) or relive my very first subscriber survey - when there were a grand total of five. Or, for something more substantive, how about the top five-most-read posts:

But wait, there's more! First OODA reference: Ideas. Code. Data. Implement. Measure. Learn. You can also witness the start of my speaking marathon in Built to learn, or leave a comment on my (still-draft) A new version of the Joel Test (draft).

If all that archive-browsing leaves you hungry for more, you will soon be able to get Startup Lessons Learned in book form. I've been experimenting with a simple compilation format. I've given copies to attendees at some recent workshops. The response has been positive, and I'm getting ready for a more general release. If you'd like more info, or want to order one of the beta-test copies, I'd love your feedback. Feel free to drop me a line or leave a comment.

Most of all, thank you so much for your continuing support. It's been a real blast getting to know so many of you - in person, comments, and at events. Please keep the feedback coming. And, if you're feeling really generous, tell a friend to subscribe. Thank you, thank you, thank you.

Oh, and one last thought. It's true, not every comment has been so supportive or constructive. That's the internet for you. So, for the trolls: I've heard you loud and clear. Let me summarize. Actually, I'll let MC Frontalot take it...

Thanks for stopping by!

What would you want to tell Washington DC about startups?

2009-09-08T12:48:00.000-07:00

I'm writing this post from an airplane headed to Washington DC, where I'll be presenting at the Government 2.0 Summit. It's an honor to be invited, and I'm looking forward to meeting a lot of people with a background very different from my usual crowd. I'm especially curious to gauge the reaction of the civilian and military representatives of our government. Beyond just those who will be hearing about the lean startup for the first time, I'm expecting to shake a lot of hands and have a lot of interesting side conversations.

As a result, sitting here on this plane, I've been pondering what message I want to deliver on behalf of startups and entrepreneurs. Thanks to on-board wifi, you can join me in that thought process, if you'd like. So here's my simple question:

What do folks in Washington need to know about the global community of entrepreneurs?

I've been in a few government-themed meetings recently, so I know some of the standard answers. One school of thought is something like: leave startups alone! They are so fragile, the heavy hand of government policy could easily snuff them out while trying to help them. And there's some truth to that, although I think the metaphor is a little misleading. Much of what makes the USA, and Silicon Valley in particular, such a great place to start a company is the result of good government policy. I think a more nuanced view is that we should be encouraging the government to think about the impact on entrepreneurs, and try to foster policies that reduce burdens on companies in their earliest stages. Some of those policies actually require more, not less, government action, because startups risk being crushed by entrenched corporate interests as well.

A second standard theme focuses on each of our financial interest. If the government raises taxes or adds regulation to my sector of the economy, watch out: innovation is doomed. I understand that there is a reason to employ lobbyists to protect established interests, but I'm not really interested in that job. I'd like to see if we can come up with policy suggestions, concerns, or questions that might promote entrepreneurship generally - and globally. It's my fervent belief that will lead to overall economic growth.

So what are good entrepreneur-friendly policies? What is good in the current system that should be preserved? And what hurdles could be eliminated? My short list, off the top of my head (hey, I am in an airplane, after all):

Patent reform (so startups don't have to waste time amassing a deterrent warchest of dubious patents)
Health insurance reform (so more people can take the risk of becoming an entrepreneur)
Stage-appropriate regulation (many regulations kick in only after companies achieve a certain size, which promotes more risk-taking)
Open data and platforms (the major theme of the Gov 2.0 movement - give startups open access to the raw materials so they can create economic growth)
Open spectrum and wireless competition (with obvious benefits, I hope)

What would you add? And beyond just policy suggestions, what facts on the ground do policy-makers need to know about startups? Please leave a comment and let's discuss!

(It's impossible to resist the urge to plug Virgin America as much as possible. Here I am, tens of thousands of feet above the ground, and I have power and broadband. Of course, the real thanks should go to a startup - Gogo Inflight Internet - that I was lucky enough to meet at a recent workshop. Thanks guys!)

Don't be the Ice Cream Glove

2009-09-03T06:49:00.000-07:00

I have a new post up today on O'Reilly Radar, called "Is your product an Ice Cream Glove or a Snuggie?" It is based on two videos I normally use in workshops - each of which contains an important entrepreneurship lesson for all of us. Here's an excerpt:

For those that haven’t watched it, I’ll give a brief recap. Ali G meets with business leaders and investors on Wall Street to learn how to create a new company around a new product idea. After some general lessons, he then proposes his first product idea, complete with flip charts, business plan, and marketing plan. His idea? The Ice Cream Glove, a special glove you can carry around with you so that, if you happen to eat ice cream, you can prevent your hands from getting sticky. After failing to persuade most of the investors to back him in that venture, he then tries to sell a second idea: a Hoverboard, “like from Back to the Future.” After all, they must have made at least one of them for the movie, right?

Both of these ideas for companies are terrible, and the show is funny because he manages to keep on selling them with a straight face. But there are also important lessons baked into the humor. Take the example of the Hoverboard. If you look at the typical startup, you will see the vast majority of their energy and time invested in building new technology. We act as if the biggest risk to startup success is that the technology won’t work. But in reality, most products fail because they are the Ice Cream Glove, that is, because there are no customers who will buy them.

Read the rest (and be sure to watch the videos)...

These videos make an important point: that almost all product ideas sound bad. At the whiteboard, you can make any idea seem brilliant or ridiculous. It's only by actually moving through the fundamental startup feedback loop, which involves facts, that we can find out which have a kernel of truth baked within them.

Let me also say a brief thank you to those who replied to my previous ask for feedback about cross-posting. So far, all the feedback has been in favor of doing it whenever I have a guest post elsewhere. If you have further thoughts, please leave them as a comment. Thanks!

Building a new startup hub

2009-08-26T15:31:00.001-07:00

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

2009-08-24T05:33:00.000-07:00

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

2009-08-20T05:38:00.000-07:00

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.

Fall speaking tour starts tomorrow

2009-08-18T19:18:00.000-07:00

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

2009-08-08T18:22:00.000-07:00

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)

2009-08-08T05:17:00.000-07:00

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

2009-08-03T06:00:00.000-07:00

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

2009-08-01T05:00:00.000-07:00

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

2009-07-31T05:00:00.000-07:00

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