Most founders start with this question:
“What should I build?”
The better question is:
“What problem am I solving, and who actually feels it?”
Because a startup without a clearly defined problem usually ends up doing this:
Ship → wait → silence.
Then you start tweaking:
• landing page
• onboarding
• pricing
• features
But the real issue is usually simpler.
You never defined who the product is actually for.
Here’s a quick exercise I recommend to founders before building anything.
Take 5 minutes and write down these two things:
1. The problem
Write the exact sentence a potential customer might say.
Example:
“I’m tired of manually searching Reddit and Twitter for people asking for tools like mine.”
2. The customer
Describe the specific person who feels that problem the most.
Example:
“Solo founders launching SaaS products who need early users.”
Once you do this, something interesting happens.
You can suddenly recognize those people in the wild.
You start noticing posts like:
“Anyone know a tool for finding startup leads?”
“Where do you guys find early SaaS customers?”
“Is there a way to detect buying intent on Reddit?”
Now the startup isn’t theoretical anymore.
You can see the problem happening in real time.
That’s actually how LeadSynth started.
I kept seeing founders manually hunting for these conversations across Reddit, X, and Indie Hackers.
So instead of manually searching, I built a system that detects those conversations automatically.
Now founders wake up to a list of people already asking for the solution they’re building.
If you’re working on something right now, try the exercise above.
Write down:
The problem sentence your customer would say
The person who feels it the most
Then go see if those conversations exist online.
You might be surprised how often the demand is already there.
If you want help finding those conversations, that’s exactly what LeadSynth does.
You can check it out here:
Or feel free to DM me if you want help defining your problem + ICP.
This is a great framework. Defining the problem in the customer’s own words is probably one of the most underrated exercises founders can do.
One thought I’ve been playing with though: sometimes the challenge is not just identifying the sentence a customer would say, but understanding whether that sentence represents a real “pain” or just a mild inconvenience. People say things like “I wish this was easier” all the time, but they don’t always mean “I’m willing to pay to solve this right now.” So maybe there’s an additional question after defining the sentence:
How often does this problem appear in their daily workflow, and how costly is it for them to ignore it? When both frequency and cost are high, that’s usually where the real opportunities appear.
That is a great way to look at it. Frequency and cost are usually the two strongest indicators that a problem is real because if it happens often and ignoring it creates friction or lost time people eventually start looking for solutions. When you see that pattern repeatedly in conversations it usually signals a much stronger opportunity.
This is exactly what I am figuring out right now! I am 17 years old from Kerala India validating my first startup CompeteIQ while studying for my board exams. The fastest signal I found was asking one simple question — are people already spending money on an imperfect solution to this problem? If yes the market is proven and you just need to build something better. For CompeteIQ founders are already paying $3000 per month for enterprise tools like Crayon and Klue — but nothing exists for early stage founders who cannot afford that. That gap told me immediately there was money to be made. What is the single fastest validation signal you have found that tells you an idea will make money?
That is a strong validation signal. If people are already paying for imperfect solutions it means the pain is real and the market exists. For me another strong signal is seeing people repeatedly complain about the same problem across different communities because it shows both frequency and urgency.
Whoa - great idea. I am about to launch a SAAS product and this sound perfect for me.
FYI love the look and feel of your site (note on the landing page the floating header/toaster is covering some of your H1 title).
Do you think this will assist a brand-new startup/launch or is better suited to an established site/service/platform?
Either way I will be giving the 7-day trial a whiz.
Appreciate the feedback and thanks for pointing out the header issue, I’ll fix that. It actually works well for brand new startups because you can see people already discussing the problem and join those conversations early instead of waiting for traffic. Let me know how the trial goes.
Really interesting approach to lead generation. The idea of catching conversations when someone is actively describing a problem makes a lot of sense.
I’m currently building a niche fintech platform focused on helping Muslims discover halal financial products in the U.S., and one challenge we see is that the people who need these services often don’t know where to find them.
That is a really interesting space. In cases like that the conversations often show up as people asking where to find halal compliant financial services or discussing alternatives they trust. Surfacing those discussions early can make it much easier to reach people who are actively searching for those products.
This is a great way of framing it.
I’ve been experimenting with something similar recently — running simulated “focus groups” for startup ideas to see what potential customers might actually say about the problem and solution before building.
What surprised me is how often the feedback isn’t “this won’t work” but more like:
“I’d use this if it solved this specific problem instead.”
It really highlights how important the exact problem definition is.
That’s a great insight. Often the idea itself isn’t wrong but the problem definition is slightly off, and a small shift there can completely change how useful the product feels. Those “I’d use this if…” moments are usually where the real opportunity starts to appear.
This is the clearest framing I've seen. The hard part is getting step one right — writing the exact sentence your customer would say. Most founders guess it from inside their own head.
Better approach: find people already saying it. Scan HN/PH/IndieHackers for real complaints. That sentence already exists, posted by someone who's genuinely frustrated. Built DemandRadar to automate that daily scan. The demand signal is hiding in plain sight — you just need to read enough of it.
Exactly. The best problem sentences almost always come directly from users, not from founders guessing in isolation. Once you start reading enough real complaints across communities you begin seeing the same language and frustrations repeat, which is usually the strongest demand signal.
The willingness to pay test is the only one that actually counts. Everything before that is just market research with a built-in politeness bias.
The thing worth adding: how they tried to solve it before you is as important as whether they have the problem. If nobody has tried anything, the problem probably isn't painful enough yet.
Completely agree. The strongest signal is when people are already hacking together workarounds like spreadsheets, scripts, or manual processes because it shows the pain is real. When someone is already spending time or money trying to solve it, willingness to pay usually follows.
I like this framework a lot.
One thing I’ve noticed is that once a team clearly defines the problem and customer, you also start seeing patterns in how the product evolves technically. Features get added quickly because the demand is obvious, but the underlying system structure doesn’t always get revisited.
Over time that can make even simple changes harder than they should be.
Curious if you’ve seen that happen with founders using LeadSynth — where the product direction becomes clear quickly, but the technical side needs periodic cleanup as it grows?
Yes, that happens quite often. Once demand becomes clear founders move fast on features and validation, but the architecture does not always get revisited until things start slowing down. It is usually the tradeoff of moving quickly early and refactoring once the direction is proven.
That makes a lot of sense. It seems like that early phase is almost optimized for speed rather than structure — which is probably the right tradeoff when you're still proving demand.
I’ve been noticing something similar when looking at smaller SaaS projects: once usage starts growing, the friction from the original architecture shows up pretty quickly. What worked for the first version suddenly becomes the bottleneck.
I’m curious — when you see teams hit that point, do they usually handle it with gradual refactoring as they go, or do they sometimes reach a stage where a larger architectural reset becomes necessary?
Most teams try to handle it with gradual refactoring while the product keeps moving forward. A full architectural reset usually only happens if the early system was built around assumptions that turned out to be wrong after real users showed up. Tools like LeadSynth tend to surface user needs earlier, which helps teams validate direction sooner and avoid rebuilding large parts of the system later.
That’s a good point. Gradual refactoring tends to be the more realistic path for most teams once real users start shaping the product.
I’ve also noticed that the bigger challenge isn’t usually the refactor itself — it’s recognizing when the original assumptions no longer match how people are actually using the product. Once that gap appears, even small architectural decisions can start slowing things down.
Exactly, spotting that gap early is the hard part. Once real usage diverges from your assumptions, everything starts compounding in the wrong direction. That’s why getting those real user signals early matters, and LeadSynth helps surface that behavior sooner so teams can adjust before the system becomes a bottleneck https://leadsynthai.app
Yeah that’s a really important distinction. The refactor is usually solvable — the harder problem is realizing you’re solving the wrong problem now.
What I’ve seen is that the pain doesn’t show up all at once either. It’s subtle at first — a feature takes a little longer, a workaround gets added, something feels slightly off. But those small mismatches between assumptions and real usage start stacking until the system is quietly working against you.
That’s why those early signals matter so much. Not just what users are doing, but why they’re using the product in a way you didn’t expect. That’s usually where the architectural drift begins.
LeadSynth surfacing that kind of behavior early is interesting — especially if it helps teams catch those patterns before they harden into design decisions. Feels like the real leverage is in shortening that feedback loop, not just collecting more data.
Spot on. The "Ship → wait → silence" cycle is brutal and avoidable. I've learned with my 6 apps that talking to people who feel the problem before building anything saves months of wasted effort.
Completely agree. Once you start talking to people who already feel the pain the product direction becomes much clearer and you avoid building features nobody asked for. Those early conversations are usually the best validation you can get.
This resonates. I'm doing exactly this exercise right now with a product idea around ad quality analytics.
My problem sentence: "I'm spending $10K/mo on Google and Meta ads and I have no idea which campaigns are driving real engagement vs wasted clicks. The enterprise tools that could tell me start at $30K/year."
The person who feels it most: SMB advertisers and agency owners managing $2K-$50K/mo in ad spend who are stuck between free platform dashboards that don't show quality and enterprise tools they can't afford.
Once I wrote that down I started finding the conversations everywhere. PPC forums, ad ops communities, even former colleagues in programmatic revenue confirming the gap. The demand seems to be there but I'm still validating before building anything. Running a short survey right now to see if the pain is real enough that people would pay to solve it.
The part about recognizing people in the wild is spot on. Defining the problem clearly changed how I read every post in ad-related communities.
That is a great example of a clear problem sentence and ICP. If you are already seeing the same complaint appear across PPC communities and from people managing real budgets, that is a strong signal the pain is real. The next step is exactly what you are doing now which is confirming willingness to pay before building.
I’ve been thinking about this a lot recently. One thing I’m experimenting with is running synthetic focus groups for ideas to see likely objections before building. Curious how others here approach validation.
Interesting approach. I usually start by observing real conversations where people already complain about the problem because objections and alternatives show up naturally there. That tends to reveal both demand and what people currently use to solve it.
That’s a great way to frame it.
Many founders start with a product idea instead of a clearly defined problem.
I’m curious — did you notice that talking to potential users early changes how founders describe their problem?
Yes, a lot. Once founders start talking to real users the problem description usually becomes much sharper and more specific because they begin using the customer’s language instead of their own assumptions. Those conversations are also where you often discover the real pain points people are already discussing online.
Interesting idea.
I recently launched a small SaaS and one thing that helped was focusing on a very specific niche first.
Have you thought about targeting a specific user group?
That is a great approach and I completely agree. Early on it is much easier to get traction when you focus on one specific group that feels the problem very strongly. For LeadSynth that group has mostly been founders and small SaaS builders who are constantly trying to find people asking for tools like theirs online. Once you understand that niche well it becomes much easier to expand later into other segments that have similar problems around finding high intent customers.
This feels really great; it helps me a lot. Thank You
Np!
This is a great framework. One thing I’ve noticed while building infrastructure products is that the “problem sentence” often appears in very technical conversations rather than direct tool requests. People might complain about access issues, identity management, or security friction without realizing there should be a product solving it. Those conversations are often where the real opportunity starts.
That is a really good observation. In many technical spaces the demand signal is hidden inside complaints about workflows rather than explicit requests for tools. Someone might say “this setup is painful” or “why is identity management always such a mess” without realizing a product could solve it. Those conversations are often where the earliest opportunities appear because the pain is real but the solution is not obvious yet. That is actually one of the patterns I kept noticing while building LeadSynth, since many of the strongest signals show up as frustration in technical discussions rather than direct tool requests.
This exercise is deceptively simple but it's the one most people skip.
I came to this from an unexpected angle. I'm 58, a senior infrastructure engineer, made redundant when WPP absorbed my company after nearly a decade. Spent months in interviews getting quietly rejected — everyone was polite, nobody said the obvious reason.
It got to a genuinely dark place.
Then one morning I thought — everyone says AI is replacing people like me. What if I used it instead?
The problem sentence wrote itself:
'Serious DIY investors spend hours hunting for director buying signals that are sitting in public filings, hiding in plain sight.'
Two months later something real was live. At 58, using the same tools everyone said were making people like me obsolete.
The exercise works. I'm proof.
Has anyone else here built something from a place like that? Would love to hear your stories.
Jason that’s a powerful story and honestly a perfect example of why this exercise works. When the problem sentence is real and comes from lived experience, the validation step becomes much clearer because you can actually see other people describing the same pain. What you did with the director buying signals is exactly the kind of pattern founders should look for. One interesting thing I’ve noticed building LeadSynth is how many of those “hiding in plain sight” problems show up in forums and communities before people even realize they’re a market. Curious where you first started noticing those conversations when you validated the idea.
Thank you — that genuinely means a lot coming from someone who clearly understands the validation process deeply.
Your observation about problems surfacing in forums before people recognise them as markets is spot on — and honestly that's exactly how this started. I wasn't formally validating anything. I was just frustrated that the data existed publicly but nobody had made it scannable.
The conversations I kept seeing were in investing communities — people manually trawling regulatory filings, sharing spreadsheets, doing by hand what should take seconds. That was the moment I thought there's something here.
Less formal validation, more frustration reaching a tipping point.
How deliberate was your own validation process with LeadSynth, or did it follow a similar path?
Very similar actually. LeadSynth did not start from a formal validation framework. It started from noticing the same frustration repeatedly while founders were manually searching Reddit, X, and Indie Hackers for people asking for tools like theirs. After seeing that pattern enough times it became obvious the real problem was not lead generation itself but the time spent hunting those conversations manually.
Just looked at LeadSynth properly — the intent matching angle makes sense, finding people already describing the problem rather than cold blasting. The writing style matching is a smart differentiator.
Curious how you're handling the platform risk — Reddit especially has been aggressive about automated engagement lately. Is that a constant battle or have you found a stable approach?
And yes — the "noticed but not invented" thing seems to be the pattern. The best ideas feel obvious in hindsight precisely because the behaviour already existed.
Jason
One thing we focus on heavily is analyzing the user’s voice and context before generating a reply so the AI agents respond in a way that actually sounds like the person using the platform rather than a generic bot. The messages are also spaced out and written to fit the tone of the conversation so they land like a normal human response instead of a burst of automated spam. The goal is to help founders join conversations naturally where they can genuinely help rather than blasting automated pitches.
I’ve fallen into the “ship - tweak - why is no one buying” loop before. Defining the person hurts your ego a bit but saves months.
Even in infra spaces like Ovobox, it’s the same - not “we sell servers” but “privacy-focused devs who need stable boxes without drama.” Way clearer who that’s for.
Solid reminder. Most people skip this and then wonder why it’s crickets.
That’s a great example. “Privacy-focused devs who need stable boxes without drama” is already a much stronger problem sentence than just “we sell servers.” Once it’s that specific, you can actually start spotting those conversations in the wild because people describe the pain in similar words.
One thing I’ve noticed is that when founders get this level of clarity, they suddenly start seeing posts like “any privacy-friendly hosting?” or “tired of unreliable VPS providers.” Those are the moments where traction usually starts. That’s also the exact kind of conversation LeadSynth is built to surface so founders don’t have to manually hunt for them every day.
Thank you so much my mind is opened now
No problem!
This reframing hit home. "What should I build?" vs "Who actually feels this problem?" sounds like a small shift but it completely changes how you validate.
I went through exactly the mess you described — shipped, waited, silence — before I got specific. For n8nShip (what I'm building), the vague version was "people who want automation." Useless. The specific version was "founders who already know n8n but lose 30-60 minutes every time they need a fresh instance deployed." Suddenly I knew exactly where those people were posting and what words they used.
The exercise you laid out is basically what forced that clarity for me. Writing the exact sentence the customer would say is deceptively powerful — if you can't write it in their voice, you don't actually understand the pain yet.
Saving this post. The "see the problem happening in real time" part is what makes it actionable rather than just theory.
That’s a great refinement of the problem sentence. “People who want automation” is impossible to validate, but “founders who already know n8n and lose 30–60 minutes every time they need a fresh instance” is suddenly very searchable because you know exactly what language those people use.
Once it gets that specific, the validation step becomes much easier. You can literally look across communities and see where people complain about spinning up n8n environments or managing instances. That’s the moment the idea stops being theoretical.
That’s also the exact layer LeadSynth focuses on now — surfacing those conversations so founders can see the problem happening in real time instead of discovering it weeks later.
I think this is a really good point, especially about defining the problem first. A lot of founders (myself included early on) get excited about building features before validating that people actually care about the problem.
Something I’ve noticed while building a marketplace project is that the real challenge isn’t just solving a problem, it’s making sure both sides of the marketplace feel the pain strongly enough to adopt a new platform. You can build something technically solid, but if sellers don’t have inventory ready or buyers don’t see enough listings, the product can stall even if the idea itself is good.
Defining the customer and the exact problem early definitely helps avoid that trap.
That’s a great point, marketplaces make this even trickier because you’re effectively validating two problem sentences at the same time. If one side doesn’t feel the pain strongly enough, the whole thing stalls even if the product itself works.
One pattern I’ve noticed is that successful marketplace founders usually start by focusing on the side with the strongest, most urgent problem first, then the other side follows once there’s enough activity. When you start spotting those conversations where one side is actively complaining about the problem, it becomes much clearer where to begin.
That’s actually one of the reasons I started building LeadSynth in the first place, to help founders surface those conversations across communities so they can see where the pain is strongest before trying to solve both sides at once.
That makes a lot of sense. The two-sided problem is probably the hardest part of marketplaces because progress on one side often depends on traction from the other.
Focusing on the side with the strongest pain first seems like a really practical approach. Once one side starts seeing real value, it becomes much easier to attract the other side organically.
I’m curious when you analyze those conversations do you usually see the pain more often on the supply side or the demand side for most marketplaces? That makes a lot of sense. The two-sided problem is probably the hardest part of marketplaces because progress on one side often depends on traction from the other.
Focusing on the side with the strongest pain first seems like a really practical approach. Once one side starts seeing real value, it becomes much easier to attract the other side organically.
I’m curious when you analyze those conversations do you usually see the pain more often on the supply side or the demand side for most marketplaces?
From what I have seen it usually appears more on the demand side first because buyers are the ones actively asking for solutions or recommendations. Sellers tend to discuss the problem later once they realize there is real demand and an opportunity to reach those buyers. That is why many marketplaces focus on capturing demand signals first and then bringing supply to where the demand already exists.
This is a great way to force clarity early.
One pattern I’ve noticed building tools for founders is that a lot of products fail not because the idea is wrong, but because the problem sentence isn’t emotionally true for the user.
Founders often write something like:
“I need better analytics.”
But the real sentence the user feels is closer to:
“I have traffic but I have no idea why people aren’t converting.”
That small shift changes everything about the product you build and how you position it.
Curious if you’ve seen cases where the problem existed but the founder slightly misidentified the real pain, and fixing that unlocked growth?
That’s a great observation. The difference between the “founder version” of the problem and the “user version” is often where things break. “I need better analytics” is abstract, but “I have traffic and no idea why people aren’t converting” is emotional and urgent, which is what actually drives someone to look for a solution.
I’ve definitely seen cases where the core problem existed, but the founder was describing the symptom incorrectly. Once they started using the exact language people were posting online, the positioning suddenly clicked and traction improved. Those raw sentences from Reddit, forums, or IH are often the best source for that.
That’s also part of what LeadSynth surfaces for founders now — not just leads, but the actual problem language people use when they’re asking for help, which often ends up shaping the product and messaging.
This is a really good exercise.
I'm currently building Fly-Claim, a platform that helps passengers claim compensation for delayed or cancelled flights under EU261, and I realized something very similar while validating the idea.
The “problem sentence” I kept seeing online was basically:
“I had a delayed flight but I have no idea if I’m entitled to compensation or how to claim it.”
Once I started looking for those conversations in travel communities, Reddit threads, and forums, I realized they were everywhere. That made the problem feel much more real than just building something and hoping people would come.
Your point about spotting the conversations first is spot on👌
That’s a perfect example of a strong problem sentence. It’s clear, emotional, and tied to a moment when the pain is fresh. When someone’s flight is delayed and they’re unsure about compensation, they usually search or post immediately, which makes those conversations very visible in travel forums and Reddit threads.
Once you start noticing that pattern, the validation becomes much easier because you can literally see the demand happening. That’s actually the kind of signal LeadSynth is built to surface, founders spotting those real-time conversations where people are asking exactly the question your product answers.
The shift from "what should I build?" to "who actually feels this pain?" is the one that separates founders who iterate forever from founders who find traction. But there's a step I'd add between your two questions: what does the customer already believe about this problem? Because most people aren't searching for your solution, they're searching for relief from a symptom, and if your positioning doesn't match the language they use to describe that symptom, you're invisible even when the demand exists.
The exercise you describe is essentially the beginning of brand strategy, and most founders skip it entirely because it feels soft compared to building. I've worked with companies across different industries, and the pattern is remarkably consistent: the ones who struggled longest were almost always solving the right problem but describing it in founder language instead of customer language. The ones who grew fast had usually spent real time listening before they typed a single line of code.
One thing worth adding: those conversations you find online aren't just validation, they're your first draft of homepage copy. The exact sentence a frustrated person posts on Reddit is almost always better than anything a copywriter would invent. Screenshot them, save them, and use that language verbatim when you describe what you built.
That’s a really good addition. The belief layer is often what shapes the language people actually use when they describe the problem. They’re rarely searching for the “solution category,” they’re describing a symptom in their own words.
And you’re spot on about those conversations doubling as copy. The sentence someone writes when they’re frustrated on Reddit is usually far more honest than anything we invent in a brainstorming session. I’ve started saving those sentences exactly like you suggested and they end up influencing positioning, onboarding copy, even feature priorities.
That’s also one of the interesting side effects of LeadSynth. When founders start seeing those raw conversations consistently, they’re not just finding leads, they’re effectively collecting the language their market already uses to describe the pain.