The Dark Side of Customer Development and Lean Startups(coconutheadsets.com)
coconutheadsets.com
The Dark Side of Customer Development and Lean Startups
http://coconutheadsets.com/2009/11/28/the-dark-side-of-customer-development-and-lean-startups/
16 comments
I think post author missed the point of "lean". The point is to iterate through a few adjacent market positions with the lowest cost possible until you find one which resonates with users the most. Once you found one, by all means get out of lean and start building out like mad.
This is an alternative to building out like mad something that you have no idea if anyone wants to pay money for, and then doing it again and again at great expense of time, money and morale. Think ".com" mania.
I agree that Steve Blank needs to talk more about lean success/failure criteria and an exit strategy. If you've used lean to build a smallish business you need to leave it behind and go look for something else. This is challenging logically (how do you know if it's too small?), psychologically (given the sweat put into it) and financially (revenue is revenue after all and you get attached to it especially if you don't have other revenue to fall back on).
This is an alternative to building out like mad something that you have no idea if anyone wants to pay money for, and then doing it again and again at great expense of time, money and morale. Think ".com" mania.
I agree that Steve Blank needs to talk more about lean success/failure criteria and an exit strategy. If you've used lean to build a smallish business you need to leave it behind and go look for something else. This is challenging logically (how do you know if it's too small?), psychologically (given the sweat put into it) and financially (revenue is revenue after all and you get attached to it especially if you don't have other revenue to fall back on).
He is bashing two strawmen:
1. Lean Startups aren't cheap startups
http://steveblank.com/2009/11/02/lean-startups-aren’t-cheap-...
2. Lean Startups aren't small startups.
Steve Blank based much of his methodology on his experiences running E.Piphany. E.Piphany IPO'd before reaching a 4 Billion dollar market cap:
http://news.cnet.com/IPO-Update-Kana-Communications,-E.pipha...
1. Lean Startups aren't cheap startups
http://steveblank.com/2009/11/02/lean-startups-aren’t-cheap-...
2. Lean Startups aren't small startups.
Steve Blank based much of his methodology on his experiences running E.Piphany. E.Piphany IPO'd before reaching a 4 Billion dollar market cap:
http://news.cnet.com/IPO-Update-Kana-Communications,-E.pipha...
Rich. I tried to distinguish between the ideas behind lean startups and the common perceptions of lean startups as portrayed in most startup blogs. It is the latter I was attacking, which is why I qualified the post at the end.
I enjoy Steve Blank's writings as much as the next guy, but will not take them as gospel. If you are going to quote the peak market cap during the bubble years you should at least note that it was mostly downhill from there, eventually being acquired for 330 million. As a CRM guy he obviously has a very strong opinion of managing your customers, but his own company could have been better-served in the long run by a stronger focus on the product development process than on the customer development process...
As someone who is very close to both of the topics he's discussing (bootstrapping and customer development), I'd like to point out something obvious that the author has apparently missed: they're not the same thing. You can raise money and do customer development, and you can bootstrap with your head in the sand and never talk to your potential customers.
The value of customer development is that it's a model for being more efficient with whatever resources you have as you search for a fit between your product and the market.
The value of customer development is that it's a model for being more efficient with whatever resources you have as you search for a fit between your product and the market.
Hi Ryan, I actually did point that out towards the end of the post. My problem is not with the ideas per se, but with the way people treat them in general. Most people equate lean startups with bootstrapping in the startup blogging world.
As far as I can tell, you do that yourself. You seamlessly switch from talking about Customer Development to lean startups to bootstrapping, as if you don't see the difference between them.
For example:
Since no one ever talks about the down side of the customer development approach...
...Capital is required to grow. I’m not aware of any $100 million companies built with a lean startup mindset...
...So if you can’t attract a lot of capital to your idea, one possible reason is that your idea sucks.
Sorry, but I really don't see the point you're trying to make.
For example:
Since no one ever talks about the down side of the customer development approach...
...Capital is required to grow. I’m not aware of any $100 million companies built with a lean startup mindset...
...So if you can’t attract a lot of capital to your idea, one possible reason is that your idea sucks.
Sorry, but I really don't see the point you're trying to make.
Hi Ryan,
If we are going to just play the game of pulling random sentences and saying they are all tied together and show some kind of logical connection to what we each are trying to argue, here are my two:
...The broader idea behind customer development is that you should get close to customers early...
...The broader idea behind a lean startup is that you should be capital efficient...
Your turn.
...The broader idea behind customer development is that you should get close to customers early...
...The broader idea behind a lean startup is that you should be capital efficient...
Your turn.
I think this is a good point:
Imagine you have an idea for a new type of hotel. Would you build just two rooms and see if people liked the general idea then, if they did build 15 rooms and if those sold build 40 rooms and then eventually 100? If so, you would end up with a building whose core infrastructure was not designed to make it efficient to service and run a 100 room hotel. That is what can happen with a lean startup. You could argue that once you prove a market then you can always go back and rebuild the thing from scratch when you have more resources, but that too isn’t really true.
It seems to me he is, in part, talking about the idea of "right sizing". But it also seems to me that part of the point of starting lean and using customer development is to develop the founders -- their skills in dealing with the customer, their understanding of the product and market, etc. This piece talks like it is about "the product" but towards the end makes this comment:
Lean startups can be attractive because they minimize your chances of failure. They allow you to string along a mediocre business for years while keeping your day job and justifying the whole thing by saying you are lean.
The above comment brings it back to development of the founder as an entrepreneur. Perhaps the author is struggling to understand what went wrong and doesn't quite know how to frame it -- which would make perfect sense because if he already understood it well enough to frame it well, the odds are good he wouldn't have made the mistakes he is frustrated by. He would have done something else (and made some other set of mistakes/discovered some other set of pitfalls).
Imagine you have an idea for a new type of hotel. Would you build just two rooms and see if people liked the general idea then, if they did build 15 rooms and if those sold build 40 rooms and then eventually 100? If so, you would end up with a building whose core infrastructure was not designed to make it efficient to service and run a 100 room hotel. That is what can happen with a lean startup. You could argue that once you prove a market then you can always go back and rebuild the thing from scratch when you have more resources, but that too isn’t really true.
It seems to me he is, in part, talking about the idea of "right sizing". But it also seems to me that part of the point of starting lean and using customer development is to develop the founders -- their skills in dealing with the customer, their understanding of the product and market, etc. This piece talks like it is about "the product" but towards the end makes this comment:
Lean startups can be attractive because they minimize your chances of failure. They allow you to string along a mediocre business for years while keeping your day job and justifying the whole thing by saying you are lean.
The above comment brings it back to development of the founder as an entrepreneur. Perhaps the author is struggling to understand what went wrong and doesn't quite know how to frame it -- which would make perfect sense because if he already understood it well enough to frame it well, the odds are good he wouldn't have made the mistakes he is frustrated by. He would have done something else (and made some other set of mistakes/discovered some other set of pitfalls).
Mz, actually, Backupify is still going strong. This wasn't a "where we went wrong" post. It was a "we built too short-sighted" post and now scaling is painful.
Sorry it made you feel defensive. Maybe you missed the fact that most of the posts before mine were quite harsh and critical. Compared to the remarks I was seeing before mine, I think my post was quite kind and evenhanded.
As for "short sighted", sometimes the best way to get to tomorrow is by making it through today. Growing pains are inevitable. It is not a question of "if" it hurts. It is a question of when and how. The things which smart tend to be somewhat personal and unique. What bothers you might not bother me and vice versa.
Peace.
As for "short sighted", sometimes the best way to get to tomorrow is by making it through today. Growing pains are inevitable. It is not a question of "if" it hurts. It is a question of when and how. The things which smart tend to be somewhat personal and unique. What bothers you might not bother me and vice versa.
Peace.
Steve gave a good talk on the "Past, Present, and Future" of the Customer Development model at the San Francisco Lean-Startup-Circle meetup this month.
Video here: http://www.justin.tv/s/XMP0tQg/clip/8cb0037e984e6a1f
Slides here: http://www.slideshare.net/sblank/customer-development-past-p...
It certainly is not a set-in-stone one-size fits all approach as many seem to believe but is very much in development itself.
Video here: http://www.justin.tv/s/XMP0tQg/clip/8cb0037e984e6a1f
Slides here: http://www.slideshare.net/sblank/customer-development-past-p...
It certainly is not a set-in-stone one-size fits all approach as many seem to believe but is very much in development itself.
I originally posted this comment on the blog post, but since it isn't going through, I'll add it here:
Sorry, but I don’t have any juicy arguments for you. I agree with most of the concerns you raised here. It would be foolish for any startup to build their business in the way you described in the hotel example. In my understanding of the suggestions put forward by those exploring the lean startup methodology, the point is to be lean, not starving.
If you have a repeatable sales model, based on actual customer activity, hell yeah… go for broke. It doesn’t make any sense to just grow a little bit. On the other end of the equation, it doesn’t make much sense to front load your sales and marketing team with a budget of $100million based on assumptions which don’t have customer actions to back it up.
All that to say, I don’t understand the point of leanstartup methodology as being cheap for the sake of being cheap. But rather, not dumping money and resources into aspects of the business which haven’t been verified by actual paying customers.
Sorry, but I don’t have any juicy arguments for you. I agree with most of the concerns you raised here. It would be foolish for any startup to build their business in the way you described in the hotel example. In my understanding of the suggestions put forward by those exploring the lean startup methodology, the point is to be lean, not starving.
If you have a repeatable sales model, based on actual customer activity, hell yeah… go for broke. It doesn’t make any sense to just grow a little bit. On the other end of the equation, it doesn’t make much sense to front load your sales and marketing team with a budget of $100million based on assumptions which don’t have customer actions to back it up.
All that to say, I don’t understand the point of leanstartup methodology as being cheap for the sake of being cheap. But rather, not dumping money and resources into aspects of the business which haven’t been verified by actual paying customers.
Customer Development's unspoken premise is that web startups are in a world where market risk, not technology risk, dominates. Its usefulness is that it focuses techies like me on mitigating those market risks.
The question on my mind is whether it's too much of a greedy algorithm that moves you towards a local maximum but discourages real audacity?
The question on my mind is whether it's too much of a greedy algorithm that moves you towards a local maximum but discourages real audacity?
Its not unspoken. If you actually read the book, he talks extensively about market types. So do most of the presentations. In fact, these guys are the first people to actually talk extensively about market types and how they effect strategy.
Excellent point. What we found is that the risk with Backupify is technology risk.
I don't mean any offense, but how is there any technology risk?
Unless there's something non-obvious about the way the site works, I believe I could duplicate the product in two weeks with less than $10,000.
That means it's almost all market risk, i.e., the risk is in whether there is demand for it, not whether you can build it.
Something that is 100% technology risk would be, say, a cure for cancer, a new type of filesystem that improves MySQL performance by 100%, or a solar cell that is 1000x more efficient than current solar cells.
There's no question that if you created any of those there'd be demand for them -- the challenge is in the creation.
Unless there's something non-obvious about the way the site works, I believe I could duplicate the product in two weeks with less than $10,000.
That means it's almost all market risk, i.e., the risk is in whether there is demand for it, not whether you can build it.
Something that is 100% technology risk would be, say, a cure for cancer, a new type of filesystem that improves MySQL performance by 100%, or a solar cell that is 1000x more efficient than current solar cells.
There's no question that if you created any of those there'd be demand for them -- the challenge is in the creation.
> "We punted on tons of key issues because we wanted to wait until we proved there was a market for our product. Once we realized there was much more of a market than we thought, we suddenly had to allocate a bunch of resources to customer support and bug fixes… things that we wouldn’t have needed at the same level if we had built a more robust and full featured product out of the gate."
flat out: you're doing something wrong. coding right is faster than hacking around. i guess that's what you are saying: at some point you have to redo all the previous buggy work you've done, and adding features is a nightmare, so all the "progress" you thought you were making was totally backwards.
i'm just surprised that "point" came to late in development. once you start having real customers, as opposed to testing an idea with gradually more tech-based mockups, how can you afford not to be doing things right? how you can make progress if every feature is introducing bugs? do you just ignore the bugs and keep pounding against the wall, brute force adding <crap> and trying to trick people into thinking everything is ok, keep the payments coming?
don't build your own grave. customers who expect to use your project for the long-view after you've built it require a REAL product. i sooooo wouldn't want to clean up after that mess.
flat out: you're doing something wrong. coding right is faster than hacking around. i guess that's what you are saying: at some point you have to redo all the previous buggy work you've done, and adding features is a nightmare, so all the "progress" you thought you were making was totally backwards.
i'm just surprised that "point" came to late in development. once you start having real customers, as opposed to testing an idea with gradually more tech-based mockups, how can you afford not to be doing things right? how you can make progress if every feature is introducing bugs? do you just ignore the bugs and keep pounding against the wall, brute force adding <crap> and trying to trick people into thinking everything is ok, keep the payments coming?
don't build your own grave. customers who expect to use your project for the long-view after you've built it require a REAL product. i sooooo wouldn't want to clean up after that mess.
The typical startup that's struggling to find some sort of product/market fit would happily inherit the problems mentioned here. I don't think the lean startup model is supposed to be a smooth sail to success. It's just an efficient method for finding traction; there is no guarantee what happens (good or bad) from there on.
I agree, like the commenters, that lean vs. raising money is a false dichotomy. However, there are some valid points in this post:
- You have to be careful with product quality. In a lean startup, because you prioritize market discovery over all else, you build a culture of people used to saying "Oh, that bug only affects 1% of customers, so we can ignore it.", even after you have found your market.
- It's hard to give up steady growth to make the kind of long-investments you know you'll have to do. IMVU had a culture of running quick A/B experiments and throwing away the loser without any deep analysis. We had gotten stuck in a local maxima with stalled business growth, and it took replacement of most of the management team to fund a six-month project to rebuild our client UI from scratch. In our case, this was absolutely the right decision. Funding anything for six months straight would have been impossible with our previous "lean startup" culture.
I, too, would like to see more discussion of lean startup edge cases. There is definitely a point where you transition out of the lean startup approach and into full-scale production.
I suspect it's very similar to the game industry's preproduction vs. production distinction: http://www.gamasutra.com/view/feature/3847/beyond_scrum_lean...
- You have to be careful with product quality. In a lean startup, because you prioritize market discovery over all else, you build a culture of people used to saying "Oh, that bug only affects 1% of customers, so we can ignore it.", even after you have found your market.
- It's hard to give up steady growth to make the kind of long-investments you know you'll have to do. IMVU had a culture of running quick A/B experiments and throwing away the loser without any deep analysis. We had gotten stuck in a local maxima with stalled business growth, and it took replacement of most of the management team to fund a six-month project to rebuild our client UI from scratch. In our case, this was absolutely the right decision. Funding anything for six months straight would have been impossible with our previous "lean startup" culture.
I, too, would like to see more discussion of lean startup edge cases. There is definitely a point where you transition out of the lean startup approach and into full-scale production.
I suspect it's very similar to the game industry's preproduction vs. production distinction: http://www.gamasutra.com/view/feature/3847/beyond_scrum_lean...
Good analysis and I agree with you on using custdev as a tool in your tool kit rather than follow it like a religion. Another point, Steve always talks about shortcutting the custdev process if you happen to be the SME on the subject. If you know lot about what customers want in a area because you have experience in then you can skip portions of it.
We’re building a start-up based on the lean principles. The reason is simple: none of us are ready to quit our jobs until we’re sure we have a winner. Call us cowards perhaps, but we have families to feed.
The problem will bulking up at the beginning is that no one will invest in your product if it doesn’t exist and you’ll never get started on anything. The lean approach encourages you to get off your butt and just do it.
For our situation the lean startup approach is working very well. We got a working product out the door very quickly and we’re learning a lot from our first customers. Plus we’re having a ball! [http://twegather.com]
The problem will bulking up at the beginning is that no one will invest in your product if it doesn’t exist and you’ll never get started on anything. The lean approach encourages you to get off your butt and just do it.
For our situation the lean startup approach is working very well. We got a working product out the door very quickly and we’re learning a lot from our first customers. Plus we’re having a ball! [http://twegather.com]
It seems to me that a central part of this argument is having "...suddenly had to allocate a bunch of resources to customer support and bug fixes...".
Building the smallest possible marketable product doesn't mean building a low quality product.
Building the smallest possible marketable product doesn't mean building a low quality product.
Building the smallest possible marketable product doesn't mean building a low quality product.
This strikes me as more than a little unfair. Anyone who's actually built and deployed software knows that customer support, bug fixes, and maintenance are practically guaranteed parts of the product lifecycle.
This strikes me as more than a little unfair. Anyone who's actually built and deployed software knows that customer support, bug fixes, and maintenance are practically guaranteed parts of the product lifecycle.
That is true. I think the core benefit of the lean startup thing is that you'll be debugging something that people actually want and are paying for rather than debugging something which may be released to an uncaring world 18 months from now, if it gets released at all.
With regards to his point about building a hotel whose core infrastructure doesn't support 100 rooms: I think, based on the dissatisfaction with having to support customers and the price point, that he is probably talking more about scaling per-customer interaction rather than scaling in a technical sense. Scaling in a technical sense is a) a nice problem to have, kind of like having to hold your pants up because the number of Benjamins in your pockets keeps threatening to tear them off of you (hint: buy a belt) and b) is largely a solved problem for sites with less users than most nation states.
So can the lean startup help you scale out of that CS issue? I think so. First, if you treat CS incidents/bugs/etc as things to be optimized away, constant small improvements will mean you get less and less CS incidents per customer as time goes on. (Find what gives people trouble. Fix it. Repeat. I get less than 1/6th as many tech support requests per sale now as I did when I started out.)
Second, if you find your current pricing isn't attracting quite the sort of customers you want, you can always change pricing for new customers. Grandfather in the existing folks at $4 a month, and then carefully consider whether you want to be serving the market that values their data less than they do a frothy Starbucks drink. "Charge more" fixes more CS issues than any other single solution. It also has some nice side effects, such as getting you more money.
With regards to his point about building a hotel whose core infrastructure doesn't support 100 rooms: I think, based on the dissatisfaction with having to support customers and the price point, that he is probably talking more about scaling per-customer interaction rather than scaling in a technical sense. Scaling in a technical sense is a) a nice problem to have, kind of like having to hold your pants up because the number of Benjamins in your pockets keeps threatening to tear them off of you (hint: buy a belt) and b) is largely a solved problem for sites with less users than most nation states.
So can the lean startup help you scale out of that CS issue? I think so. First, if you treat CS incidents/bugs/etc as things to be optimized away, constant small improvements will mean you get less and less CS incidents per customer as time goes on. (Find what gives people trouble. Fix it. Repeat. I get less than 1/6th as many tech support requests per sale now as I did when I started out.)
Second, if you find your current pricing isn't attracting quite the sort of customers you want, you can always change pricing for new customers. Grandfather in the existing folks at $4 a month, and then carefully consider whether you want to be serving the market that values their data less than they do a frothy Starbucks drink. "Charge more" fixes more CS issues than any other single solution. It also has some nice side effects, such as getting you more money.
Hi Patio,
As an example problem (I wrote the original post), we strongly suspected users wanted encryption of their backed up data. But when we talked with initial customers, there were certain things they wanted more that, when built, made encryption a slower, more difficult process to implement. We punted on encryption because, for the first 3 months we were in the market, there was a little demand, but not much. Then as we hit more mainstream blogs and publications and got a wider user base, encryption shot to the top of our list. So what we learned is that our first 500 customers weren't very representative of who would ultimately use the product and we shouldn't have catered to them so much. We really should have paid less attention to early customers, and more attention to related markets like PC backup, and assumed they had already figured out what the market wanted.
What about the customer development methodology urged you to make poor architectural decisions?
The author is completely missing the point of lean and minimal viable product. His assertion that Google would only be a "small search player" if they'd gone the lean startup route is way off, because Google already had their MVP built by the time they took their VC money. There's nothing wrong with taking money to accelerate business growth; it's just dangerous to have unlimited resources up front when you're still trying to figure out what the market wants.
According to the lean startup presentation given by Eric Ries at Web2.0 expo, (http://www.web2expo.com/webexsf2009/public/schedule/detail/7...) one key point is to "1. Identify a profitable business model faster and cheaper than your competitors." Google took VC money without having a clear revenue model at the time. So I would argue that they weren't a lean startup.
And anyway, I would say MVP and lean startup are different but related concepts.
And anyway, I would say MVP and lean startup are different but related concepts.
I would argue Google had identified the profitable business model, but needed VC money in order to implement it effectively. Their minimum viable product (their search technology) was already developed at that point.
I agree that MVP and lean startup are different but (very closely) related. (Specifically, you can't have the latter without the former.) But what's your point?
I agree that MVP and lean startup are different but (very closely) related. (Specifically, you can't have the latter without the former.) But what's your point?
Why is no one addressing the key issue that "customer development puts you in constant short-term thinking mode."?
Because short term thinking mode is the mode you SHOULD be in until you have something people want? That cycle is not long - get out there and see if people are interested. Dying for it? Proceed to next step. Not dying for it? Iterate.
So many years of productive lives are wasted building things nobody wants by bypassing that short term period.
So many years of productive lives are wasted building things nobody wants by bypassing that short term period.
The customer development model is a tool to help you find a market (actual paying customers) for your idea. It is not a growth strategy.
It helps with the early part of the TALC (Technology Adoption Life Cycle). It is a tool to help you find early adopters and early customer segments that allow you to Cross the Chasm.
One of the hardest things about managing TALC is knowing where you are in it. I think maybe you managed to find an early market but didn't shift your operational strategy & tactics to reflect your progress.
I would suggest you read Geoffrey Moore's Crossing the Chasm and Inside the Tornado. They are very, very good books. I read them over 10 years ago and haven't found them to be wrong yet.