software, market-research, bootstrappingThis question might seem a little silly, but it is something I wonder if there are techniques to be done. I’m a physicist and a programmer and for some time now I’ve been looking forward to create some app which might be useful for people and generate a nice revenue so that I can really make this my work.
Now, although I have the programming knowledge to build the app, my main doubt has been on how to choose which app to build.
In other words, we write software to solve problems, so the point here is that if I want to build and start selling a software I need a problem to be solved. And this problem must be something which people are interested in.
The point is that I have not been able to see a problem that needs solving that hasn’t been addressed before. For some time I believe this was just a question of creativity: if I don’t have it, I don’t have it and there’s nothing that can be done. However, lately I’ve seem many new startups every month and so I wonder if there is some kind of research, some kind of line of thought that might lead to some problem that needs solving through software.
In that case, how to identify a problem that can be solved through the creation of some app? Is there some kind of research, line of thought or anything else that might lead us to find some problems that we can approach, so that we can select one to build an app?
Understanding of specific industry
To solve a problem, you must first find one. To find a problem in certain industry, you need to understand it very well or otherwise you have just assumptions of what problems there might be.
If you’re more of a developer kind, partnering up with somebody who’s area of expertise your going for can help a lot in idea validation phase.
Find pain points
As you get familiar with industry of your choice, you can see behaviour patterns in it. Mailman wakes up early, gets the papers, drivers around your neighbourhoods. These are usually things which are ‘always done like this’. Finding most time consuming or complex steps in these patterns can be possible pain points, that in your case technology could fix.
Understanding of behaviour
When you have your industry figured out and have found possible ‘painpoints’, you have to understand WHY people behave in a way they currently do. In many cases, possible solution you could offer is something nobody feels comfortable doing, as they don’t necessarily see the problem. Also, solving redudant problem isn’t attractive. Selling shoelaces that tie them up automatically is a novelty product, its not really that big of a deal to do it yourself.
Talking to people
The most important step, before writing a single line of code: Talk with people who could be your potential customers. Tell them how you see their work and what you could do to make it easier. Listen every word they say, and ask more detailed questions. Digging deeper and deeper will eventually make them say hell, if you could make an app like that, I would buy it right away! Repeat as many times as you can and you’ll have strong knowledge base of A. the real problem and B. customers who already love you.
Deliver
After you’ve found right market, pain points you can fix, customers loving your product, its time to deliver. Build only necessary features first, and iterate with early adopters. Test what works and what doesn’t, learn more along the road. Even the best ideas with bad execution and user experience end up in trash.
One approach is to go through freelance marketplace websites (there are several of them) and to make a list, in your own summarised words, of the general problem each client is trying to solve. In other words, go through the job listings, and for each job discern (a) what the client wants and (b) why the client wants it. Avoid getting into the details of the client's specific needs or the client's proposed (if any) method for solving the problem. After all, the postings are technically intellectual property. A summarising and generalising is necessary for legal and practical reasons. If you have a specific area (such as physics) that you are interested in, it could be useful to filter job listings by search term.
Afterward, once you have accumulated a fair-sized list, try to find patterns to see if there are any common problems being sought for solution. This can be important since uncommon problems are usually less likely to offer marketable potential and hence return on investment. If you can think of a way to solve multiple of these problems in one throw, that could have marketable potential as well.
Another approach could be to look at the Software Recommendations section here on Stack Exchange and see if you can find any requests which have not been fulfilled.
Also: Remember to check for existing solutions before trying to make your own. One thing you really do not want is to find after months or years of work that there is a strong competitor that you were unaware of. Asking the community whether a solution to the problem exists could also be useful -- if you are not afraid of letting out the idea (which usually has little value on its own).
The point is that I have not been able to see a problem that needs solving that hasn’t been addressed before. For some time I believe this was just a question of creativity: if I don’t have it
Where I live we say lófasz.
Look: for every 100 entrepreneurs I’ve met out there, maybe 1-2 had actually talked to their clients before beginning the journey to sell - or much worse, build. In fact, I’d gather about 95% never talked to clients before actually building anything. As in really anything.
Shocking, I known.
If it’s not to you, it should be. Getting customers solves 95% of your problems. Need I add anything else to that?
Perhaps this: go out there and talk. To everyone. Go to and interact with people at meet-ups. Use online forums. Try the likes of https://erlibird.com/ or what have you. Anything goes, as long you’re actively talking to end users.
As you do, probe your market for ideas and price points.
Did I mention that getting clients solve 95% of your problems?
Domain expertise is everything.
I have a surviving but not thriving software business. I spent 12 years between project manager, field engineer, and trouble shooter in three different companies in my field. I took mental notes of what was missing and put together a solid functional model. My software skills were only OK (at the time) but I learned what I needed and I wrote from scratch.
I applied it to a related domain and thought it would just be a slam on over. My re-sellers said no these customers do not think that way. They were right and the first release was not readily accepted and I had to quickly defer to the domain experts.
Take something like the simplex optimization. That has value you can build then sell.
Not sure if this is true but consider the firewall. I bet the person that come up with that idea had no trouble implementing.
The person that came up with Ethernet. I bet conception was harder than the execution.
This answer is an extension and illustration of Tom’s answer.
We can find about the “job to be done” type of approach that seems a clear guideline to answer what to do. But there is not magic here: This is a lot of work on communicating, investigating, well digging to understand what may matter.
A famous example was for milkshakes at a large fast-food chain. They tried for a long time to sell more milkshakes by making them more creamy, tasty, new flavours, new colour, etc. In the end, they tried the “job to be done” approach, and found concrete reasons why people were buying milkshakes. People were mostly car commuters and they had a large milkshake on their way to stay awake and counter boredom in traffic jams. Based on these findings, the chain chose to make the milkshakes easier to buy (vending machines to avoid queueing), thicker (so that drivers have to stay awake), and with fruit pieces inside (to randomly fight the boredom). Applying this thinking to various domains and then building software is an approach that works for me (at a smaller scale though). Check out the work from Christensen (well, the famous Innovator’s Dilemma author) for more on this.
Second, software can address a huge range of problems, and more every year—“eating the world” as Andreessen once said. So we can see that software may well be applied easily… where it is not applied yet. Education is a recent striking example. Over the past few years, education has started to change radically thanks to an increasing number of online resources, new ways of teaching and learning, mobile coaches, etc. All software. And guess who wrote a key book that triggered a lot of new startups? Christensen’s Disrupting Class…
I propose readers to loop back to Tom’s answer for a broader review of the question.
All content is licensed under CC BY-SA 3.0.