What's the PROBLEM your product solves?

For us, Vibelets is solving a problem I’ve personally felt for years. Marketing teams don’t lose because they don’t have ideas. They lose because every campaign starts from scratch. The same research is repeated. The same briefs are rewritten. The same mistakes come back after two weeks. The learning from one test rarely becomes the starting point for the next one.

That is the gap we are trying to solve.

Vibelets is built to help marketers turn scattered thinking into a repeatable campaign system, from angles, hooks and copy to creative direction and testing logic. Not just “generate content.”

As makers, it's easy to describe features, while for users what matters more is the workflow those features improve. Launching Isoline yesterday changed how I think about this. Going into the launch, I spent a lot of time thinking about the implementation—GLSL compilation, ray marching, graph traversal and exports. But the feedback I received wasn't about those things. People said they liked not having to wrestle with raw GLSL, the visual node graph, and being able to export directly to ShaderToy or STL. That made me realize the problem Isoline solves isn't "procedural modelling"—it's reducing the friction between experimenting with procedural geometry and getting something usable.

This resonates a lot. For FounderFlow, the problem isn't "founders need an AI assistant" it's much narrower: when you run more than one business, everything competes equally for your attention, and the stuff that quietly slips through the cracks is what eventually costs you money. The product just watches across your businesses and tells you the 1-2 things that actually need a decision today, and how confident it is about that. If I'd led with "AI Chief of Staff" instead of that problem, I don't think it would have landed nearly as well.

problem first, always — for health/wellness launches especially, since a polished dashboard means nothing if I can't tell "i'm anxious" from "i'm getting sick." that's the framing we lead with: 30 seconds of talking tells you your nervous system state, no wearable needed. do you find health-category launches are worse at problem-first messaging than others, or about the same?

In Abroad Life, we don't think our product solves "immigration."

It solves the feeling of being lost when starting a new life in another country.

That's the problem we're obsessed with.

Anna, I appreciate this discussion.

Problem first, always. I'm also learning the strong demo show what a product does.

The problem tells me whether I'd have paid to make it go away, and that's the a primary factor that predicts whether I'll still be using it next week. I'm still learning about this.

Here's mine, one sentence: podcast hosts burn hours hunting for guests and can't tell a good booking from a bad one until they're already recording. That's what PodGreenroom fixes. It vets a guest before you send the invite, so the "is this person actually right for my show" question gets answered up front instead of in the edit.

My hope is that everything the product does hangs off that one sentence. And it's my test for any launch too: if you can't say the problem out loud without a slide, you might not have found it yet...

I second this! The demo/output definitely helps and is sort of the first filter for me, but whether or not I want to take that extra step to make an account and potentially pay for the service as well is where the "what problem does this solve?" comes in handy.

It's like buying a pint of ice cream for its appealing design but then realizing "what's so different about this brand?"

Problem first, every time, for me. When I'm scrolling launches, if I can't tell what was breaking in someone's day before this existed, I move on no matter how nice the demo looks.

I learned this the hard way with my own launch. My first instinct was to lead with "AI Chief of Staff" and explain the architecture. It fell flat. What actually landed was naming the specific mess: running a software company, a care home, and a cafe at once, and never being sure which one actually needed me that day versus which one was just being loud. Once people recognized that feeling, the product made sense on its own.

So I'd say the demo's job isn't to sell the problem, it's to prove you understood it correctly.

I completely agree with this. Features and demos might catch my attention, but the first thing I always ask myself is, "What problem does this actually solve?" If I can't answer that within a few seconds, it's hard to stay interested, no matter how polished the product looks.

That mindset has shaped how we've been building MySpec, too. We realized the real problem wasn't that AI couldn't generate code, it was that founders and developers often started building before they had enough clarity. That's why our latest update supports both sides of the journey: Greenfield for people starting with nothing but an idea, and Brownfield for teams improving an existing codebase. Different starting points, but ultimately the same goal, helping teams make better product decisions before writing more code.

I think products become much easier to explain when the problem is obvious. The solution almost speaks for itself.

This really resonates. We spent far more time defining the trust problem in financial markets than talking about features. Once the problem was clear, explaining the product became much easier.