Most founders hire developers before they answer the four questions that decide whether their idea is a business. That's how $40,000 disappears into an MVP nobody wants. Ask these questions first and most ideas fail at least one. That failure is the cheapest, most useful one you'll ever buy.

The good news: the four questions are not original, they're not secret, and they don't require a technical background to ask. The bad news: founders skip them anyway, because asking them honestly is uncomfortable. The whole point of this post is to make them harder to skip.

What are the four product risks every startup idea has to survive?

The four product risks come from Marty Cagan, founder of Silicon Valley Product Group and former product leader at Netscape and eBay. In his book Inspired, Cagan argues that every product idea faces four independent risks before it can succeed: value risk, usability risk, feasibility risk, and business viability risk. An idea has to clear all four. Founders who skip even one tend to rebuild, pivot, or shut down within 18 months.

Most non-technical founders only think about feasibility, and only as "can someone code this." That's the easiest of the four. Software is good at solving feasibility. It's terrible at solving the other three.

Translated into the four questions a founder actually has to answer:

Value. Does anyone want this badly enough to pay for it, switch from what they use today, or change their behavior?

Usability. Can a normal user, not a power user, figure out how to use it without hand-holding?

Feasibility. Can the version we'd ship in three to six months solve the problem well enough that customers stick?

Viability. Does the math (acquisition cost, lifetime value, pricing, retention) produce a business, not a charity?

CB Insights has analyzed over 400 dead startups and the same top reasons keep surfacing: no market need, got outcompeted, ran out of cash, flawed business model, team issues. Map them back to Cagan's framework and almost every failure is one or more of these four risks left untested. The 80% in the title is not dramatic license. It's roughly what happens when founders run an idea through the four questions honestly. Most ideas fail at least one. That's not bad news. That's the test working.

How do you test value before you build anything?

You test value by getting customers to do something costly before you build. Words are free. Time, money, and reputation are not. The fastest, cheapest test of value is whether someone gives you something they don't give away easily. A 30-minute deep-dive conversation. A deposit. A pre-order. A written intro to their boss. A paid pilot for a service you deliver manually. If you can't get those, you don't have a value signal. You have a friend group.

Rob Fitzpatrick's The Mom Test is the playbook. The core idea: stop pitching, start investigating. Don't ask "would you use a product that does X?" Ask "how do you do X today? What's the worst part? What did you do last time it broke?" People are reliable about their past behavior. They're unreliable about predicting their future behavior, especially when they want to be polite.

Three concrete techniques that produce real signals.

Five conversations, not fifty. Five focused conversations with the right people tell you more than fifty surveys. Look for three things: real pain (they describe the problem before you mention it), real spending (money, time, or workarounds with measurable cost), and real urgency (they've tried to fix it in the last 12 months). One out of three is interesting. Three out of three is a green light.

The painted door test. Put up a landing page that describes the product as if it exists. Spend $200 on ads. Watch who clicks "Buy" or "Join Waitlist". The drop-off between curiosity and commitment is the value signal. If 5,000 people read the page and three sign up, the message isn't broken. The demand is.

The concierge test. Manually deliver the service your software would automate, for three to five paying customers. Charge real money. If five people will pay you to do it by hand, they will probably pay your software to do it automatically. If they won't pay you in person, they definitely won't pay your app.

We covered the failure mode underneath all of this in 400+ Startup Postmortems. Same $40K Mistake. Every Time.: the conversations that kill startups are the ones that cost the other person nothing. Free encouragement is not validation. It's politeness, with confidence.

How do you test feasibility without a technical co-founder?

You test feasibility by splitting your product into commodity work (almost everything) and genuinely novel work (almost nothing). For the commodity layer, the question is not "can this be built?". The answer is yes. The real question is "can it be built well, by whom, in what time, and for what cost?" For the novel layer, you pay a senior engineer for a one-week paid spike. The deliverable is a one-page memo, not code: how hard is the kernel, what are the unknowns, what does a v1 look like, and what would it cost.

Most non-technical founders confuse feasibility with capability. They worry "can this be built?" when the real worry should be "can this be built inside the budget and timeline that make the business work?" Software can do almost anything given infinite resources. Startups don't have those.

Four practical steps any non-technical founder can run.

Strip the idea to its kernel. What is the one thing your product does that nothing else does? Write it in a single sentence. Everything else is commodity. A login page is commodity. A dashboard is commodity. A Stripe integration is commodity. The kernel is the thing a customer would mention in 30 seconds.

Get three quotes for the commodity layer. Talk to a product studio, a senior freelancer with shipped products, and an offshore agency. The spread will be roughly 3x. The cheapest option is rarely the cheapest option in the long run. We broke down this trade-off in Dev Agency vs. Product Studio vs. CTO: The $50K Decision Nobody Explains.

Pay for a one-week spike on the kernel. Hire a senior engineer for one week of paid investigation. Budget $2,000 to $5,000. The output is a one-page memo. A small spike has saved founders six-figure overruns more times than we can count.

Double whatever timeline you're given. Then ask yourself: if this took twice as long, would the business still survive? If the answer is no, your feasibility risk is hidden in the schedule, not the code.

You don't need to be technical to test feasibility. You need to be specific. Vague briefs produce vague estimates, and vague estimates produce real overruns.

How do you actually decide: build, kill, or pivot?

The decision turns on three inputs: customer signal, competitive reality, and economic model. Build when real customers describe the problem unprompted, your approach is meaningfully different from existing alternatives, and the unit economics work at conservative scale. Kill when interest is polite but not desperate, a funded competitor already solves the problem adequately, or the math requires unrealistic assumptions to break even. Pivot when the original idea is dead but the conversations revealed an adjacent problem that's sharper, more urgent, and underserved.

Three real cases make this concrete.

Slack was a pivot. Stewart Butterfield was building a video game called Glitch at Tiny Speck. The game failed. The internal chat tool the team had used for years became Slack. The signal was already there before the pivot, embedded in the actual usage of a real team that depended on it.

Instagram was a pivot. Burbn was a check-in app with too many features. Kevin Systrom and Mike Krieger watched what users actually did, which was post photos, and stripped everything else. Within months of the relaunch, the app crossed a million users. They didn't keep building Burbn longer.

Quibi was a kill that never happened. Jeffrey Katzenberg and Meg Whitman raised $1.75 billion for short-form mobile video and never tested whether anyone would actually pay $5 a month. Polished execution. Wrong question answered. Six months after launch, it was over. We covered the broader pattern in 400+ Startup Postmortems.

The hardest part of this decision is not the analysis. It's the honesty. Killing an idea you've been excited about feels like failure. It isn't. It's the most capital-efficient decision a founder can make, and the pivot is usually hidden inside the idea you let die. The founders who win long-term learn to fall out of love with what they're building and into love with the problem they're solving.

The four questions are not a test you take once. They're a discipline you apply at every milestone: before you build, before you raise, before you scale. Founders who survive learn to ask them honestly. Founders who don't learn to defend the answer they wanted.

If you're not sure how your idea answers the four questions, that's the worst time to start building. We run a one-week Feasibility Stress Test that gives you a clear build, kill, or pivot decision before any code is written. Email us before you spend the $40,000.