I get what you're trying to do. Let me also suggest something different -- instead of tackling things from the solution end (software), why don't you immerse yo

I get what you're trying to do. Let me also suggest something different -- instead of tackling things from the solution end (software), why don't you immerse yourself into a few verticals (in whatever ways you can -- job, conference, connections, etc.) to really understand the unsolved problems without presuming a software solution? Don't be afraid to work on problems where the solution might not be a software solution. Also you need to have experienced the problem yourself in order to have skin the game. (This was one of the take-aways from an IDEO design thinking workshop I attended — you have to find ways to empathize with the user you’re designing for) Chances are a software solution will likely emerge anyway (in this day and age, everything runs on software), but by focusing on solving the problem, you ensure your solution has value, and you're not just trying to find a use case to write software for. Understanding the problem domain prior to presuming the solution space almost always works better than the other way around. (speaking as someone who has tried the approach problems from both ends in a non-tech field) The latter usually results in products that have no flair and no market uptake. Tobi Luetke started out trying to sell snowboards on-line but didn't find any suitable eCommerce software so ended up writing what eventually became Shopify.