What should you ask before building a software product?

Ask 7 questions before you write any code, and answer them honestly in an hour. Each one is a way one of my 25 dead products died. Very few of the deaths needed a new question.

The 7

1. Is it a problem you have today? A problem from a job you left is a memory, and memory sands off the hard parts.
2. Can it be live in 7 days? If not, it's too big to test alone.
3. Will someone pay before it's finished? Ask, with a date and a refund promise.
4. Do you already have the audience? Can you name where these people talk, and are you known there?
5. Can one person run it for 5 years? Count the support, not only the code.
6. Is the technology boring? Choosing it to learn something is a hobby.
7. Have you written down the number at which you'll kill it? Before launch, while you're hopeful.

The one that matters most

Filter 4. Of the 25 deaths, the biggest pile is products that worked and that almost nobody ever heard about. A booking tool for music teachers, launched to 300 developers. A broken-link checker posted in 6 places in one morning. A schema documenter announced to 20 rooms of strangers before the one room that knew my name.

Every one of those passed filter 5. One person could have run any of them for years. Nobody would have noticed.

How to use them

Score the idea on the day you have it, not after you've fallen for it. Most ideas fail 2 or 3 on the first day, and that's useful to know before you're attached. Then keep the score. When you read it again in a month, the idea either has a second person asking for it or it doesn't.

The filters aren't a guarantee. My longest-running product failed the first one in the strict sense, because I'm not a landlord. It survived because I'd been in the landlords' rooms for 5 years. What the filters do is make each attempt cheaper and more honest, so you can afford enough attempts for one to stick.

The rules page has the 7 on one page. Nobody Bought It scores all 25 dead products against them.