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 lens is so underrated. I'm a solo founder building in AI ad generation and the discipline of being able to say the problem in one sentence is what separates people who can sell from people who can only demo.
For MotionFy it took me 3 versions to get there:
V1: "AI-powered ad creative platform" (means nothing)
V2: "Generate ads in seconds" (still vague, what ads, for whom, why)
V3: "DTC beauty brands run the same 3 creatives until they burn out. We give them 20+ variations from one product photo."
The difference is V3 names the customer, names the actual pain (creative fatigue), and names the consequence (running the same thing until ROAS drops). Without all three, the problem statement is just a feature description in disguise.
The trap I see most often: founders describe what their product does instead of what their customer was failing to do before.
@elias_motionfy Oh yeah, well done - V3 is hands down the best of the 3! Now the Prospect understands exactly the problem your product solves for them. If you wanted to sharpen the outcome a little more, you could try:
"DTC beauty brands run the same 3 creatives until they burn out. We give them 20+ variations from one product photo, so they rotate ahead of fatigue instead of reacting to it." Now they can see it's a preventative measure as well (bonus). Have you launched this already?
@anna_ludwinowski "Ahead of fatigue instead of reacting to it" is a genuinely sharper version, the preventive frame reframes the whole purchase from "we need more creatives" to "we don't want to hit the wall in the first place." Different budget category, different conversation. Stealing this.
Not launched yet, Product Hunt on July 22. I've been in build-mode for 4 months and about to find out whether the positioning survives contact with real buyers. If you want to see how the pre-launch is going, the page is here: https://www.producthunt.com/products/motionfy?launch=motionfy
Thanks for the sharpening. It's rare to get a stranger to actually improve your copy in the wild.
@elias_motionfy Glad that it hit for you - and happy to help!
You're in the homestretch now - excited, nervous, both?!
@anna_ludwinowski Both, honestly, but more excited than nervous now that the positioning has been through enough conversations like this one to feel solid. The nervous part isn't "will it work," it's "will enough of the right people see it on the day."
Four months solo makes launch day feel bigger than it probably is. I keep reminding myself the launch is one data point, not the verdict.
I'll actually be reaching out closer to the 22nd to a small group of people whose input shaped this, you're on that short list, given you literally sharpened the core line. No pressure at all when it comes, but wanted to flag it now rather than surprise you.
Problem first, every time. A slick demo grabs my attention for about three seconds, but if I can’t immediately see what painful thing it fixes, I move on. The launches that stick with me are the ones where the problem is so clear I almost feel called out—then the product becomes the obvious answer. Naming the problem up front isn’t a tweak, it’s the whole opener. Without it, even the most polished UI feels like a solution in search of a problem.
@chess123app_admin Yes, exactly - you want to feel that "I just got called out" feeling! The ones you FEEL are the ones you remember, buy, and tell others about.
I start with "What problems can my program solve to remove a pain point for me" and then if others find it useful, they will upvote or star it wherever I post it (and I will probably continue to work on it a bit). I don't look for "how can I monetize it", I look for a truly beneficial product that is valuable in the sense that it works for me, and I don't have to use some product that comes close but never quite touches the problem properly. The money usually comes from how it eliminates time or issues in services/projects that I already do on the side.
@g023 If we lead with monetization, we can become blind to the problem we're trying to solve because it becomes only about the $$$. Find the problem, build the solution, find the Users, make the $$$.
The problem Maleu solves: your digital life is scattered.
You're social on Instagram. You think on Twitter. You learn via YouTube rabbit holes. You track fitness on Strava. You build community on WhatsApp groups. You chat on Telegram.
None of these know the full you. They each know a fragment.
Maleu is one space where all of that is connected — your social feed, your learning path, your fitness journey, your communities, your conversations. One identity. One social graph.
Launched on PH today. The problem is deeply personal — I was the user I built it for.
@dharan_tej_reddy "They each know a fragment" that's a sharp line! That would've been great in your launch post. Fragmentation is a Founder's problem, not usually a User's. Nobody quits Strava because it doesn't know their Twitter thoughts. So I'd push on this - what's the ONE thing in Maleu someone does in week one that they can't do anywhere else? That's the wedge, and once you find it, the "one identity" story becomes your proof.
For Geode, the original problem was: “I need to transcribe this, but I don’t want my recording to go to the cloud.”
That came up a lot with interviews, research calls, client conversations, and internal meetings.
So we started with local-based transcription.
But then we learned the problem was not simply “cloud is bad.” Some users actually wanted cloud transcription or cloud summaries when the audio was difficult, less sensitive, or when accuracy mattered more.
So our positioning became: local by default, cloud by choice.
The problem we solve is giving people control over how their recordings are processed — not forcing every conversation into the same cloud workflow.
@geode_ai Ok, now THIS is good: "Local by default, cloud by choice" is a great landing point! I like that you didn't get there by assuming the first problem statement was wrong - you got there by learning it was incomplete.
So, at what moment did you realize "cloud is bad" wasn't quite it? Was there a specific user or conversation that pushed back on that assumption, or did it show up gradually across a bunch of calls?
I completely agree. I think a lot of founders fall in love with the solution before they've clearly defined the problem.
For us, the problem was actually what led to the product. We kept seeing teams jump straight into AI coding tools, only to realize later that the real bottleneck wasn't writing code, it was unclear requirements, missing edge cases, and everyone having a slightly different understanding of what they were building.
That's why we built MySpec, to help founders and developers create clarity before development begins, instead of fixing misunderstandings after code has already been generated.
I also think this applies to Product Hunt launches. If I can't quickly understand why a product needs to exist, it's much harder for me to appreciate how good the solution is.
@nancyy_chooTHIS: "Founders fall in love with the solution before they've defined the problem". Yes, and I'd bet most of us in this thread have done it at least once.
Question on your specific case though: the bottleneck you described (mismatched understanding across a team) sounds like it hits founders and developers a little differently - a founder's version of that pain is probably "I don't know if what's being built is what I meant," and a developer's is probably "I built exactly what was asked and it's still wrong."
Which one is the moment MySpec is actually built around, or does it genuinely split the difference?
I try to answer the "problem to solve question" as early as possible. Sometimes too early.
The hardest part for me is reducing the problem to a single sentence. It’s tempting to describe what the product does instead of the one problem it solves.
I’ve also noticed that this sentence changes as you learn. Especially before product-market fit, every user conversation can refine—or completely change—how you describe the problem.
One exercise that helps me is switching to the user’s perspective. Instead of asking “What did I build?” I ask “What changed for the user after using it?” The answer is often much simpler.
Coming from enterprise IT, I think this is something many projects struggle with. We often start from a list of required features rather than a clearly articulated problem. You can build exactly what’s specified and still miss the thing the user actually needed.
@picspace "What changed for the user" instead of "what did I build" is exactly the right swap! It's the same trap in enterprise IT and in most launches here, just dressed differently (feature list vs. demo).
Since you mentioned the sentence changes as you learn: do you have an example of how yours shifted for picspace? Like what the early version of the problem sentence was, versus what it is now? I'd guess the gap between those two says more than the exercise itself.
The problem Naxely solves is one I kept seeing in freelance work: you spend 3 hours in Excel making a client report look presentable, and the actual analysis took 20 minutes. The ratio is backwards.
Freelancers and agencies send the same type of report every week — same structure, same sections, just different data. But every time it's manual: copy numbers, fix formatting, write a summary, make charts, export to PDF. None of that adds value. It just takes time.
So the product is: upload your CSV, get a branded PDF report with charts, anomaly flags, and an AI-written summary. The 3-hour part becomes 30 seconds.
To your broader point — I think demos sell curiosity, but problems sell decisions. Someone watching a demo thinks "interesting." Someone who recognizes their own problem thinks "I need this." Those are very different moments.
@deepanshu_garg9 "The ratio is backwards" is such a clean way to say that! I'd bet more people recognize themselves in that line than in most demo videos.
Soh, when you were building the landing page, did you have to fight the instinct to lead with the demo (CSV → PDF in 60 seconds) over the problem? Because your PH comment nails the problem way sharper than most homepage headlines do, and I'd guess that wasn't the first draft.
My co-founder and I created Neuphlo to solve issues we've had over the years with project management tools (I'm a test manager). no matter which tool i have tried, i ended up having various workarounds to make the tools fit our department work processes. When building our landing page, we have adressed some of these issues, but I still think we have a long way to go before we can really "catch" new users using the site alone. I do not have the answer as my marketing skills suck, so I am listening in on all you good people to see what really makes a product catch the eye :-)
Regards
Jan Riis Sørensen
Co-found of Neuphlo.com
@jan_sorensen The thing I keep coming back to in your comment: you told us your frustration (test manager, years of workarounds, tools that didn't fit your team's process) but the site reads like it's for any team running projects with AI agents.
And while those might both be true, right now it's not clear which ONE Neuphlo actually is.
Is it a sharp tool for people in roles like yours, OR a broad platform where your story is just the origin, not the ICP.
Genuinely curious which one it is for you, because I think that answer is upstream of the "catch" problem you're describing. You can't sharpen the hook until you know who it's supposed to hook ;)
Fragmented software and per-seat pricing.
@austinbuhl Ok - are these things you look for or notice about a product? Are those the problems?
@anna_ludwinowskiThose are the problems I believe Salestrics solves.
For most startups, work is fragmented across half a dozen tools—CRM, chat, meetings, docs, email, support—and every new hire increases costs because of per-seat pricing. Teams spend hundreds to thousands of dollars each month while context is scattered everywhere.
Salestrics is our answer to that: an AI-native revenue workspace that brings CRM, Service, Docs, Chat, Meetings, Email, and more into a single platform with AI built in from the start, so startups can spend less time stitching tools together and more time building their business.
In terms of launches on Product Hunt, I've seen plenty of products that have won me over just with the demo.
@austinbuhl Interesting that you land on problem-first for Salestrics but demo-first as a viewer. Do you think there's a difference between what convinces you to look closer versus what you'd actually put in your own launch copy?
And on "most startups" - is there a specific kind of team you picture hitting that per-seat pricing wall, or is it genuinely everyone past a certain size?
I think they're connected. A demo gets me to stop scrolling, but the problem is what makes me remember the product.
As for "most startups," I picture teams that have grown beyond just a handful of people, let's say 5+. That's usually when they start accumulating tools for sales, support, meetings, docs, email, and internal communication, and the per-seat costs begin to compound.
Salestrics is our answer today, but it took a long time to arrive at that problem. I originally set out to build an agricultural drone, then pivoted to software for managing those drones, then to AgrovuxOS—a CRM for agriculture. After talking with small businesses, I realized the bigger opportunity wasn't agriculture at all. The recurring pain I kept hearing was fragmented software and rising per-user costs, regardless of industry. That insight ultimately led to Salestrics.