Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
The last two sins are the founder sins. #10 (not planning to fail) is hubris — the belief that v1 will work. #11 (developing technology not products) is ego — the desire to be impressive over the desire to be useful. They're the hardest to catch because they're not project-level decisions; they're personality patterns. The cure is structural — make failure planning and product orientation institutional habits, not founder vibes.
The last two sins and how they wreck startups specifically.
SIN #10: NOT PLANNING TO FAIL
The pattern:
All scenarios in the plan assume v1 works.
No contingency for: dead chip, failed cert, factory delay, supplier issue.
When (not if) one of these hits, the team is paralyzed.
Cohen's framing:
You will have unknowns. You will not be able to enumerate them. But you
can budget time + money for "things we couldn't predict" — a 20% buffer
on everything important.
More importantly: have a Plan B for each major dependency.
- Chip: identify a backup-compatible chip.
- Supplier: pre-qualify two.
- Certification: know what happens if v1 fails the cert (resubmit cost,
schedule impact).
- Critical engineer: ensure no single point of failure.
HARDWARE TRACK:
Cohen's specific example: startup builds connected device with a
custom Wi-Fi/BLE chip from a single vendor. Vendor announces EOL
mid-project. No backup chip, no plan B. Re-spin: 6 months.
Pre-qualify a second source for every critical component. The cost is
worth more than the security.
SOFTWARE ANALOGUE:
Same pattern, different specifics:
- Single cloud vendor (AWS / GCP / Azure) — what if outage?
- Single auth provider (Auth0 / Clerk / Cognito) — what if their
pricing changes 10x?
- Single payment processor (Stripe) — what if they freeze you?
- Single key engineer with all the system knowledge.
Plan B for each:
- Multi-cloud abstraction (or at least, a "what if AWS is down" plan).
- Auth interface designed for replacement.
- Payment routing logic.
- Documentation + rotational ownership.
SIN #11: DEVELOPING TECHNOLOGY RATHER THAN PRODUCTS
The pattern:
Founder is obsessed with a cool technical capability.
Product is built TO SHOWCASE the tech.
Market doesn't care about the tech; they care about a problem.
Founder doubles down on "marketing this better."
Two years and $5M later, no customers.
Cohen's framing:
Customers don't buy technology. They buy outcomes.
The product question is: "What user outcome does this enable?"
Not: "Look at this clever thing."
If you can't articulate the outcome in user words (not engineer words)
in one sentence, you have Sin #11.
HARDWARE TRACK:
Cohen's specific example: founder builds device using neural network
on edge silicon (cool!). Markets it as "AI-enabled" + a generic spec
list. Customer hears: meh.
Re-frame: same product, market as "the only device that warns you
before a fall." Same tech. Different framing. Different outcome.
SOFTWARE ANALOGUE:
Even more common in software:
- "Built on blockchain!" (customer: I don't care)
- "Powered by GPT-4!" (customer: I don't care)
- "Microservices architecture!" (customer: I don't care)
Customer cares about: faster, cheaper, less work, fewer surprises.
Translate the tech into that frame.
THIS MODULE'S FOCUS:
Two diagnostic questions for your current project:
1. If [critical dependency X] failed tomorrow, what would we do?
(No good answer → Sin #10 live.)
2. Can the value of the product be stated in plain-language outcomes
without naming any specific tech?
(No → Sin #11 live.)
Honest self-diagnosis is the entire game here.