Can't explain your startup in one sentence? Start here

Usually because the problem has not been pinned down yet, not because you are bad with words. When someone asks what you are solving and you talk for five minutes, you are still searching for the problem out loud.

Many founders keep the idea vague because a vague idea cannot be shot down. That is our reading of the pattern, not a measured finding. Vague feels safe, but it is only untested. The sentence is where a weak spot becomes visible, and a visible weak spot is one you can fix.

Three parts, and each one has to be something you could check:

• Who: one specific kind of person, narrow enough that you could find ten of them this month.
• What happens: the moment in their week when the problem shows up.
• What it costs: hours, money, lost customers or stress that someone could actually count.

A simple template: "[Person] struggles with [moment], and it costs them [cost]." If one slot stays empty, do not make something up. The empty slot is the thing you need to go and observe.

Here is an illustrative example, not a real founder or a real tool run. Say you spent six years in billing at a dental office. Your first attempt is a five minute ramble about insurers, phone calls and rejected claims.

A sharper version reads: "Front desk staff at small dental offices spend hours checking insurance by phone, then claims get denied anyway." The cost follows from that: the office pays for the same work twice.

Now each part can be checked. Who: front desk staff at small dental offices. What happens: long phone checks, then denied claims anyway. What it costs: staff time, spent twice.

Two more illustrative examples, invented to show the shape, with a vague version first:

• Vague: "An app for dog owners." Sharper: "Dog owners who work long office days pay for walkers they cannot vet, and a missed walk means a mess at home and a stressed dog."
• Vague: "Software for bakeries." Sharper: "Small bakeries guess tomorrow's bread orders by hand, and the leftovers they throw away each evening eat into a thin profit."

Each sharper line names a person, a moment and a cost. None of them mentions the product yet. The product comes after the problem holds up.

The weakest one. In the example, six years inside makes the "who" and the "what happens" believable. The cost is the weak spot. Nobody has counted it at a single office, and the link between the phone checks and the denials is assumed, not shown.

If most denials actually come from coding mistakes, meaning the wrong billing codes on the claim, the sentence falls apart. It splits into two smaller problems, and neither may be big enough to build on.

So the test is concrete. Talk to billing staff at three offices where you never worked. Ask them to look back at last month: how many hours went on insurance calls, and how many denials traced back to coverage? If fewer than two of them raise coverage-related denials without you prompting, the cost part is in trouble.

Before those calls, read how to find the right people to talk to and the interview questions that get honest answers.

Your experience is your strongest asset and your biggest blind spot at the same time. Years inside a field make your observation believable. But it stays your claim until someone at another company confirms it.

The strongest case against this advice: some founders with deep experience build first and turn out to be right. The missing fact is whether people outside your old workplace feel the same cost. If they do, checking costs you a week. If they do not, it saves you months.

Problem Sharpener takes your rough description and works it into one problem sentence. It points to the part it reads as weakest and suggests a way to test it. If you only have a feeling that something is wrong, it marks the empty parts as open questions instead of filling them in for you.

It sharpens the problem. It does not judge the idea. Whether the idea is worth building is the next question, covered in is this a good idea or am I just excited. If you have no idea at all yet, start with what to do when you want to build but have no idea.

Write your problem in the three-part template. Circle the part you are least sure of. Ask three people outside your circle about that one part, using questions about what already happened to them. Write down their answers before you write any code.