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
This is also one of the first things investors look for. A polished demo can attract attention, but if someone cannot quickly understand who has the problem, how painful it is, and why the current alternatives are inadequate, the conversation hits a dead end. Based on my own experience and a friend who works at 1752vc, the strongest pitches often make the problem feel inevitable before they spend much time explaining the product.
Problem first, always. A slick demo with no obvious pain reads as a solution looking for a problem.
The one we work on: companies accumulate happy customers much faster than they accumulate proof. A B2B case study takes 3-6 weeks of chasing, scheduling, transcribing, writing, and approvals, so most teams sit on hundreds of wins and publish three stories. StoryVoice collapses that: your customer talks to a voice AI for 5 minutes, and the publish-ready case study is written the moment they finish.
And you're right about naming it clearly. Leading with "proof shouldn't cost weeks" is what makes people stop scrolling, because they recognize their own backlog in it.
Problem first, always. The test I use on my own products is whether the problem survives being written as one specific scene.
The one I keep coming back to: a tenant in the UK reports mould, gets silence for months, and does not know that the wording and timing of their complaint letter decide whether the landlord can keep stalling. There is a formal escalation route with deadlines the landlord must meet, but it only works if the complaint is written and timed correctly. People lose winnable cases at the writing stage. I built ComplaintForge for exactly that moment, the letter you write after you have already been ignored once.
To your question, the demo only matters to me once I believe the maker has actually met the problem. A polished demo of a problem nobody has is a screensaver.
For me the problem needs to be clearly understood but it's often the demo that get's me to click on the product. That's why I think design and visuals are so important
Founders juggling more than one business spend most of their day just figuring out which fire is real. That's the problem, not lack of dashboards, lack of a filter. I'm the founder of FounderFlow, built it after running a software company, a care home and a cafe at once and constantly getting the loud-but-fake fire confused with the quiet real one. If I can't explain the problem in one sentence like that, I've usually built the wrong thing.
Strongly agree, and it's a useful gut-check. When I was prepping my own launch messaging, I kept coming back to: can someone read this in 5 seconds and go "yeah, that's my problem"? If not, the polish underneath doesn't matter yet.
For me the answer ended up being pretty literal — I was losing track of bills, subscriptions, documents, and appointments across a dozen different apps and notebooks, so the pitch became "stop letting life admin pile up." No abstraction needed, because the problem was just... my actual life.
I think the trap is that once you're deep in building, you start describing the solution in more and more detail because that's what you've been staring at for weeks. But the person scrolling past hasn't lived in your solution — they've lived in the problem, if they have it at all. Leading with the problem meets them where they already are.
To your question — for me it's problem first, every time. A slick demo without a clear problem just makes me think "cool tech, not sure who needs it." A clear problem with a rough demo still gets my attention, because I can fill in the rest myself.
Problem-first, every time and I learned it the embarrassing way. My homepage led with what Kaevo is ("AI household operating system") until I watched real people bounce. What made them stop scrolling was the problem sentence: "Your budget app doesn't know your passport expires in August. Your calendar doesn't know the water heater's warranty ran out in March." Nobody wants a household OS; everyone recognizes the Sunday-night dread of six apps and a drawer of documents that don't talk to each other.
The twist I'd add to your framing: for AI products specifically, the demo can carry it but only if the demo IS the problem being solved. A screenshot of my AI answering "is anything overdue?" converts better than any positioning copy I've written, because it's the problem and solution in one frame. Demo-as-problem-statement beats both.
Yes! always think about the problem first.
The first thing I look for is whether I can relate to the problem. If I don't immediately understand why it matters, I usually don't spend much time exploring the features.
I look for the problem first. A polished demo shows that a product works, but a clear problem explains why I should care.
While building VAT Engine, I’ve learned how important this is. The core problem is not simply “businesses need VAT rates.” It’s that EU VAT depends on country, product type, transaction date, thresholds, customer context, and reporting scheme. Smaller e-commerce teams often end up combining spreadsheets, separate plugins, generic APIs, and manual accountant work.
The product only becomes meaningful when that problem is stated clearly: reducing fragmented EU VAT work into one traceable calculation and compliance workflow.
I now use a simple test—if I cannot explain the problem in one sentence before showing the product, the messaging is not ready yet.