In my post last week, I wrote that I intended to build a more complete landing page for my product with an eye toward collecting credit card numbers of a few prospects who have said they would pay for the product.

This technique of trying to collect credit card numbers before building a product is becoming more popular amongst startups following the 'Lean' methodology. It helps validate the hypothesis that a paying market exists for a given value proposition.

However, I am beginning to think that these types of techniques may be applicable to only a certain set of Internet startups. And I don't think that my startup is on that list.

The essence is that my startup is focused on a niche market, is being bootstrapped, and has no intention of taking venture capital. In fact, I don't think my market is large enough to attract venture capital in the first place.

So while being 'Lean' applies to all startups, the specific techniques one uses should be based on the type of startup you are doing. In this post I will elaborate my thoughts on how 'being Lean' looks in the case of my bootstrapping startup.

For me, being lean means essentially two things:

  1. Treating all the components of your business model as a set of assumptions.
  2. Testing those assumptions through conversations with customers.

In the limit, one could live true to these tenets by running online advertising campaigns against fake landing pages in order to collect credit card numbers: this is probably the most measurable, repeatable, and scalable way of testing the components of your business model without investing in product development and engineering.

The 'conversations' here are anonymous and users speak with their clicks. Cold hard numbers don't lie after all, do they? I think it's a great idea as far as it goes.

But I'm not sure how far it goes for bootstrapping startups building products for niche markets, who have an exceptionally low burn rate, and exceptionally short development times.

First of all, your customers aren't so anonymous in a niche market. If you aim to have only thousands of customers (as opposed to millions), the equation changes. Further, if these customers are part of a close-knit community (as they usually are in niches), then word of mouth becomes an increasingly valuable channel for reaching these customers.

Hence for a niche market, even a few bad experiences (where people enter credit card numbers only to be told the system is not ready) can count for a lot. Not only because you have probably lost those customers forever, but also because each one of them could have realistically brought you many more.

Second, for niche markets, hands-on marketing is increasingly viable. For instance, my startup is aimed at music students. I am part of a vibrant musical community in the Bay Area and so I have access to literally 100's of students. Many of them have already agreed to test the first version of my product. Further, it is reasonable to expect that if my product solves their problem well, then they will spread the word about it to their friends.

But I cannot leverage this resource without a product. Yes, hands on marketing of this type is not scalable. But again, if the target market size is in the thousands and not in the millions, then you don't need highly scalable channels.

Hands-on marketing and word-of-mouth also work for bootstrappers whose burn-rate is fairly low . Thus we can wait longer for a product to gain traction without feeling rushed. For instance, I am a designing and building my product my self. I don't have an office. My only costs are those of my apartment and whatever I will pay for the hosting infrastructure of my product (ie. my AWS bills).

Third, building a product quickly and taking it from there works very well if the development time for the product is low. With open-source web-app frameworks like Ruby and Rails, jQuery, 960grid, the Amazon cloud, etc., the development times can be really short when scale is not an issue. In my case, I think it is possible to have a functional minimal product out in 4-6 weeks. This makes it less attractive to spend time testing hypothetical value propositions. I would rather put the product in the hands of people who I know feel the need for it (because they have told me so), and then take it from there.

Finally, for bootstrapping startups, the lifetime value of each customer paying a monthly subscription fee is much higher than startups who are looking to monetize eyeballs. Hence building tailored solutions becomes critical. And you can only build tailored solutions by putting things in peoples' hands and watching them use it. Numbers and data can only go so far in helping you design for a niche audience.

* * *

It is for these reasons that I have chosen to pull out all the stops and get a working product out by the first week of September. I will release this product to 4-5 people, and then use that to drive the next iteration of development. And then I will release that iteration to a wider circle, and so on and so forth.

In this way I will keep my iterations short (4-6 weeks each), and learn through direct conversations at each step. And I think that is about as lean as one can get.