I’m curious how other builders here discover real problems before building a product.
Do you usually start from your own pain point, customer interviews, Reddit comments, market research, or just build and test?
I’m trying to get better at finding problems that people actually care about, not just ideas that sound cool.
Would love to hear your process.
I’m exploring a B2C workflow/tooling problem and trying to figure out whether it’s a real pain point or just something people complain about but tolerate.
The area I’m looking at is the manual overhead around software developers updating their Jira/Linear, worklogs, status updates, sprint hygiene, etc. My instinct is that a lot of teams find this tedious, but I’m not sure whether it’s painful enough that they’d actually adopt a product to fix it.
For founders who’ve built or validated internal tooling / B2C workflow products: how do you test whether something like this is worth building around?
What signals do you look for ? time wasted, frequency, teams already hacking together automations, willingness to trust automation, or whether the actual buyer is engineering leadership / ops / PM rather than the dev doing the work?
Would love to hear how people here think about validating this kind of problem before building too much.
I have been a CTO and technical founding engineer at a couple startups for the last few years, mostly building other people's ideas. finally want to do my own thing but i'm stuck on something kind of embarrassing for an engineer: i can't pick what to build.
the building part doesn't scare me. it's the "what" that's killing me. b2b, b2c, ai stuff, some vertical niche thing, micro saas, boring-but-profitable... they all sound fine when i think about them for five minutes and then fall apart when i think about them for ten.
honestly being technical makes it worse. "can i build it" filters out nothing because the answer is always yes. so i've got no constraint forcing a decision.
couple things i keep flip flopping on:
do you build in a space you already know well, or go where the money is even if you're an outsider? and is "i personally have this problem" a real signal or just me rationalizing something convenient?
mostly though i want to know how people actually validated before committing months. not the lean startup textbook version, like what did you really do. did you talk to people, did anyone actually pay, did you fake a landing page, what.
curious what ideas people killed and why too, that's probably more useful than the ones that worked.
Something's been stuck in my head and I'd love to hear from people who've actually been through it.
Even if you can build something really cool, but if no one sees it, no one uses it. So you need an audience.
Everyone says, "Build an audience before you launch."
But if you're just starting out... how do you actually do that?
If I tell people I'm building a startup, why would they care? There are thousands—probably millions—of people building something. At that stage, your only USP is that you're building, but so is everyone else.
So I'm curious about the founders here who managed to make it work.
How did you get your first audience?
I'm building a platform where founders and product teams can discover and validate real SaaS problems before deciding what to build.
The challenge I'm thinking about is the cold start.
I don't want to launch with an empty database, but I also don't want to invent problems myself.
If you were starting from zero, how would you get the first 10–50 genuinely valuable problems?
Some ideas I've considered:
If you've built a marketplace or community before, how did you solve this?
Where would you look first for high-quality, recurring business problems that founders would actually pay to solve?
I'm not looking for startup ideas—I want repeatable ways to find real customer pain points.
I'd appreciate any advice or examples from your own experience.