

The Dark Side of Customer Development and Lean Startups - icodemyownshit
http://coconutheadsets.com/2009/11/28/the-dark-side-of-customer-development-and-lean-startups/

======
apinstein
Customer development is kind of faddy at the moment, and you are right that
you can't get too extreme with things, but frankly in this case I think you're
just doing it wrong.

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.

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

------
richcollins
He is bashing two strawmen:

1\. Lean Startups aren't cheap startups

[http://steveblank.com/2009/11/02/lean-startups-
aren’t-cheap-...](http://steveblank.com/2009/11/02/lean-startups-aren’t-cheap-
startups/)

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...](http://news.cnet.com/IPO-Update-Kana-
Communications,-E.piphany-soar-in-debuts/2100-12_3-266199.html)

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

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

~~~
robmay
According to the lean startup presentation given by Eric Ries at Web2.0 expo,
([http://www.web2expo.com/webexsf2009/public/schedule/detail/7...](http://www.web2expo.com/webexsf2009/public/schedule/detail/7789))
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.

~~~
nkohari
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?

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

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

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

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

------
gcheong
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...](http://www.slideshare.net/sblank/customer-development-past-present-
future-steve-blank-111909)

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.

~~~
richcollins
Better video here:

[http://steveblank.com/2009/11/23/customer-development-
past-p...](http://steveblank.com/2009/11/23/customer-development-past-present-
future/)

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

------
petewarden
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?

~~~
robmay
Excellent point. What we found is that the risk with Backupify is technology
risk.

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

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

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

------
chadaustin
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...](http://www.gamasutra.com/view/feature/3847/beyond_scrum_lean_and_kanban_for_.php)

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

------
chrisjschmitt
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>]

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

~~~
_pius
_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.

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

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

~~~
rjurney
What about the customer development methodology urged you to make poor
architectural decisions?

------
robmay
Why is no one addressing the key issue that "customer development puts you in
constant short-term thinking mode."?

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

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

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

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

