A brainstorm is the cheap part. An hour gives me a page of ideas (products, tools, the odd technology bet, now and then a whole company). On the page they all look good. Building any one of them takes weeks, often months.
So nothing gets built until it answers four questions in writing. Where is the money? What real problem does it solve? Can I explain the technology in plain language? What’s the moat, and what makes it different? It’s the screen an investor runs on a startup pitch, except the founder across the table is me.
The order is on purpose. Technical people tend to start with the technology, since that’s the fun part; an idea can live for months on fun alone. Asking about money first kills the weak ones while killing them still costs an hour.
Where Is the Money?
Every idea shows up with a big number attached. A $40 billion market, one percent of it, done. That number tells me nothing about whether anyone will pay me. So I skip it and look for a name: who pays for what, out of whose budget.
A weak answer says businesses will pay for this. A strong one names the job title that signs the invoice.
The best evidence is money that’s already moving. Competitors with public price pages. Acquisitions in the space. Funding rounds. A line item in somebody’s budget that the new thing would replace. When none of that exists, either I’ve found something new or I’ve found a market that doesn’t pay. The second happens far more often.
Software has a trap here. In many categories the core product is free, so nobody pays for the thing itself. They pay for what it takes to run a lot of it safely: support, management, compliance, someone to call at 3 a.m. Linux is free. Red Hat built a business selling subscriptions and support on top of it; IBM paid $34 billion for the company in 2019. When the core is free, my money answer has to point at whatever sits around it.
Prices at this stage are guesses. I write them down anyway, as guesses to test with real buyers, because a guess I can test beats a market size I can’t.
What Real Problem Does It Solve?
A real problem is one somebody has right now. It costs them something they can count, hours or money. The surest sign is a workaround. A spreadsheet someone updates every Friday. A script nobody admits to owning. A chat channel where the same question comes up every week. An intern. Half of somebody’s job. People who work around a problem have it; people who don’t, mostly don’t.
The cautionary case is Juicero. It sold a $400 Wi-Fi juice press that checked a code on each pack of chopped fruit and vegetables before pressing it. Then reporters tried squeezing the packs by hand. They got nearly as much juice. The machine worked. Nobody needed it. Juicero had raised about $120 million; it shut down in 2017.
The question has a second half that’s easy to miss. The person with the problem and the person who pays are often different people. Developers feel the pain; a security team or the finance department signs. If my money answer and my problem answer name different people, with nothing connecting them, I’m describing two products. Maybe neither one sells.
Can I Explain the Technology in Plain Language?
This one is a writing test. One short paragraph, for a smart reader outside the field, saying what goes in and what comes out. No jargon. No “AI-powered” standing in for an explanation.
If I can’t write that paragraph, I don’t understand the idea yet, or it’s vaguer than the pitch makes it sound. Either is worth knowing before any code exists.
The plain version also shows what’s new. Written out, it often describes a product that already exists. That’s useful. Now I know who the competitor is, and the last question just got harder.
Sometimes the plain version is the product. When Dropbox was first shown on Hacker News in 2007, a commenter pointed out that a Linux user could already build the same thing with an FTP account and version control software. He was right about the parts. Dropbox fit in a sentence anyone could repeat: put a file in this folder and it shows up on your other computers. People bought the sentence.
What’s the Moat, and What Makes It Different?
Two questions share this slot. The difference is why someone would switch from what they do today, which usually means a free tool or nothing at all. The moat is why the biggest player in the space can’t copy me once it’s obvious the thing works. Difference wins the first customer. The moat keeps the hundredth.
The real threat to a small product is the platform adding it as a checkbox. Mac developers have a word for this. In 2002 Apple shipped Sherlock 3, which did much of what Karelia’s Watson app already did, free with the operating system. Getting sherlocked has meant the same thing ever since. It still happens most years.
Real moats are dull. Switching costs. Data that piles up as people use the product. Being the format other tools read. Deep integrations. Years of trust with one kind of buyer. Being first doesn’t count, and neither does better code; code gets rewritten.
“None yet” is an honest answer this early, as long as I can say what the moat would be once there are users. “We’re faster” isn’t an answer at all. The incumbent can be faster by next quarter.
Keep the Answers
I keep the answers. If the idea survives, they’re the first draft of everything after it. The money answer grows into the business case. The problem becomes the headline on the homepage. The plain-language paragraph opens the documentation, and the moat answer is ready for the first investor who asks.
Most ideas should die at question one or two. Killing an idea there costs an hour; killing it after a prototype costs a month.
I’d rather spend the hour.
