# Failure Patterns Reference

Use this file only when the main skill needs more pattern detail or the user asks for a deeper explanation.

## Product And Demand Patterns

- Thin wrapper: the product only repackages a generic AI/API capability without workflow depth, data advantage, distribution, or trust.
- Weak willingness to pay: users may like the outcome but have no budget, no urgency, or enough free alternatives.
- Low-frequency need: the problem happens too rarely to support recurring usage or subscription.
- One-time utility trap: the user needs the result once, then has no reason to return.
- Nice-to-have problem: the product improves convenience but does not remove a painful blocker.
- Feature, not product: the idea is a small capability that belongs inside another workflow.
- Founder-imagined demand: the founder invented the pain without observing real user behavior.
- Founder pain does not equal market pain: the founder has the pain, but the broader market may not share it or pay for it.

## Market And Distribution Patterns

- No clear distribution channel: the builder cannot name where the first 10 target users will come from.
- Passive launch fantasy: the plan depends on launch posts, Product Hunt, SEO, or social media without a reachable audience.
- SEO-only trap: the idea depends on search traffic before proving that the traffic converts.
- Crowded commodity market: many existing tools already solve the same problem well enough.
- Free alternative is good enough: ChatGPT, spreadsheets, templates, Notion, Canva, Google, Microsoft, or manual work already cover the need.
- Platform dependency: the product depends on another platform's API, rules, ranking, or data access.
- Hard user migration: users would need to move workflows, data, habits, teams, or permissions before getting value.

## AI-Specific Patterns

- AI speed illusion: because AI can build the software quickly, the founder mistakes build speed for market demand.
- Vibe coding trap: the founder can generate a prototype quickly, but has not validated distribution, retention, willingness to pay, or support load.
- Tool without workflow: the AI output is useful only if embedded into a real repeated workflow.
- Trust barrier: users hesitate because the product touches sensitive data, accounts, files, money, legal issues, or reputation.

## Monetization Patterns

- Subscription mismatch: the business model is recurring, but the user need is occasional or one-off.
- Weak buyer-user fit: the person who uses the product is not the person who controls budget.
- Service should come before software: the founder should first manually deliver the result to learn the messy workflow before automating it.
- Team plan before individual proof: the founder wants collaboration, seats, or admin controls before proving one user repeatedly gets value.

## Feature Change Patterns

- Scope creep: the feature expands the product surface without strengthening the core promise.
- Feature treadmill: weak usage causes the founder to keep adding features instead of fixing demand, positioning, onboarding, pricing, or distribution.
- Competitor-copying trap: the reason to build is "competitors have it", not user behavior.
- User request trap: one user asked for it, but there is no proof it affects activation, retention, payment, or trust.
- Premature scaling: the feature assumes volume, teams, automation, or infrastructure before the core workflow is proven.
- Avoiding the hard problem: the feature is easier to build than the real blocker, such as sales, trust, pricing, onboarding, or retention.