Identifying High-Quality Problems

A high-quality problem is felt acutely by a real customer, has no good existing solution, and is something you're positioned to solve better than the alternatives. Most people skip problem selection because they already have an idea they're attached to.

The order matters: problem first, solution second. If the problem description sounds like a thinly veiled solution, you've skipped the problem. You need to be able to describe the pain clearly without mentioning how you'd fix it.

Write it in one sentence: 'If we help [customer] solve [problem] with [approach], they'll choose us over [alternative] because [differentiation].' If you can't write it that cleanly, you don't understand the problem yet.

This sentence is not a pitch. It's a falsifiable claim about the world. Every word is a testable assumption. The assumptions that would kill the project if wrong are the ones you test first — cheaply, before you build anything.

Go stand next to the customer. The most honest signal about a problem's severity and a solution's appeal isn't a survey — it's a conversation with someone who has the problem right now, in the context where they experience it.

Ask for substitutes and the 'do nothing' option. Most students only name apps that look like their app. That misses how people actually solve the problem today — usually a spreadsheet, a habit, or nothing. The strongest competitor is almost always the status quo. Name it before you write the spec.

Name the load-bearing assumptions — the beliefs that, if wrong, would kill the project. List them explicitly. Test the ones that would kill you first, because those are the ones most worth knowing about early.

Before you commit to a direction, sit down and pretend it's two months from now and the project has failed. Write down every reason why. Most of the reasons you'll write are things you could fix today for free.

This is different from a postmortem because you still have time to act. The premortem is the cheap version of the lesson. The postmortem is the expensive version.

Before any team commitment to a direction, paste your hypothesis back to an AI and ask why it might fail, who wouldn't use it, and what you're probably underestimating. This is the step people skip because they want to feel good about the idea.

If your idea can't survive its own devil's advocate pass, you're not ready to pitch it. If it can, you have a cleaner version of the argument — and you've already heard the counterarguments so they don't surprise you later.