Questions, answered plainly

Answer in a slot, not all day, and read the questions for the feature they're asking for. Repeated questions are the best product research you'll get.

Ask named people for money for a thing that doesn't exist yet, with a date and a full refund if you miss it. Then open the payment account first, not last.

Run it through 7 questions in an hour, then ask 10 named people for money before you write any code. If nobody pays, you've saved a month.

Look for a room you've already been sitting in. The best niche is a group whose problems you've watched for years and who'd notice if you stopped posting.

7 days. If the smallest version that someone would pay for takes longer than a week, the idea is too big for one person to test.

Yes. Free users prove that people like free things. A price on day one tells you in a week what a free tier hides for a year.

Labour you can check, such as reading, sorting and drafting. Not judgement. Hand an agent the decisions and it returns the average of everybody else's.

One named slot per product, the same pages in the same order, and a line in the file each time. Mine is 2 hours on a Sunday for the biggest product.

A metric, a number, a date and an action, written before launch while you're still hopeful. It lets you stop a product calmly instead of watching it fade.

Warm to cold. The room where people know your name goes first, on day one, with your best post. Strangers come after, once they can see somebody cared.

7 questions, in an hour, before any code. They came out of 25 dead products, and most of those deaths needed no new question.

Talk to the people who signed up. Rewriting the landing page, adding features and relaunching are what everybody does instead, and none of them works.

The dullest one you already know, written on one card and changed only in January. A new product should never also be a new stack.

Only if you already have the crowd. A marketplace is empty until it's crowded, and every time I filled one side, the other side emptied.

No. Free users prove that people like free things. My shared shopping list had more users than anything I've built, and almost all of them left the month it asked for money.

Write the kill date while you're still hopeful, before launch. I kept a driving instructors' tool alive for 36 months after I knew it was dead.

20 minutes, the week it dies, on one card. What it was, who it was for, what actually killed it, and the rule it leaves you. The version written 6 months later is a story about yourself.

No. A store is a shelf. It puts your product in front of people searching for something with a similar name, and it never walks anyone over to it.

Only if you're genuinely one of them. I spent 3 weeks beside a builder and a decorator, called myself inside the trade, and built on 2 yeses. Nobody else ever heard of it.

No. One yes is one person's problem. My bookkeeping tool paid for itself, exactly, with one customer for 5 months, until he changed jobs.

Close it cleanly and quickly. I found out from a Tuesday changelog, gave 6 weeks' notice, refunded the month and wrote a guide to moving across.

Then a monthly price will bleed it. Match the shape of the payment to the shape of the value. My stock-take planner's value arrived twice a year; the charge arrived 12 times.

Because they're launched to the wrong people, once. A launch is a morning; distribution is every week after it, in the place your customers already talk.

Mostly because nobody who has the problem ever hears about them, or because the people who do hear don't want them enough to pay. 23 of my 25 dead products died one of those 2 ways.

Because "freelancers" is a contract, and nobody gathers under it. You can't email it, find where it complains, or notice when 3 of them say the same thing.

Many do. They already pay for insurance, hall hire and the van. I gave a volunteer rota away for 9 months on a belief I never checked, and the support queue grew with every group.

An allowance. Set it at the heaviest sensible month, with a charge above it that pays. Customers can predict their bill, and nobody can cost you a fortune.

A failure retried 3 times costs 4 times. Cap the attempts on every item, never retry a bad input, retry a wrong answer once at most, and read the pile every week.

Move every job you can write as a rule into ordinary code first. 2 of my document product's 5 model calls were doing arithmetic and date checks. Moving them roughly halved the model spend.

Measure what one unit of work costs on real inputs, multiply by your heaviest sensible customer's month, and keep that under a tenth of the price.

Raise it for new customers first, and tell existing ones in a proper letter with the reason. Never shrink the product quietly instead.

A hard cap on every key, watched until it fires, and a daily ceiling in your own code that stops, holds the work and tells you. Set the ceiling from the shape of the month.

Run 30 real inputs through the model before you build, then read a page every week listing what each customer cost you. One row many times the others is either keen or broken.

No. A free tier on anything with a meter reads documents for people who haven't paid, every month, with no price to divide by. Show saved examples, run a sample by hand, or promise the money back.

Queue it. Put the work in a queue, check it, store it, then tell the customer. Call the model live only when somebody is genuinely waiting.

Rerun your own past work on the new model before any customer meets it. One door in the code, 3 months of stored inputs and a second option you know make it a Sunday job.

The model fee is a fraction of a penny. The real cost is your evening, an apology, and a customer's trust that the product says true things. Right, then cheap, then fast.

The judgement. Give the model labour you can check, and keep the price, who it's for, what you say when it goes wrong, and what to switch off.

When it agrees with the strong model on your own past work and its failures are the kind your check catches. Test it on 50 real inputs, read every disagreement, then route.

Give them one shared weekly page: what changed, what's waiting, and a line for every fault that once reached a customer. A dashboard only shows what you thought to put on it.

One sheet of paper in January. Every product down the side, with its slot, its year in a line, and one word: keep, grow, hand over or close.

Build every product on the same machinery, so a new one only adds the part that's new. My first rebuild drill took 6 hours and 20 minutes and found 3 things that lived only in my head.

One email with the reason, the date, a full refund for the current month and an export you've tested yourself. Then one line at the end, for anybody curious about what's next.

As many as you have named slots in your week. I run 5 in about 3 evenings, and I've stopped there, because a sixth would need a slot I don't have.

If anybody paying you is asking for something you haven't built, build that first. 3 landlords asked for the same thing in one month; it took an afternoon and became the best feature the tool has.

Look for somebody who cares about its customers more than you do, and hand it over properly. I closed a working fees tracker for language schools, and its customers went back to paper.

Mine ran for 2 weeks of flu with nobody looking, mostly by luck. Now each product has one page, written while I'm well, saying where it lives, what runs, what needs a person and what to tell customers.

6 things: the inbox, the price, the stack, the dependencies, the customers and the slot. I walked away from a dog walkers' booking tool that failed several of them at once.

When the newest paying one has settled: it fits a slot you could name, it hasn't needed you outside that slot for a month, and its questions have become repeats.

From your cancellation replies. Read them all in one sitting, on paper, for the sentence that goes past the question. The same paragraph from 3 strangers is a product.