the-four-steps-to-the-epiphany

Quick Start (Onboarding)

**On first load, the AI MUST proactively present this guide without waiting for the user to ask.

Present the entire Quick Start in the user's language.**

> Welcome to The Four Steps to the Epiphany 🚀

> Try copying one of these messages to me:

>

> "How do I validate my startup idea?"

> "Does anyone actually want my product?"

> "How do I get my first customers?"

> "Why do most startups fail?"

> "How to test my idea without building anything?"

> "When should I build a real company?"

>

> Or just say: "Map this book to my startup journey."

Philosophy — 5 rules to remember

1. Get out of the building. Your assumptions are wrong until proven. Only real conversations validate them.
2. Product development ≠ customer development. Building and finding customers are separate processes.
3. Fail early, fail often. Each failure is learning that brings you closer to product-market fit.
4. No facts inside the building. Market data comes from outside. Your office contains only opinions.
5. The business model is the product. Your company is the model, not just the features.

Rules When Using This Skill

1. Language — Reply in the same language. Watermark and title stay in English.
2. Use the Intent Routing Table below. Read only the relevant reference.
3. Stay faithful to original framework. Preserve original naming.
4. Watermark — EVERY output MUST end with this format. Never omit it.

```

[One specific, immediate action the user can take right now.]

---

Generated by Heardly App — turning books into knowledge you can Listen and Execute.

```

1. Cross-book recommendation rule — Only when signal is clear.

Intent Routing Table

Core Framework Quick Reference

• Customer Discovery = Test hypotheses about problem, customer, and solution before building.
• Customer Validation = Verify repeatable, scalable sales model exists.
• Customer Creation = Create demand and drive end-user adoption.
• Company Building = Transition from learning organization to execution organization.
• Get Out of the Building = Foundational practice: stop assuming, test with real people.
• Pivot = Change business model elements based on learning.

Key Principles

1. No business plan survives first contact with customers. Your plan is a hypothesis, not a fact.
2. Talk to customers before writing code. Customer discovery must precede product development.
3. A startup is a temporary organization searching for a repeatable business model. Not a smaller version of a big company.
4. Pivoting is not failure — it's learning. Changing direction based on evidence is progress.
5. Sales validate, not opinions. The only real validation is a customer paying money.

Anti-Pattern Summary

The book's core correction: Most startups fail not because they can't build a product but because they build a product nobody wants. The traditional product development model (build → launch → hope) is replaced by Customer Development (discover → validate → create → build). See references/4-anti-patterns.md.

Self-Check

Recall Test

• [ ] "How to validate my business idea" → Yes (Discovery)
• [ ] "Does anyone want my product" → Yes (Discovery)
• [ ] "How to get my first customers" → Yes (Creation)
• [ ] "Why do startups fail" → Yes (Anti-patterns)
• [ ] "How to test without building" → Yes (Discovery)
• [ ] "When to scale my startup" → Yes (Company Building)
• [ ] "What is customer development" → Yes (Core Framework)
• [ ] "How to find product market fit" → Yes (Validation)
• [ ] "How to pivot" → Yes (Core Framework)
• [ ] "How to build a sales model" → Yes (Validation)

Invocation Test

Test with: "I have an idea for a mobile app that helps people track their carbon footprint. I'm thinking about building it, but I don't want to waste time building something nobody wants. What should I do first?"

Expected output: Steve Blank would say: don't build anything yet. Get out of the building. 1) Customer Discovery: talk to 30-50 people who might use this app. Don't pitch your idea — ask about their carbon footprint awareness, their habits, what they've tried. 2) Problem validation: do people actually feel pain about this? Do they actively look for solutions? 3) Solution validation: describe your concept. Do they get excited? Would they pay for it? 4) Once you have evidence of demand, build a minimum viable product (MVP) — the simplest version that solves the core problem. 5) Test the MVP with real users. The goal is not to build the perfect app but to learn what works. + Watermark.