I'm probably going to be one of many who will say that you should pick a pain you're already having and try to solve it. It's the only way you'll know exactly what to build and how to build it.
The more you try this the easier it will become, and after a few failed attempts you'll know how to get from the "new idea" to a finished product. Yes failed attemps, it'll probably take a while until you learn which things are worth building and which aren't.
Don't be afraid to be very specific. Pick a niche problem, don't try to build a solution that fits everyone. Just go after one specific use case and do it right.
You can try solving someone else's problem, or a problem you see in the company you work for, or a problem your customers are having. But be sure to understand the pain you're trying to solve, feel the pain, you need to know why are you building this thing. Don't just do it because it is cool, do it for a reason.
I completely agree with picking a pain that you are experiencing and try to solve it.
In addition to the pluses mentioned above, solving a pain you experience means you will be in a position to "dog-food" your own solution. This is obvious but worth reiterating. If, for example, you solve a problem that people other than you have, then you will not be using your own solution, and this is likely to lead you astray.
Having said that, be careful about being too "niche" or too personal with your solution. After you have come up with a problem you would like to solve for yourself, and you have ideas on how to solve it, go out and ask others:
- do you have this pain?
- how bad is it?
- if someone offered solution X for Y dollars, would you consider it?
- what would be some of the requirements and hangups that will keep you from adopting solution X?
In other words you don't want to solve your pain and then find out nobody else perceived the same pain in the same way. That's a one-way ticket to the deadpool.
One problem with this approach is we, developers, have different problems then a majority of the population. That's why a lot of SaaS apps are geared towards developers & their problems. Take this advice one step further, try to identify pain points your non-techy friends constantly have and solve those.
Comments
I'm probably going to be one of many who will say that you should pick a pain you're already having and try to solve it. It's the only way you'll know exactly what to build and how to build it.
The more you try this the easier it will become, and after a few failed attempts you'll know how to get from the "new idea" to a finished product. Yes failed attemps, it'll probably take a while until you learn which things are worth building and which aren't.
Don't be afraid to be very specific. Pick a niche problem, don't try to build a solution that fits everyone. Just go after one specific use case and do it right.
You can try solving someone else's problem, or a problem you see in the company you work for, or a problem your customers are having. But be sure to understand the pain you're trying to solve, feel the pain, you need to know why are you building this thing. Don't just do it because it is cool, do it for a reason.
I completely agree with picking a pain that you are experiencing and try to solve it.
In addition to the pluses mentioned above, solving a pain you experience means you will be in a position to "dog-food" your own solution. This is obvious but worth reiterating. If, for example, you solve a problem that people other than you have, then you will not be using your own solution, and this is likely to lead you astray.
Having said that, be careful about being too "niche" or too personal with your solution. After you have come up with a problem you would like to solve for yourself, and you have ideas on how to solve it, go out and ask others: - do you have this pain? - how bad is it? - if someone offered solution X for Y dollars, would you consider it? - what would be some of the requirements and hangups that will keep you from adopting solution X?
In other words you don't want to solve your pain and then find out nobody else perceived the same pain in the same way. That's a one-way ticket to the deadpool.
One problem with this approach is we, developers, have different problems then a majority of the population. That's why a lot of SaaS apps are geared towards developers & their problems. Take this advice one step further, try to identify pain points your non-techy friends constantly have and solve those.
Great idea! Thank you so much. Now let's create some problems.