Ask HN: How did you find the problem your product is solving?
I run a site about Health Savings Accounts[0]. Each year that you have contributions or distributions in your HSA, you have to file tax form 8889 to report these to the IRS. The form is overly complicated with pages of instructions so I wrote a blog post on how to complete it. A reader wrote me requesting help and, importantly, offered to pay me to fill it out for her. I thought it over and considered opening a tax service to fill these out for people. I didn't want to spend my days filing people's taxes one by one so declined, and instead programmed it and launched EasyForm8889[1]. It is an online service that asks simple questions and completes the tax form for you.
You should work on a product that solves YOUR problem instead of making a product than determining the problem that it is solving.
This is a very common sentiment and is echoed almost everywhere startup related. You can read PG's essays on the matter or watch some Startup School videos.
I understand you may already have a product so hopefully others can give you more advice.
> You should work on a product that solves YOUR problem
I think this popular advice is flawed. It's survivorship bias in advice form.
If you happen to have a good profitable problem you go solve it and become successful and then turn around and say "Look! I solved my own problem".
There exist many people whose own problems are terrible for turning into a product for many reasons. They would be better off if they attempted a more practical problem that was not necessarily their own.
I also see founders reverse-engineering their story to mask the fact that they just went after a feasible profitable idea.
For example they create a customer support software (as an example of a crowded competitive field).
But because it's not sexy to not have a dreamy story they manufacture some forced story line like "We were running this small consultancy company and needed customer support software. After trying tens of existing solutions we just weren't happy with their X,Y,Z so we decided to solve our own problem for good!".
From the looks of it, OP has a product and they does not know the problem it solves. Anyway you slice that - regardless of how "cliche" solving your own problem is - is a problem.
Edit 2: Addendum to above: Even with the suggestion you've made, that assumes you know the problem BEFORE you have a product. OP has a product.
But yes. OP, if you combine both of these 2 cents, your 4 cents would be: Know the problem before you have a product not the other way around :)
Edit 1: Also, note that there are new set of biases to worry about in the approach you have pointed out; does not make it invalid, but you also have to be careful there.
You don't.
First you find a problem, then solve it. Go read everything on https://stackingthebricks.com/
(I've been there. Built a product. Talked to potential users to try to find a problem it would solve, they talked about their problems. We ignored those problems, focused on our technology instead. Far far better to find the problem first, and then build a product.)
A little warning stackingthebricks is a semi-advice site designed to get you to need the rest of the advice, buy buying the course. Which isn't cheap.
I learned enough just reading the free stuff to make a product with revenue. But yes.
You're like the physicists that stayed in the casino, then. :-)
FWIW I don't think he's asking how to find a problem that his already-built solution solves.
He's asking how people found the problem they ended up working on.
The problem I found was/is an industry paying people do create X analysis/report routinely. I wrote an app to do this in the browser using new APIs. So I know the industry, the people who need and use these reports and the complexities and costs in making them. I found this opportunity by automating part of my day job.