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
Petio started with a problem I kept seeing in pet households: important context is scattered across food bags, messages, vet paperwork, and memory. A generic AI answer is not very useful if it does not know which pet, what they eat, or what was already recorded. We are building around one connected profile, then helping owners prepare clearer questions for their vet. The useful validation signal for us has been whether people return to add context, not whether they try one clever prompt.
Problem first, almost always.
A polished demo can get my attention, but the problem is what tells me whether the product actually matters.
With Ailin¹, for example, the problem we started from was very simple: most AI applications depend on a single model at a time.
That creates a single point of failure, bias, capability, pricing, availability, and judgment. Even the best model can be confidently wrong, unavailable, too expensive, or simply not the best model for a specific task.
That led us to explore a different architecture: instead of relying on one model, coordinate multiple independent models so they can reason, challenge, verify, and complement each other.
The product becomes much easier to explain once the problem is clear.
I think a useful test is: if you need to explain the feature before someone understands why they need it, the problem probably isn't clear enough yet.
Coding agents silently drop the context mid-task. Ours "rebuilt" an existing helper two files over with a new name. So we have two diverging implmentations to untangle) Plus the actual headache is managing cross-file awareness so they stop writing duplicate utilities...
the reason youre having to dig is usually that the real problem is embarrassing to say out loud. mine is that founders cannot tell the difference between people who like the idea and people who will actually pay, and writing it that way sounds like an accusation pointed at whoever is reading it. so the polite version goes on the page, and the polite version is always a feature description. the test i use now is whether the problem sentence would make one specific person slightly uncomfortable to read. ours does, and i still soften it about half the time anyway.
You've described the same problem I work on, from the other end. You're fixing the rep's time, I'm trying to stop the lead reaching the rep unqualified in the first place
Curious what your users say the real drop off point is. For us it was always the gap between interested and booked.
The cheapest fix I found for wrong fit leads wasn't better copy. It was making the page ask two questions before the calendar link shows up
The wrong people disqualify themselves and never reach your diary. Same traffic, half the meetings, twice the proposals
The repeatability test catches vague problems but it lets through a different failure: a problem that is real, repeatable, and too small to justify switching tools for. I ask a second question after the one line test, what does this person currently do instead, and how much does that cost them right now, in money, time, or risk. If the honest answer is "nothing, they just live with it," the product will struggle even with a crisp problem statement, because there is no active cost pulling them toward a fix. The launches I trust most name the current workaround by name, not just the pain, because that is the thing you are actually replacing.
Ours: product teams ship faster than anyone can document it. So the help centre runs six months behind, support answers the same question forty times, and nobody has time to record a walkthrough for every change.
We turn one screen recording into a video and a written doc in the same pass, so updating it isn't a whole project.
After a decade of building apps that didn't take off, I'm trying the approach of problem first.
I'm building these apps on the side of my real job and while that is not the typical founder way, the stability has allowed me to take a bit more time focusing on the problem.
The current app I'm building, Zenith, was a problem my wife was having with doomscrolling eating up time in her day.
It was a problem for one person but thats my approach now, problem first rather than a cool idea searching for a problem.
The nice thing of having the problem first is all your messaging, demo, screenshots can list benefits rather than the feature.
I think a nice analogy is to build something thats a painkiller than just a vitamin.