Lean Startup: Are You Building An Awesome feature That Nobody Will Use

The lean startup teaches a scientific approach to creatingLean Startup Methodology startups that are able to deliver the products to the customer quickly and also use relatively lesser resources in that process. Let's try to understand some of the concepts of lean startup mechanism in simple language. Let's start by looking first at what you should not be doing to create a lean startup.

Are you creating an Un-"Lean Startup"

You got an idea or maybe you saw a problem somewhere and thought of a solution. Then, you did some market or customer research (assuming you indeed did it) to validate the need of your solution and embarked upon the development of your solution. That's how almost all the startups get started.

But as the development starts, suddenly after few days that very solution that seemed marvelous in the beginning starts looking inadequate. So, you think of adding another feature to make it better. And then this cycle repeats after every few days of development, the solution would seems lacking something or the other and you would keep on adding another feature to make it complete. You are struck in the trap of building an awesome product for your startup.

And the most unfortunate part of this trap is that you tend to decide what's missing and what's more to be added, without any customer validation. Somehow the confidence of having a vision to come up with the core idea and its initial customer validation makes an entrepreneur believe that he is the best judge for any decision around that idea.

The results are prolonged development, a bulky product, lack of focus in your solution and an inability to do further quick experiments. All these things are disastrous for a startup and a recipe of guaranteed failure. So, let's see how an entrepreneur can avoid this trap and follow a better lean startup approach.

Shipment Over Perfection

Always give a priority to shipment of the product then building the perfect product. Based on your initial validated feature set for the product, work-out a practical deadline for your shipment or launch of your startup. This deadline should be the top priority then onwards. This rule will keep you away from adding any more non-validated features to the product. An entrepreneur ought to curb the fear of shipping an imperfect product. Although, it is also important here to understand that imperfect product does not mean that the feature you delivered doesn't work or breaks down often. Deliver less but deliver it well.

Let Necessity be the mother of invention

Once you have been able to stick to a deadline as mentioned above and deliver the product. You can move on to think of another set of features, but the question is how you use your already delivered core product for this purpose. Most of the times we tend to think of our core product as a flower bouquet base and then think of other flowers (features) that can be attached to it. And hence you might end up adding something, which is easy to add or goes well with your product, but unfortunately, not required by your users. It leads to wasted effort; a big no for a lean startup, in fact for every entrepreneur.

Instead, use your delivered product as a test bed to find out what additional features your users would want, you can use a feedback form, mailers, your website analytics or direct interaction with your users to know what additional they are looking for. Try to achieve these additional features, even if they do not seem directly or easily integrate-able to your product in the beginning.

An oxymoron: Manual Automation

It is understandable that it not that easy to know 'what people want' and sometimes the only way to find that out is to first offer them something and see if they liked it or not. These would be the cases where you can not eliminate the need of first developing a feature and then doing the validation.  But even in those cases, it is not necessary that you develop a feature completely just to discover that they did not like it. You can handle such situations by doing something that sounds like an oxymoron, Manual automation.

The idea in manual automation is to not develop the whole feature, and limit yourself only to a nice looking interface that enables your users to try and use this feature. But at the back-end you have manual tasks to offer that feature. For example if you need to give your users a button which triggers a transaction automatically. You can just implement a button, which would send an email to you when a user presses the button and then you can do the transaction manually.

Have you been into such a situation and used one of the techniques above or maybe some other technique that saved your effort on doing big developments in a startup. Do share that with us in a comment below.


Log in also lets you receive 'likes' and 'responses' to your comments.