Just wanted to give everyone a heads-up that I'll be appearing on stage with Steve Blank tomorrow, April 30th, at the startup2startup event in Palo Alto. For more info, you can read the event description here. We'll be attempting some new material, so should be an interesting event.
As a reminder, on Friday, May 1 I'll be doing a free webcast with O'Reilly at 10am PT: "How to Build a Lean Startup, step-by-step." Although the event is free, it does require advance registration.
Later in May, I have a few events coming up. The first is a panel at TiEcon on May 15. I'll be moderating a panel on "Building an Internet Company for $50K." Then, on Thursday May 21, I'll be on the HP campus for a SIPA event that is open to the public; you can register here. And, of course, there's the all-day Lean Startup Workshop on May 29th in San Francisco. This is already mostly sold-out due to pre-orders from the customer validation survey (!), but I am investigating if we can accommodate any additional spots. If you're interested, please make sure to take the survey and then drop me an email to let me know.
For those of you in Austin, I'm currently working on a series of events there in early June. I'll have more details once it's confirmed, but mark your calendars for a likely TeXchange event the evening of June 3. I'm also going to meet with a few companies and VC's for some one-on-one and small-group consulting; if you're interested in something like that, please get in touch.
I'm doing my best to keep up with the current requests for speaking, so please don't be offended if you've written and I haven't gotten back to you. If you know people who might like to host or help organize events, I'm currently working on trips to Boston, New York, another trip to Vancouver, and even some possible events in Europe (around Øredev). Please drop me a line if you might be able to help.
Lastly, as always, if you do attend one of these events please come say hello. It's always great to meet and hear feedback from readers. Thank you all so much.
Wednesday, April 29, 2009
Sunday, April 26, 2009
Product development leverage
Leverage has once again become a dirty word in the world of finance, and rightly so. But I want to talk about a different kind of leverage, the kind that you can get in product development. It's a force that allows startups to build products at parity with much larger companies - cheaper and much faster. It's a key lean startup concept.
The idea of leverage is simple: for every ounce of effort your product development team puts into your product, find ways to magnify that effort by getting many other people to invest along with you.
Leverage was one of the big ideas we talked about early on at IMVU. We knew that we were only a small team, but we had big aspirations. We wanted to create a 3D product that could provide superior options for self-expression to millions of people. Other companies accomplish this by hiring a large staff of content production experts - and get a very good result. We didn't think we'd able to compete with that. Plus, we saw some of the intrinsic limitations of supporting such a large staff: slower cycle times, higher cost basis, and - most importantly - the ability to serve only a limited number of customer segments. For segments that were considered out of the mainstream or somewhat obscure, the ROI just isn't there for these established companies to serve them.
So we tried to craft a strategy that would give us the product development leverage we needed to serve all customers. We combined three tactics: extensive use of free software, an open platform for user-generated content, and leveraged distribution channels. Each of these tactics was effective, and I'll return to them in detail in a moment. The net result was powerful: within six months of starting the company, we were able to get a basic version of our product into open beta. Although customers didn't flock to this offering at first, we had enough of a developer program active to start recruiting early adopters to start creating 3D objects for sale in our catalog. That engine of creativity has led to a catalog of something like 2 million virtual goods authored by a hundred thousand developers. At no time did IMVU ever employ more than three full-time 3D artists. Most importantly, there is almost no niche or trend that is unserved by this community. Want emo shoes (172,190 available), goth earrings (152,996 available) or anime-themed furniture (55,240 available)? Yeah, we've got that.
Leverage is work, though. It has to be found and managed. For more on the specific trade-offs involved with IMVU's virtual good strategy, see Three decisions to make on virtual goods. In that same spirit, here are some suggestions for tactics you can use to increase the leverage of your product development efforts:
For example, I have wasted a lot of time in my career trying to argue for the superiority of open source solutions over comparable proprietary solutions. These arguments have ranged from the ethical, to performance comparisons, to feature-by-feature breakdowns. But I now realize that none of that was very useful. Instead, the real compelling reason to switch from proprietary platforms and vendors is the advantage you can gain in leverage, even if you give up other serious benefits. When proprietary vendors focus too much on value capture, their products become expensive, inflexible to change, and require too much permission to adapt to new contexts. All of which can slow down startups in just the places where they need to speed up. Thus, the right argument to make in evaluating proprietary alternatives is simply this: will this vendor speed us up or slow us down? If the latter, almost no benefit in terms of price, price/performance, product support, or lifetime total cost of ownership is worth it.
Once startups and vendors really understand this dynamic, we can all get past these legacy arguments and start focusing on building partnerships that truly make it easier to create companies that matter. In the meantime, I think we have a good explanation for what all those PR dollars are being spent trying to obscure. Don't fall for it - it's a trap.
The idea of leverage is simple: for every ounce of effort your product development team puts into your product, find ways to magnify that effort by getting many other people to invest along with you.
Leverage was one of the big ideas we talked about early on at IMVU. We knew that we were only a small team, but we had big aspirations. We wanted to create a 3D product that could provide superior options for self-expression to millions of people. Other companies accomplish this by hiring a large staff of content production experts - and get a very good result. We didn't think we'd able to compete with that. Plus, we saw some of the intrinsic limitations of supporting such a large staff: slower cycle times, higher cost basis, and - most importantly - the ability to serve only a limited number of customer segments. For segments that were considered out of the mainstream or somewhat obscure, the ROI just isn't there for these established companies to serve them.
So we tried to craft a strategy that would give us the product development leverage we needed to serve all customers. We combined three tactics: extensive use of free software, an open platform for user-generated content, and leveraged distribution channels. Each of these tactics was effective, and I'll return to them in detail in a moment. The net result was powerful: within six months of starting the company, we were able to get a basic version of our product into open beta. Although customers didn't flock to this offering at first, we had enough of a developer program active to start recruiting early adopters to start creating 3D objects for sale in our catalog. That engine of creativity has led to a catalog of something like 2 million virtual goods authored by a hundred thousand developers. At no time did IMVU ever employ more than three full-time 3D artists. Most importantly, there is almost no niche or trend that is unserved by this community. Want emo shoes (172,190 available), goth earrings (152,996 available) or anime-themed furniture (55,240 available)? Yeah, we've got that.
Leverage is work, though. It has to be found and managed. For more on the specific trade-offs involved with IMVU's virtual good strategy, see Three decisions to make on virtual goods. In that same spirit, here are some suggestions for tactics you can use to increase the leverage of your product development efforts:
- Free and open source software (and even hardware). When you participate in an open community like these you take advantage of tremendous amounts of effort. Even as "just a user" you make the community better by adding momentum. Even better, if you engage with the community in a mutual relationship, you can increase your leverage further. For example, IMVU early on decided on using an open source library for our 3D file formats, skeletal animation, and scene graph. As a result, we were able to get started more quickly, avoid writing a ton of art path tools from scratch, and even hire from within that community. It's an amazing thing when you can hire an employee who knows more about your code base than you do, and this turned out to be a big source of advantage. Over the years, we've made many contributions back to this community; if its formats become standard, the company benefits further. (Of course, there are ethical reasons to prefer free software to proprietary software, too - but they don't bear on this particular discussion so I am omitting them intentionally)
- User-generated content. Our original mission statement for IMVU was "to fulfill the promise of online socializing and creativity." We hoped that user-creators would be part of our model from day one. Part of this was a values statement. We had been in a previous company whose pursuit of centralized control had proved damaging in many ways. But part was a recognition that we could gain substantial competitive advantage by leveraging a community of like-minded visionary customers to serve a wider (and more mainstream) audience than we could alone. Making UGC work requires good tools, open standards, and proper incentive design. Personally, the framework I've found most helpful is MTV's "create, share, validate" feedback loop. By focusing on giving creators all three, we were able to reap the rewards of their shared efforts. In the end, I believe they co-created our product with us.
- Leveraged distribution channels. It's now possible to gain massive distribution for almost any product without asking anyone for permission or signing a complex contract. This is what Google AdWords, Facebook Platform, the iPhone App Store, and Salesforce AppExchange all have in common. If you have the opportunity to use these channels to reach customers, you can iterate much faster and gain traction before more established competitors can move to check your growth. Of course, all of these mechanism have their own attendant risks, two in particular: 1) that the platform provider will itself decide to compete with you or just limit your growth (as Microsoft has a long history of doing, and as Facebook and Google have occasionally dabbled in), 2) that the ease of distribution empowers new competitors to chase you more effectively. Still, these risks are thoroughly mitigated if you can iterate faster than either set of competitors - and, as a startup, you shouldn't have any excuse for allowing that to happen. (For a specific application of this idea, see How to get distribution advantage on the iPhone.)
- Open API's and data-oriented architecture (aka "web 2.0"). The much-promised era of component reuse in software is finally upon us. Some of that is enabled by open source, but a lot more is enabled by simple services that allow apps to be composited in record time and without having to ask for permission. Many complex apps can now be prototyped as a simple mashup in order to prove market viability - and this is true beyond just software apps. For example, I recently created a customer validation exercise around the Lean Startup Workshop. It allowed me to assess the market demand for that offline product before I had the final product baked. Doing the market test required this blog, a SurveyMonkey account and a PayPal account - and nothing else. The response has been nothing short of amazing (thank you all so much!). I'll post more about the specifics of what I learned from this exercise in a future post, but for now I want to focus on how much learning it made possible for such a small amount of effort. And yet, even though it wasn't very costly overall, all of the players involved (including me, Google, PayPal and SurveyMonkey) were able to create and capture real value. Multiply that by the large numbers of similar "long tail" creators like me, and you can see how much leverage this ecosystem is creating.
- On-demand utility pricing for services (aka "cloud computing"). This is really a specific instance of many of the above trends synthesized together. But it's had such an impact that I think it's worth itemizing on its own. Naturally, everyone is using tools like Amazon's AWS and Google's AppEngine to prototype their startup's first version, thus lowering both time to market and capital equipment costs. But I'd like to call out special attention to services like Amazon's new FPS payment platform, which allows people to create new web services that are charged on a cost-plus basis. In effect, this allows you to create a new AWS service, profit by it, and distribute it alongside Amazon's other first-party services. I believe this is going to unlock a huge wave of innovative services available with utility pricing.
For example, I have wasted a lot of time in my career trying to argue for the superiority of open source solutions over comparable proprietary solutions. These arguments have ranged from the ethical, to performance comparisons, to feature-by-feature breakdowns. But I now realize that none of that was very useful. Instead, the real compelling reason to switch from proprietary platforms and vendors is the advantage you can gain in leverage, even if you give up other serious benefits. When proprietary vendors focus too much on value capture, their products become expensive, inflexible to change, and require too much permission to adapt to new contexts. All of which can slow down startups in just the places where they need to speed up. Thus, the right argument to make in evaluating proprietary alternatives is simply this: will this vendor speed us up or slow us down? If the latter, almost no benefit in terms of price, price/performance, product support, or lifetime total cost of ownership is worth it.
Once startups and vendors really understand this dynamic, we can all get past these legacy arguments and start focusing on building partnerships that truly make it easier to create companies that matter. In the meantime, I think we have a good explanation for what all those PR dollars are being spent trying to obscure. Don't fall for it - it's a trap.
Tuesday, April 14, 2009
Validated learning about customers
Would you rather have $30,000 or $1 million in revenues for your startup? Sounds like a no-brainer, but I’d like to try and convince you that it’s not. All things being equal, of course, you’d rather have more revenue rather than less. But all things are never equal. In an early-stage startup especially, revenue is not an important goal in and of itself.
This may sound crazy, coming as it does from an advocate of charging customers for your product from day one. I have counseled innumerable entrepreneurs to change their focus to revenue, and many companies who refuse this advice get themselves into trouble by running out of iterations. And yet revenue alone is not a sufficient goal. Focusing on it exclusively can lead to failure as surely as ignoring it altogether.
Let’s start with a simple question: why do early-stage startups want revenue? We all know why big companies want revenue – it’s one of two critical halves of the formula for profit. And big companies exist to maximize profit. Don’t startups exist for the same reason? I think such reasoning is an example of the “startup dollhouse fallacy” – that startups are just shrunken-down big companies. In fact, I don’t think revenue is in and of itself a goal for startups, and neither is profit. What matters is proving the viability of the company’s business model, what investors call “traction.” Demonstrating traction is the true purpose of revenue in an early growth company. (Of course this is not at all true of many profitable small businesses, but they are not what I mean by startups.) Before I explain what I mean, let me add an important caveat: traction is not just important for investors. It should be even more important to the founders themselves, because it demonstrates that their business hypothesis is grounded in reality. More on that in a moment.
Consider this company (as always, a fictionalized composite): they have a million dollars of revenue, and are showing growth quarter after quarter. And yet, their investors are frustrated. Every board meeting, the metrics of success change. Their product definition fluctuates wildly – one month, it’s a dessert topping, the next it’s a floor wax. Their product development team is hard at work on a next-generation product platform, which is designed to offer a new suite of products – but this effort is months behind schedule. In fact, this company hasn’t shipped any new products in months. And yet their numbers continue to grow, month after month. What’s going on?
In my consulting practice, I sometimes have the opportunity to work with companies like this. Diagnosis is easy: they are exceptionally gifted salesmen. This is an incredible skill, one that most engineers overlook. True salesmen are artists, able to hone in on just those key words, phrases, features, and benefits that will convince another human being to give up their hard-earned money in exchange for even an early product. For a startup, having great sales DNA is a wonderful asset. But in this kind of situation, it can devour the company’s future.
The problem stems from selling each customer a custom one-time product. This is the magic of sales: by learning about each customer in-depth, they can convince each of them that this product would solve serious problems. That leads to cashing many checks. Now, in some situations, this over-selling would lead to a secondary problem, namely, that customers would realize they had been duped and refuse to re-subscribe. But here’s where a truly great sales artist comes in. Customers don’t usually mind a bait-and-switch if the switched-to product really does solve an important problem for them. These salesmen used their insight into what their customers really needed to make the sale and then deliver something of even greater value. They are closing orders. They are gaining valuable customer data. They are close to breakeven. What’s the problem?
This approach is fundamentally non-scalable. These founders have not managed, to borrow a phrase from Steve Blank, to create a scalable and repeatable sales process. Every sale requires handholding and personal attention from the founders themselves. This process cannot be delegated, because it’s impossible to explain to a normal person what’s involved in making the sale. The founders have a lethal combination of insight about what potential customers want and in-depth knowledge about what their current product can really deliver. As a result, potential customers are being turned away; they can only afford to engage with the customers that are best qualified.
And what of the product development team? They are busy too, but they are not creating value for the company. They are trying to build a product to an ever-changing spec, based on intuitions from the founders about what might be able to sell itself. Worse, the founders are never around – they are too busy going out and selling! Without access to customer data, or even a clear product owner, the product development team keeps building feature after feature based on what they think might be useful. But since nobody in the company can clearly articulate what the product is, their efforts result in incoherence. Worst of all, their next-generation product is so bad they are not allowed to try it out on any customers. The team is thus completely starved of any form of external feedback.
Let me describe a different company, one with only $30,000 in revenue (again, pure fiction). This company has a large long-term vision, but their current product is only a fraction of what they hope to build. Compared to the million-dollar startup, they are operating at micro-scale. How does that stack up?
First of all, they are not selling their product by hand. Instead, each potential customer has to go through a self-serve process of signing up and paying money. Because they have no presence in the market, they have to find distribution channels to bring in customers. They can only afford those (like Google AdWords) that support buying in small volume.
Compensating for these limitations is the fact that they know each of their customers extremely well, and they are constantly experimenting with new product features and product marketing to increase the yield on each new crop of customers they bring in. Over time, they have found a formula for acquiring, qualifying, and selling customers in the market segments they have targeted. Most importantly, they have lots of data about the unit economics of their business. They know how much it costs to bring in a customer and they know how much money they can expect to make on each one.
In other words, they have learned to grow renewable audiences. Given the data they’ve collected about these early customers, they are also able to estimate with modest precision how big the market is for their product in its current form. They may be at micro-scale now, but they are in a very good position to raise venture money and engage in extremely rapid growth.
Our million-dollar startup, by contrast, is stuck in the mud.
Stories like these are what has led me to this definition of progress for a startup: validated learning about customers. (Steve calls this just Customer Validation, but I like to emphasize the learning aspect, so I accept a far more awkward phrase.)
This unit of progress is remarkable in several ways. First of all, it means that most aggregate measures of success, like total revenue, are not very useful. They don’t tell us the key things we need to know about the business: how profitable is it on a per-customer basis? What’s the total available market? What’s the ROI on acquiring new customers? And how do existing customers respond to our product over time?
Secondly, this definition locates progress firmly in the heads of the people inside the company, and not in any artifacts the company produces. That’s why none of dollars, milestones, products or code can count as progress. Given a choice between what a successful team has learned and the source code they have produced, I would take the learning every time. This is why companies often get out-competed by former employees (Palm vs Handspring to name just one), even though the upstart lacks all of the familiar resources, tools, processes, and support they used to have. (Incidentally, it’s also why these upstarts often get sued for bogus reasons. Companies can’t believe they didn’t steal any of their “precious” assets.)
But learning is a tricky thing to quantify, which is why the word “validated” is so important in this definition. Validation comes in the form of data that demonstrates that the key risks in the business have been addressed by the current product. That doesn’t always mean revenue, either. Some products have relatively obvious monetization mechanisms, and the real risks are in customer adoption. Products can find sources of validation with impressive stats along a number of dimensions, such as high engagement, viral coefficient, or long-term retention. What’s important is that the data tell a compelling story, one that demonstrates that the business is on a solid economic footing. (It being so easy to convince yourself that you’re in one of these “special case” businesses, I do recommend you give revenue a long, hard look first.)
For example, I’ve talked a few times about how IMVU raised its first venture round with monthly revenues of around $10,000. This wasn’t very impressive, but we had two things going for us:
Let’s return to my example of the million-dollar-revenue company. If you find yourself in this kind of situation, what can you do? I’d suggest a few things, each rooted in the idea of breaking down the wall between the two halves of this company.
This may sound crazy, coming as it does from an advocate of charging customers for your product from day one. I have counseled innumerable entrepreneurs to change their focus to revenue, and many companies who refuse this advice get themselves into trouble by running out of iterations. And yet revenue alone is not a sufficient goal. Focusing on it exclusively can lead to failure as surely as ignoring it altogether.
Let’s start with a simple question: why do early-stage startups want revenue? We all know why big companies want revenue – it’s one of two critical halves of the formula for profit. And big companies exist to maximize profit. Don’t startups exist for the same reason? I think such reasoning is an example of the “startup dollhouse fallacy” – that startups are just shrunken-down big companies. In fact, I don’t think revenue is in and of itself a goal for startups, and neither is profit. What matters is proving the viability of the company’s business model, what investors call “traction.” Demonstrating traction is the true purpose of revenue in an early growth company. (Of course this is not at all true of many profitable small businesses, but they are not what I mean by startups.) Before I explain what I mean, let me add an important caveat: traction is not just important for investors. It should be even more important to the founders themselves, because it demonstrates that their business hypothesis is grounded in reality. More on that in a moment.
Consider this company (as always, a fictionalized composite): they have a million dollars of revenue, and are showing growth quarter after quarter. And yet, their investors are frustrated. Every board meeting, the metrics of success change. Their product definition fluctuates wildly – one month, it’s a dessert topping, the next it’s a floor wax. Their product development team is hard at work on a next-generation product platform, which is designed to offer a new suite of products – but this effort is months behind schedule. In fact, this company hasn’t shipped any new products in months. And yet their numbers continue to grow, month after month. What’s going on?
In my consulting practice, I sometimes have the opportunity to work with companies like this. Diagnosis is easy: they are exceptionally gifted salesmen. This is an incredible skill, one that most engineers overlook. True salesmen are artists, able to hone in on just those key words, phrases, features, and benefits that will convince another human being to give up their hard-earned money in exchange for even an early product. For a startup, having great sales DNA is a wonderful asset. But in this kind of situation, it can devour the company’s future.
The problem stems from selling each customer a custom one-time product. This is the magic of sales: by learning about each customer in-depth, they can convince each of them that this product would solve serious problems. That leads to cashing many checks. Now, in some situations, this over-selling would lead to a secondary problem, namely, that customers would realize they had been duped and refuse to re-subscribe. But here’s where a truly great sales artist comes in. Customers don’t usually mind a bait-and-switch if the switched-to product really does solve an important problem for them. These salesmen used their insight into what their customers really needed to make the sale and then deliver something of even greater value. They are closing orders. They are gaining valuable customer data. They are close to breakeven. What’s the problem?
This approach is fundamentally non-scalable. These founders have not managed, to borrow a phrase from Steve Blank, to create a scalable and repeatable sales process. Every sale requires handholding and personal attention from the founders themselves. This process cannot be delegated, because it’s impossible to explain to a normal person what’s involved in making the sale. The founders have a lethal combination of insight about what potential customers want and in-depth knowledge about what their current product can really deliver. As a result, potential customers are being turned away; they can only afford to engage with the customers that are best qualified.
And what of the product development team? They are busy too, but they are not creating value for the company. They are trying to build a product to an ever-changing spec, based on intuitions from the founders about what might be able to sell itself. Worse, the founders are never around – they are too busy going out and selling! Without access to customer data, or even a clear product owner, the product development team keeps building feature after feature based on what they think might be useful. But since nobody in the company can clearly articulate what the product is, their efforts result in incoherence. Worst of all, their next-generation product is so bad they are not allowed to try it out on any customers. The team is thus completely starved of any form of external feedback.
Let me describe a different company, one with only $30,000 in revenue (again, pure fiction). This company has a large long-term vision, but their current product is only a fraction of what they hope to build. Compared to the million-dollar startup, they are operating at micro-scale. How does that stack up?
First of all, they are not selling their product by hand. Instead, each potential customer has to go through a self-serve process of signing up and paying money. Because they have no presence in the market, they have to find distribution channels to bring in customers. They can only afford those (like Google AdWords) that support buying in small volume.
Compensating for these limitations is the fact that they know each of their customers extremely well, and they are constantly experimenting with new product features and product marketing to increase the yield on each new crop of customers they bring in. Over time, they have found a formula for acquiring, qualifying, and selling customers in the market segments they have targeted. Most importantly, they have lots of data about the unit economics of their business. They know how much it costs to bring in a customer and they know how much money they can expect to make on each one.
In other words, they have learned to grow renewable audiences. Given the data they’ve collected about these early customers, they are also able to estimate with modest precision how big the market is for their product in its current form. They may be at micro-scale now, but they are in a very good position to raise venture money and engage in extremely rapid growth.
Our million-dollar startup, by contrast, is stuck in the mud.
Stories like these are what has led me to this definition of progress for a startup: validated learning about customers. (Steve calls this just Customer Validation, but I like to emphasize the learning aspect, so I accept a far more awkward phrase.)
This unit of progress is remarkable in several ways. First of all, it means that most aggregate measures of success, like total revenue, are not very useful. They don’t tell us the key things we need to know about the business: how profitable is it on a per-customer basis? What’s the total available market? What’s the ROI on acquiring new customers? And how do existing customers respond to our product over time?
Secondly, this definition locates progress firmly in the heads of the people inside the company, and not in any artifacts the company produces. That’s why none of dollars, milestones, products or code can count as progress. Given a choice between what a successful team has learned and the source code they have produced, I would take the learning every time. This is why companies often get out-competed by former employees (Palm vs Handspring to name just one), even though the upstart lacks all of the familiar resources, tools, processes, and support they used to have. (Incidentally, it’s also why these upstarts often get sued for bogus reasons. Companies can’t believe they didn’t steal any of their “precious” assets.)
But learning is a tricky thing to quantify, which is why the word “validated” is so important in this definition. Validation comes in the form of data that demonstrates that the key risks in the business have been addressed by the current product. That doesn’t always mean revenue, either. Some products have relatively obvious monetization mechanisms, and the real risks are in customer adoption. Products can find sources of validation with impressive stats along a number of dimensions, such as high engagement, viral coefficient, or long-term retention. What’s important is that the data tell a compelling story, one that demonstrates that the business is on a solid economic footing. (It being so easy to convince yourself that you’re in one of these “special case” businesses, I do recommend you give revenue a long, hard look first.)
For example, I’ve talked a few times about how IMVU raised its first venture round with monthly revenues of around $10,000. This wasn’t very impressive, but we had two things going for us:
- A hockey stick shaped growth curve. People often forget the most important part of the hockey stick: the long flat part. We had months of data that showed customers more-or-less uninterested in our product. We were limping along at a few hundred dollars a month in revenue. All this time, we were continuously changing our product, talking to customers, trying to improve on our AdWords spend. Eventually, these efforts bore fruit – and this was evident in the data. This lent our claims about learning and discovery credibility.
- Compelling per-customer economics. We had only a small number of customers – if memory serves, only a few thousand active users. But a little math will show that we were making over a dollar per-user per-month. Our cost to acquire a customer on AdWords was only a few cents. Our eventual VC’s were quick to grasp what this meant (in fact, they understood it better than we did): that if our product achieved significant scale, it would be wildly profitable.
Let’s return to my example of the million-dollar-revenue company. If you find yourself in this kind of situation, what can you do? I’d suggest a few things, each rooted in the idea of breaking down the wall between the two halves of this company.
- Go on an agile diet quickly. With a product development team that is not shipping, any agile methodology will surface major problems quickly. Force anyone who is in customer contact to take the role of the Product Owner and insist that they deliver something new on a short regular interval.
- Get product into customers’ hands. The sales strategy currently leaves many customers completely un-served (those that don’t qualify for the founders’ personal time). Start using some of those customers as guinea pigs for a self-serve version of the product. Even if the product is absolutely terrible, it will establish a baseline against which the product development team can try and improve.
- Build tools for the sales team that reduce the time investment required for each sale. Instead of devoting all product development efforts to building a full-blown product, try building just those parts of the product that would allow the current sales process to go a little faster. For example, could we develop a simple landing page that would allow customers to pre-qualify for sales time? Iterating on these kinds of features has two benefits: it frees up time for the founders and simultaneously starts getting building a feedback loop with the product development team. Pretty soon, the text on that landing page is going to become an effective explanation for what the product does, because if it’s not the salesman will have to spend time re-explaining the product to potential customers. Time-to-complete-a-sale is not a bad metric for validated learning at this stage.
Thursday, April 9, 2009
Built to learn
It's been an exhilarating ride since the Web 2.0 Expo last week. Thank you all so much for making the event an overwhelming success (way beyond my wildest expectations) and a special thanks to all of you who have reached out to share your feedback, comments, and questions since then.
I have been meaning to write this post for days, but the meetings have been non-stop and I haven't had much time. First of all, I promised to post the full slides of the talk, which are below. I want to thank those people who were recording, tweeting, and posting from the hall itself. Thanks to you I know about the energy in the room and even have pictures to prove it. Best of all, Nivi from Venture Hacks was recording, so these slides have synchronized audio, too.
I learned an incredible amount by giving this talk, especially from the many people who have commented, disagreed, and asked questions about it. Here are some of my top takeaways. Rather than use boring section headers, I thought I'd just quote from actual customers, in their own words.
Creating a company-wide feedback loop that incorporates both customer development and agile development is a challenge. Traditional department labels just make it harder. So instead of having sales, marketing, and business development, we have a problem team implementing customer development. But where it makes sense, that team may also include engineers building new experiments or prototypes to try with customers. And instead of design, engineering, QA, and operations we have a solution team implementing a startup-centric version of agile development. But that team may also include product marketers or other in-house customers who can give insight into the impact that solution trade-offs might have on customers. Most of all these two teams are in constant contact, sharing insights, hypotheses and -- above all -- data.
Metrics are a key questions startups face. How do we decide what to measure and why? What do we do about it once we get started? I didn't start life as a metrics-lover, and it took me many years to learn to distinguish between "vanity metrics" that make us feel good and "actionable metrics" that help us make decisions. "Metrics are people too" is a reminder I constantly needed when I was a manager. It's not about moving numbers in a spreadsheet, it's about changing customer behavior -- for the better. When people ask about how to reconcile metrics with interaction design, usability testing, or in-person customer interviews, this is the issue they are really talking about. When we lose sight of the humanity of our customers, we're not likely to be able to delight them.
There's no skipping the chasm. Startups have no choice but to first talk to and sell to what Steve calls earlyvangelists. This is true whether you're selling million-dollar software to huge enterprises or selling fifty-cent virtual clothes to teenagers. Only the truly visionary customers will engage early-on. Luckily, they can help you find their mainstream counterparts, if you listen closely.
I have been meaning to write this post for days, but the meetings have been non-stop and I haven't had much time. First of all, I promised to post the full slides of the talk, which are below. I want to thank those people who were recording, tweeting, and posting from the hall itself. Thanks to you I know about the energy in the room and even have pictures to prove it. Best of all, Nivi from Venture Hacks was recording, so these slides have synchronized audio, too.
I learned an incredible amount by giving this talk, especially from the many people who have commented, disagreed, and asked questions about it. Here are some of my top takeaways. Rather than use boring section headers, I thought I'd just quote from actual customers, in their own words.
Mark's point is the one that seems to have had the biggest impact from the talk as a whole: that startups should be built to learn. That's the essence of so many of the lean startup techniques I've evangelized: customer development, the Ideas/Code/Data feedback loop, and the adaptation of agile development to the startup experience. Many people asked some variation of the question: "sure, learning sounds good. But how do I actually organize my team so that we actually do it day-in day-out?" Answering that question is what I'm striving to do on this blog (and at future webcasts and workshops).MarkH: Key takeaways from Eric's great talk #w2e #leanstartup 1) "building a culture to learn" @ericries
Steve Blank has evangelized the "no departments" theme for many years. This is my take on that idea. The insight is that waterfall and agile are well-adapted for situations of "known problem, known solution" and "known problem, unknown solution" respectively. The lean startup focuses on situations where we have both an unknown problem and an unknown solution.blader: @ericries my #1 takeaway from #leanstartup: "No marketing team. No engineering team. You need a problem team and a solution team."
Creating a company-wide feedback loop that incorporates both customer development and agile development is a challenge. Traditional department labels just make it harder. So instead of having sales, marketing, and business development, we have a problem team implementing customer development. But where it makes sense, that team may also include engineers building new experiments or prototypes to try with customers. And instead of design, engineering, QA, and operations we have a solution team implementing a startup-centric version of agile development. But that team may also include product marketers or other in-house customers who can give insight into the impact that solution trade-offs might have on customers. Most of all these two teams are in constant contact, sharing insights, hypotheses and -- above all -- data.
rahmin: #leanstartup unit of progress: validated learning about customers, preferably with $$$ attached - @ericriesOnce we have our problem team and solution team, it's essential that they share a single definition of progress: validated learning about customers. It's not good enough to hit product milestones and conduct usability tests. We have to actually validate our key business theories and prove that we're on a path to creating somethng that matters.
adachen: The biggest source of waste at a startup is building something that no one wants #leanstartup
dalelarson: "Metrics are people, too." @ericries's talk on Lean Startups absolutely fantastic. #leanstartup(Gotta love using twitter quotes, since they occaisionally come with compliments attached).
ericnsantos: #w2e #leanstartup Metrics should be Actionable, Accessible and Auditable. Use them to split-test all the time.
Metrics are a key questions startups face. How do we decide what to measure and why? What do we do about it once we get started? I didn't start life as a metrics-lover, and it took me many years to learn to distinguish between "vanity metrics" that make us feel good and "actionable metrics" that help us make decisions. "Metrics are people too" is a reminder I constantly needed when I was a manager. It's not about moving numbers in a spreadsheet, it's about changing customer behavior -- for the better. When people ask about how to reconcile metrics with interaction design, usability testing, or in-person customer interviews, this is the issue they are really talking about. When we lose sight of the humanity of our customers, we're not likely to be able to delight them.
sachinrekhi: "Visionary customers are as smart if not smarter then the founders" #leanstartup
hansoo: #leanstartup "MBA fallacy: whiteboard, think about it, whiteboard some more, think about it, whiteboard, feel good about your idea"
Although I never went to business school, I have committed the "MBA's fallacy" many times. It's actually the fastest way to iterate on a business: just keep reworking it at the whiteboard. At IMVU, I remember spending an incredible amount of time iterating on the model that would power our third-party developer economy. My cofounders and I would hash out nuances and details almost every day, re-drawing diagram after diagram on the whiteboard. Now, the first few times we thought through those issues, we probably did some quality thinking. But pretty soon it degenerated into fact-free bloviating. If it doesn't involve new facts, it doesn't count as learning.
So without further ado, let me share the slides with audio.
Upcoming Events
If you missed the session at Web 2.0 Expo, never fear. I'm doing my best to satisfy the many requests I've had to provide more in-depth material and more diverse locations.
April 21 - Agile Vancouver is sold-out (thank you all so much!). However, for those who weren't able to get in (or are real gluttons for punishment), I will be speaking the night before at a free event hosted by . It will be a more-technical version of the Expo talk. You can register here. I'm doing my best to live up to the three-!!! billing.
May 1 - free webcast. I'm doing a webcast with O'Reilly that is free and open to the public. We'll be discussing in greater detail the three techniques I highlighted at the Expo: continuous deployment, split-testing, and five whys. Here's the promo; more information is available on their site.
I'll continue to post about additional events as I get them scheduled. Looks like I'll be at TiEcon 2009 in mid-may, and at an event to be announced in Austin in early June.
Thanks for reading, attending, commenting and questioning. I'm continually inspired by your entrepreneurial passion and insight. Thank you.
MeganMurray: "Behind every technical problem is a human problem. Fix the cause, not just the symptom." #leanstartup #w2e (via @blader) AmenIf you are willing to follow a continuous-improvement methodology like five whys, you can re-derive almost all of the lean startup techniques, and probably discover many more besides. All it takes is that you focus seriously on the idea that you're not willing to waste time having the same problem occur twice. It sounds easy, but in practice it usually means a radical shift in perspective, one that can help see through the apparently technical problems that most of us who are engineers spend our time fixing. Those are only symptoms.
mcavalcanti: #w2e #leanstartup every technical problem is a usually a human problem.
jonbischke: "We're fine with having any problem occur one time. But no problem can occur twice." @ericries #leanstartup #w2e
So without further ado, let me share the slides with audio.
Upcoming Events
If you missed the session at Web 2.0 Expo, never fear. I'm doing my best to satisfy the many requests I've had to provide more in-depth material and more diverse locations.
April 21 - Agile Vancouver is sold-out (thank you all so much!). However, for those who weren't able to get in (or are real gluttons for punishment), I will be speaking the night before at a free event hosted by . It will be a more-technical version of the Expo talk. You can register here. I'm doing my best to live up to the three-!!! billing.
May 1 - free webcast. I'm doing a webcast with O'Reilly that is free and open to the public. We'll be discussing in greater detail the three techniques I highlighted at the Expo: continuous deployment, split-testing, and five whys. Here's the promo; more information is available on their site.
How to Build a Lean Startup, step-by-stepMay 29 - the Lean Startup Workshop. I am particularly excited about this, as it will be a really in-depth discussion. The workshop will go all day and will be for a carefully screened audience. If you'd like to register, you have to take the survey. At the end, you'll be given the opportunity to participate in a customer validation exercise where you can reserve a spot, or just sign up to be notified when applications will start.
Get started with a detailed guide to three key lean startup techniques: continuous deployment, rapid split-testing, and root cause analysis (five why's). This webcast will cover the theory of how lean startups work, implementation details, and case studies. Participants will come away with a specific plan of action for how to apply these techniques to their product, company, or startup.
Register here.
I'll continue to post about additional events as I get them scheduled. Looks like I'll be at TiEcon 2009 in mid-may, and at an event to be announced in Austin in early June.
Thanks for reading, attending, commenting and questioning. I'm continually inspired by your entrepreneurial passion and insight. Thank you.
Wednesday, April 1, 2009
Web 2.0 Expo session followup
The room was utterly packed today at Web 2.0 Expo, and the discussion afterward at the web2open was amazing. Thank you all so much for coming. I had brought a stack of fliers with me with one of the "Ideas-Code-Data" feedback loop infographics on one side, and information about the upcoming workshop on the other.
I dramatically underestimated the number that I would need, and there was almost a riot as people rushed the stage once they realized they were going fast. Note to self: avoid bodily injury via more fliers next time!
Anyway, I promised that I would post an electronic copy of the flier as soon as humanly possible, which is right now. I'll save further commentary for a future post, and the Expo will eventually post the full deck that I used in the room. Suffice for now to say that I am incredible grateful, honored and humbled by the turnout, the incredible questions and comments, and the passion you all shared with me. Thank you thank you thank you.
I'm following the conversation on #leanstartup on Twitter, if you'd like to follow along or participate. Your feedback is always much appreciated.
Without further ado, and with many thanks to the guys from KISSmetrics who helped with the snappy design...
I dramatically underestimated the number that I would need, and there was almost a riot as people rushed the stage once they realized they were going fast. Note to self: avoid bodily injury via more fliers next time!
Anyway, I promised that I would post an electronic copy of the flier as soon as humanly possible, which is right now. I'll save further commentary for a future post, and the Expo will eventually post the full deck that I used in the room. Suffice for now to say that I am incredible grateful, honored and humbled by the turnout, the incredible questions and comments, and the passion you all shared with me. Thank you thank you thank you.
I'm following the conversation on #leanstartup on Twitter, if you'd like to follow along or participate. Your feedback is always much appreciated.
Without further ado, and with many thanks to the guys from KISSmetrics who helped with the snappy design...
Subscribe to:
Posts (Atom)
