Sell the problem first. The solution can wait.

Most pitch decks open with the product. Slide one is a screenshot. Slide two is a feature list dressed as a vision. Slide three is a market size number large enough to make everyone slightly nervous. Somewhere around slide seven, if you are lucky, someone mentions the customer’s actual Tuesday. By then the room has already decided whether they like the solution-without agreeing on the problem.

I have watched this pattern burn months of runway. Teams ship elegant answers to questions nobody is asking out loud. Marketing then inherits the awkward job of inventing urgency after the fact. It rarely works. Features are answers. Problems are the reason anyone listens.

This piece is about building and positioning products so the problem arrives first-in research, in copy, in demos, and in the roadmap. It sits alongside how I decide whether a product is worth building and why great products fail before product-market fit. If you are already mid-launch and wondering why the channel feels broken, start here instead of the ad account: most product launches don't fail because of marketing.

Why solution-first feels productive (and usually isn't)

Building is comforting. Naming a problem precisely is not. A problem statement forces trade-offs: who hurts, how often, what they do today, what they will pay to stop. A feature list lets you stay in the pleasant fog of possibility. Founders are rewarded for shipping; they are rarely rewarded, early on, for saying “we are not building that yet.” So the roadmap fills with solutions looking for an audience.

• Solution-first copy sounds clever and lands soft-nobody feels seen.
• Solution-first demos show capability; buyers buy relief.
• Solution-first roadmaps accumulate features without accumulating belief.
• Solution-first fundraising trains you to sell theatre to people who will never use the product.

The irony is that problem-first work is faster in the long run. You cut half the backlog before it becomes code. You write landing pages that do not need a thesaurus. You stop arguing about button colours because the conversation is about whether the pain is real. Related reading when the backlog is already bloated: the hidden cost of building features nobody asked for.

A simple sequence: pain → language → proof → product

I use a four-step sequence with founders at nau. It is deliberately boring. Boring is underrated.

1. Pain: find the cost of inaction

Ask what breaks if they wait another quarter. Money, time, reputation, compliance, sleep-pick the currency that already appears on their calendar. Mild inconvenience is not a market. Chronic, costly friction is. Jobs-to-be-done language helps here; the Interaction Design Foundation has clear primers if you want the theory without the cult.

2. Language: steal their words, not yours

Customers do not say “synergistic workflow orchestration.” They say “I spend Friday nights copying numbers into three tools.” Your homepage should sound like their Slack rant, cleaned up slightly for public consumption. If your positioning requires a glossary, you are still selling the solution’s self-image.

3. Proof: show the problem is solvable before you sell the suite

A case study, a before/after, a two-minute teardown, a spreadsheet that already works-anything that proves the pain can move. Proof is not a feature tour. Proof is evidence that Tuesday got shorter.

4. Product: only then attach the mechanism

Once the problem and proof are clear, features become explanations rather than the pitch. “Here’s how we remove that Friday-night copy-paste” lands. “Here’s our AI-powered platform” does not, unless the listener already trusts you.

Problem clarity versus solution theatre

A feature is a claim. A problem, stated in the customer’s language, is an invitation to trust.

Framework: the problem brief before any build

Before design, before Figma, before the sprint-write a one-page problem brief. I refuse to open a layout tool until this exists, which is why I start every project without opening Figma. The brief is not a PRD. It is a discipline.

1. Who specifically feels this (role, context, constraint)-not “SMBs.”
2. What they do today when it hurts (tools, people, workarounds).
3. How often it hits and what it costs in their currency.
4. What “solved” looks like in the first week of use.
5. What evidence would kill the idea (not what would make it pretty).

If you cannot fill the brief, you are not ready to sell a solution. You are ready to research. That is not failure. That is the job. For a fuller pre-design sequence, use the product strategy framework I use before designing a single screen.

A fictional contrast: two invoicing tools

Founder A launches “InvoiceOS-AI-native billing for modern teams.” The site lists integrations, templates, and a chatbot. Demos start on the dashboard. Trial users poke around and leave. Support tickets ask what the product is for.

Founder B launches with a different first sentence: “Freelancers who chase late payments every month.” The hero shows a calendar with three red “still unpaid” days. The demo opens on a reminder sequence the founder built for themselves. Features appear as explanations of how chasing stops. Same category. Different first move. Only one of them solved a problem before selling a solution.

Exercise: the mute-button pitch

Where this breaks in practice

Problem-first is not “never talk about features.” It is sequencing. Engineers need specs. Designers need constraints. Investors need a mechanism. The mistake is leading every external conversation with the mechanism because that is what you spent the weekend building.

It also breaks when founders confuse their own annoyance with a market. Your Friday night frustration is a hypothesis, not proof. Treat early buyers as teachers-more on that in the first customer isn't your market. They're your teacher.-and keep updating the problem statement as language sharpens.

Useful external anchors: Y Combinator’s library on talking to users, First Round Review on focus, and Nielsen Norman Group on how people actually scan product copy. None of them will write your problem sentence for you.

Problem-first across the stack

The discipline only works if it survives contact with every surface. Website, sales deck, onboarding email, in-product empty states, support macros-each one either reinforces the problem or quietly reverts to feature theatre. I have seen a sharp homepage undone by a demo that opens on settings. I have seen a sharp demo undone by an onboarding checklist that asks for integrations before any relief appears.

• Homepage: situation and cost before product name.
• Demo: their workaround before your dashboard.
• Onboarding: first win before configuration completeness.
• Pricing page: outcomes and who it is for before feature matrices.
• Support: answers framed as “you were trying to stop X” before button paths.

When those surfaces disagree, the customer learns not to trust the first sentence they read. Consistency is not brand fussiness. It is how problem clarity becomes belief. Airbnb’s early pages worked because they made the awkward lodging problem feel solvable before they sold “a platform.” Figma won attention by making multiplayer design pain obvious in the product itself-not by listing vector tools first.

A weekly habit that keeps you honest

Once a week, take one sales call recording or support thread and extract a single verbatim problem sentence. Put it next to your homepage hero. If they do not rhyme, rewrite the hero-or rewrite the ICP. Do not debate adjectives in a vacuum. Debate against the words people already use when they are annoyed.

This habit also protects you from PMF theatre. Declaring fit while the public sentence and the private rant diverge is how teams freeze a story the market has already left. Keep the problem moving as evidence moves-fit is not a trophy, which is why product-market fit isn't a milestone. It's a moving target.

How this shows up in my work at nau

When founders come to me mid-build, I often pause the visual work and force the problem brief. It feels slow for a week and saves a quarter. Websites, onboarding, and launch narratives all get clearer when the product stops introducing itself as a list of verbs. If what you need is not another campaign but a sharper product story, read what founders actually need isn’t more marketing.

Listen first, then ship

The best products do not open with their own cleverness. They open with a problem the buyer already pays for-with time, money, or quiet dread. Solve that on the page, in the demo, and in the first week of use. Sell the solution only after someone feels understood. Features will wait. Attention will not.