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