The basic question haunting most startups is “are they building something people want?” Paul Graham said if you want to know why startups fail you should observe what those failed startups do. And it turns out the failure primarily results from making something nobody wants. If this question is so important as life and death of your startup, it is worth giving some thought. There are basically three approaches that successful startup founders have taken to make sure they build something people want.
Approach #1 : Build for yourself
This approach assumes that you are a typical user and what you are building is a product you will want to use. This reduces the problem of finding what to build to whether there are people like you out there or not. And chances are that there are. This approach has shown considerable successes (read Facebook and Google) and is pretty decent way to get started with an idea. All you need to do is ask : Would you love to use it if it weren’t your startup?
Downside : The above question assumes that you know how you would behave if it weren’t your startup. But fact of the matter is it is highly likely that you don’t. For two reasons : One, it is your idea and ideas have natural tendency to command inclination of the person who gets it. And two, it is fairly difficult for anyone to know how one would behave in a purely hypothetical situation (in this case : if it were someone else’s idea).
Approach#2 : Go lean
This approach assumes that there is no way of knowing what people want without validating it with experiments. At least, in making decisions about what people want, you best bet is to run experiments as cheaply as possible to really learn how people would behave in the hypothetical situation you are are trying to create through execution of your idea. Luckily you don’t actually need to execute upon the idea to learn that. If you goal is merely to learn you can do that in whatever way you can to get the users close to the hypothetical situation you are proposing. This approach means you don’t even have to build product unless you have learnt well about your users through experiments.
Downside : This approach is useful in a scenario when there is extreme uncertainty. It deviates your attention from actually building your product to learning about users, which is good because building a product nobody wants is a form of waste. But if you have figured out what users want “trying to run experiments” is a form of waste as well.
Approach#3 : Build for existing market
This approach is fairly simple. (Disclosure: this is what we have been following in our startup : Meedo). This approach is somewhat less discussed in today’s scenario (but existed even before the time there were no lean startup or even tech startups). At its heart, the approach entails building something that users are already using. This is determined by the existence of products that people are using. Yes, it means you will have competitors but it also means that there is a market already and people want that kind of product. Ideally you would want to build a product in a space that has no market leader yet (More on that later). So the question of what to build is already figured. In this case to win among your competitors the one and only thing you need to do is ensure that the cost of switching to your product is less than the added perceived value that user thinks he will get out of your product. This means that users should be able to switch to your product without loosing anything in the process (and ideally, gaining something). This explains why you couldn’t possibly build a winning social network even though there is a market or for that matter, any other product category which has a market leader. Simply because the cost of switching for users is just too much to be compensated by the additional features you might be hosting in your service.
That leads to the final question of how do you differentiate substantially that Added perceived Value > Cost of Swtiching . That can be done primarily by :


