What's the PROBLEM your product solves?
In the month that I've been here, I've been noticing a pattern in a lot of launches - strong demos, polished UI, clear outputs of "what it does."
But when I ask myself "What problem does this solve?" I sometimes have to dig for the answer. (I come by that thinking honestly - I've spent 33 years building and fixing businesses, so this is the lens I can't turn off.)
The products where the problem is obvious are the ones people actually buy - you see it, you go "oh, that's exactly my issue," and you're sold on it.
It also makes pitching easier. If you're clear on the problem, explaining your product to anyone - buyers, other makers, whoever - gets a lot simpler.
And it's a small tweak with a big payoff - naming the problem clearly in your launch messaging can be the difference between people scrolling past and people stopping to actually look.
Curious what others think: when you're checking out a launch here, do you look for the problem first, or does the demo/output usually sell you on its own?
Replies
I look for the problem/need first.
However, note that some products are solving the problem of a bad existing UX and user interface (think about the goal "to manage virtual private servers" and solutions — via the terminal VS via a cloud panel with a convenient UI), that's where the appearance of the user interface and its presentation matters.
@wvitalik Good point and a problem, no matter what it is, is still a problem. And I suspect that UX problems are very common. Building a solution is one thing for the developer, but making it easy to understand for the user (and non-developer) is quite another.
"Why does it take so long to sift through our database and find the video footage I need and edit it together?"
That is the problem we are addressing. But it is much more internal, for us to always remember and understand. For the user/customer the demo/output would need to sell.
@sean_mcfadden That's a real problem to solve and important internally, for sure. But you still want to include it in your messaging and demo - Prospects still need to know the problem you're solving for them. They may also not always understand what the root of the problem is - they're just focusing on a symptom.
@anna_ludwinowski I usually look for the problem first. A strong demo can make me curious, but if I can’t quickly understand who is struggling and what gets better after using the product, it feels harder to trust the value. The best launches make the problem obvious before they start showing features.
@alpertayfurr Exactly - if it's not clearly obvious, people will move on. Our attention spans are getting shorter - make it clear and capture their attention!
@anna_ludwinowski I agree you Anna, again Congratulations :)
TAM Network solves the keyword filter problem in hiring. a recruiter types react, typescript, aws. a builder who shipped exactly that but wrote frontend, javascript, cloud never makes it past the filter. the resume is a vocabulary test. the work is invisible. our fix is a receipt. one peer signs that the work shipped. one customer signs that it landed. the recruiter reads who signed off and what changed. not keyword strings. v2 launches aug 12.
@thenameisarian This isn't an area I'm well-versed so I'll default to you on this. The only thing I'd really make sure of is whether this is a genuine problem that affects how someone does their work. We want our products to be a must-have not a nice-to-have!
this is the right test. the must have moment hits in three places. one. the candidate side. in 2026 9 of 10 resumes filter on keywords not work. a candidate with the right work but the wrong words gets rejected at the door. that is a must have problem for the applicant. two. the employer side. 30 to 40 percent of new hires fail probation because credentials lied. each bad hire costs over 200k. must have problem for HR. three. the 92 percent of work that linkedin never covered. plumbers, nurses, electricians have never had a portable record. that is the most must have segment because the alternative is no record at all. when receipts replace resumes, all three solve at once. that is the wedge.@anna_ludwinowski
For Cova, the problem is specific: fitness apps plan your training as if you always show up at 100%.
They count reps and macros but have no idea of your actual state. Sleep 5 hours, take on work stress, have a heavy week outside the gym, and the plan adds weight anyway. You push through. A few weeks later you plateau or something gives.
Natural lifters past the beginner stage feel this more than most. The margin between enough stimulus and too much gets smaller the more trained you are. Beginners absorb almost anything. Intermediate and advanced lifters cannot.
The product answer is a daily recovery check-in and a plan that responds to what it finds. I built Cova around that one idea.
@oshylabs YES, this is exactly the kind of problem statement this thread is about! You've nailed the specifics and why-it-matters part. My only question would be: do intermediate/advanced lifters know they have this problem? Or do they just experience it as "I stopped progressing" and chalk it up to bad luck or genetics?
Because that gap [between diagnosing the problem and someone realizing they have it] can have a huge impact of the success/failure of a product.
@anna_ludwinowski Honest answer: most do not name it. They feel a stall and reach for the usual levers first, add volume, change the split, blame genetics or age. The recovery and fatigue angle is the last thing they suspect, because every app and influencer has trained them to think in sets and macros. So the job is not to sell a recovery solution, it is to reframe the stall they already feel: you are not undertraining, you are not recovering enough, and here is the signal you missed. Get that reframe right and the problem looks obvious in hindsight. Get it wrong and you are shouting about a problem nobody thinks they have. That gap you flagged is the whole challenge, not a detail.
@oshylabs That gap you flagged is the whole challenge, not a detail - honestly, that's the clearest I've heard anyone put it. Good luck with the reframe!
Problem-first, every time. For OsmO it's almost too easy to name because everyone feels it: your phone has quietly become a source of stress — spam and robocalls burying the calls that actually matter, plus the ones you dread making (the 40-min hold, rebooking a doctor, chasing a refund).
The wrinkle I didn't expect, though: for some problems people have given up on a fix existing. They've normalized the pain — 'phones just suck now, that's life.' When a problem is that normalized, naming it isn't enough; the job becomes giving people permission to expect it solved. 'Your phone can feel calm again' lands harder than 'AI call screening' — the first one challenges a belief they'd stopped questioning.
So my add: name the problem AND the resignation around it. The strongest launches don't just say 'here's your problem,' they say 'you were right to be annoyed — and no, you don't have to live with it.'
@getosmo Oh, yes, you've added the emotional permission layer, which is fantastic and the part I think most Founders miss. Naming the problem clearly is table stakes, but you're right, half the work is making people believe it's solvable again.
Another question to sit with though is: when does giving that permission potentially backfire? Like, is there a scenario where saying "you don't have to live with this" actually makes someone more defensive about their current workaround, or makes them feel judged for having accepted it? It's a delicate dance!
@anna_ludwinowski Great question — yes, it can, and the mechanism is a little brutal: giving permission to hope RAISES the bar from 'resigned' to 'expectant.' A resigned user who never hoped churns quietly. An expectant user you let down churns angrily — you didn't just fail, you broke a promise you talked them into believing.
So I treat the permission as a debt: only grant it for the part the product genuinely nails. I'm comfortable saying 'spam calls can finally feel handled' because that's rock-solid. I'm far more careful implying 'every call, perfectly,' because a miss there lands on trust I just manufactured.
Rule of thumb I've landed on: grant emotional permission only in proportion to what you can actually deliver. Over-grant and you don't create a customer, you create a betrayal; under-grant and you stay invisible. The art is matching the size of the promise to the size of the certainty.
@getosmo That's great - you're further along than many!
But that's the hard part too, right? Because the calibration is internal - YOU know what you can deliver, but the customer doesn't know if you're under-promising or being honest about the limits.
So when you say "spam calls can finally feel handled," how do you show people this? Do you have to be explicit about what won't change (like, "this won't eliminate all spam, but it will stop the ones that actually matter to you")?
Or does the product itself communicate the limits naturally through use? Because I think that's where most products mess up - they grant the permission but don't create a mechanism for the customer to understand the actual scope. So they either never believe it, or they believe it and feel betrayed when it's not a total fix. Neither of which is desirable.
@anna_ludwinowski Exactly the right place to push. Honest answer: don't communicate scope with disclaimers — nobody reads 'this won't eliminate all spam.' Communicate it through the product's first honest moment.
The mechanism that's worked for us: every action comes with a receipt. The AI doesn't say 'I handle your calls,' it shows you 'here's the call I just screened, who it was, and why I let it through or blocked it.' You calibrate from a real instance, not a promise. The receipt IS the scope.
The underrated half: the product has to admit uncertainty out loud. When it's not sure, it says so — 'I wasn't confident about this one, so I let it through.' Admitting a limit in the moment builds more trust than a flawless-looking result, because it teaches the real boundary without a caveat nobody believes.
So the mechanism you're after isn't messaging — it's transparency-by-default in the product: narrate every action, flag your own low-confidence calls. It turns 'trust me' into 'watch me, and judge for yourself,' and you can't feel betrayed by something that never over-claimed.
I can definitely relate to this with DeckPlan Pro. Everyone who's actually tried it has had great feedback and really liked it, but I'm still struggling to build a user base.
I think part of that is exactly what you mentioned. Early on, I focused too much on showing what the software could do instead of clearly communicating the problem it solves. Contractors waste hours doing takeoffs, quoting, and managing jobs across multiple tools. Once I started leading with that problem instead of the features, the conversations became much easier.
Building the product has been the easy part. Getting the right people to understand why they need it has been the real challenge.
@johnathan_branson Thanks for sharing this - you're most definitely not alone in this! I find tech and financial people tend to lean towards OUTPUTS (the nature of their businesses), but what Prospects want to see are the OUTCOMES from having used your product/worked with you.
If I'm struggling with X and I want to get to Y, how do I know your product/service is going to help me get there? If they can clearly see that outcome, literally everything else is secondary (the product, price, etc.). Glad you see how the conversations became easier as a result!
I look for the problem first, but the launches that actually stop me are the ones that name a pain I'd already given up on. Not a new problem, an old one I stopped noticing because I assumed that was just how it works.
I build a writing and preproduction tool for screenwriters, and the problem we solve is exactly that kind. Writers write blind. You type page after page with the whole film living only in your head, and you don't find out the structure is broken until you read it back cold, weeks later. Nobody complains about it, because everybody assumes writing is supposed to feel like that. So the hard part of our messaging isn't describing features, it's getting someone to go "wait, it doesn't have to be like this?"
That's the test I'd add to the thread. Not just is the problem clear, but did the reader already accept the pain as normal. If yes, naming it out loud does more than any demo. If they're actively hunting for a fix, the demo can carry the weight. Two different jobs.
@frank_houbre Yes, such a good addition to the conversation! You're right, these are two different jobs, though related. The ones who've given up and assume that's just how things are, need the sharpest messaging - it has to be crystal clear for them because you're literally bringing them back into the conversation. AND when you do convert them (they have a high conversion rate), they become your biggest advocates!
Your product sounds like a lifeline for screenwriters - how have those conversations gone?
the problem TAM Network solves: 92 percent of workers do not write code. they plumb, nurse, design, weld, teach, drive. none of them have a credential they can carry between jobs that a recruiter can verify.
linkedin gives them a title. the title is unverified and rented from the employer. when the employer is gone or never existed (early career, trades, career change) the candidate is invisible.
the receipt fixes that. one sentence about the work. the artifact. a peer who signs. a customer who countersigns. portable. verifiable. owned by the worker.
appreciate you holding launches to this question. it sharpens everyone.
@thenameisarian Thank you for participating! We need to look at the whole business - not just the products we're building - so we can get the right products in front of the right people who need them.
This resonates deeply especially as someone currently launching their first app.
When I started building Ritually (an AI habit coach), I made exactly this mistake. I was so
excited about the AI plan generation feature that my early messaging was all about the
solution "AI builds your habit plan in seconds!" But nobody cared. Because I hadn't clearly
named the problem first.
The moment I changed my messaging to "Most habit apps track your streaks but never actually
teach you how to build the habit" people immediately said "yes, that's exactly my
frustration."
Same product. Completely different response. Your 33 years of experience just saved a lot
of first-time founders from making the same mistake I almost made.
To answer your question problem first, always.
The demo is just proof that the problem is solved.
@innocent_fonkoa Yes, that simple shift allowed people to see themselves in your solution! I'm glad you saw that and made the change. And congratulations on your upcoming launch - have you got a date yet?