# ShipFit — full content feed (llms-full.txt)
> Machine-readable full-content dump of every indexed ShipFit page, generated
> at build time from the canonical MDX source. AI assistants can ingest this
> file in one fetch instead of crawling the site page by page.
>
> Spec: https://llmstxt.org
> Curated entry point: https://shipfit.ai/llms.txt
> Last built: 2026-08-15
---
## Validate Your Business Idea (the master pillar + 7 spokes)
### AI for Idea Validation: How to Get Real Signal, Not AI Slop
URL: https://shipfit.ai/validate-your-business-idea/with-ai
> AI tools default to flattery. Here's how to use them for real validation work without drowning in AI slop. Prompts, workflow, and what AI can't replace.
## Why default AI gives you slop, not validation
You type your startup idea into ChatGPT or Claude. The response: "That's an interesting idea! Here are 10 reasons it might work..."
That feels useful. It isn't. That's **AI slop**: fluent, agreeable, plausible-sounding text with no real signal in it. The AI is doing what its training pushes it to do: be helpful, mirror your enthusiasm, generate output that humans rate well. The same response pattern that makes AI assistants pleasant for general use makes them actively harmful for idea validation, where you need the opposite of encouragement.
The training pipeline behind every consumer LLM has the same problem. RLHF (reinforcement learning from human feedback) optimizes for responses that humans rated as good. Humans, like all humans, rate agreeable responses higher than disagreeable ones. The model learns agreement gets reward. Then you ask it whether your startup idea is good, and it ships you slop. Polite, well-formatted, structurally similar to analysis, but with no actual judgement underneath.
This guide is about getting around that.
## The three patterns that actually work
When prompting AI for validation work, three patterns reliably surface real signal:
### Pattern 1. Explicit counter-prompt
You name the role and the bias explicitly:
> "You are a brutally honest pre-seed investor who's seen 1,000 startups fail. For the idea below, tell me the 5 strongest reasons it would fail, with specific failure patterns from comparable historical startups. Do not include positive framing. If your answer includes encouragement, restart."
The "if your answer includes encouragement, restart" line matters. Without it, the model will hedge ("there are challenges, but...") and lose the signal.
### Pattern 2. Constraint-based
You explicitly forbid the positive framing:
> "Respond only with the kill signal. If you would say something positive about this idea, say nothing instead. Reasons to walk away only."
This produces shorter, harsher output. Useful when you want a quick gut-check before a deeper validation pass.
### Pattern 3. Pattern match against failures
You force the model to retrieve from its training data's failure cases:
> "Find the 3 most similar startups to this idea that failed. Explain why each failed in plain operational terms (e.g., 'they ran out of cash because CAC was too high'). Then assess whether THIS idea avoids those specific failure modes."
This works because the model's training data includes a lot of post-mortems. Most public startup analysis is written about failures, not successes, so the model has more failure-pattern data than success-pattern data. Use that.
## What AI is good for in validation
Five jobs where AI accelerates the work without compromising the outcome:
### Job 1. Interview question generation
Given a buyer persona and a hypothesis, AI generates a tuned set of Mom Test questions. Faster than starting from scratch; matches your specific context better than a generic template.
Sample prompt:
> "Generate 15 Mom Test customer interview questions for [buyer persona] about [problem]. All questions must be past-tense and behavioral, not future-tense or hypothetical. Output as a numbered list."
### Job 2. Stress-testing your assumptions
You write down what you believe; AI plays devil's advocate.
> "Here are my 5 assumptions about [buyer]. For each one, identify the strongest counter-evidence I should look for in interviews to test it. Be specific about what kind of buyer behavior would invalidate each assumption."
### Job 3. Synthesizing interview transcripts
After 15 buyer interviews, you have hours of transcript. AI extracts patterns.
> "Here are 15 interview transcripts about [problem]. Identify (a) the 3 most common pain phrasings buyers used (verbatim), (b) the 2-3 buyer segments that show different behavior patterns, (c) any contradictions between what buyers said and what they described doing."
The "verbatim phrasings" output is gold. It's your marketing copy, in your buyer's actual words.
### Job 4. Drafting Van Westendorp surveys
The four-question Van Westendorp methodology is hard to phrase well. AI generates the buyer-specific version.
### Job 5. Stress-testing your pricing rationale
> "I'm pricing this at $X/month. Here's my unit economics math. Here's the buyer profile and willingness-to-pay data. Identify the 3 strongest objections a prospect would raise, and for each, tell me whether my justification holds."
## What AI cannot do
Five things no LLM can do, regardless of prompt sophistication:
### Cannot 1. Generate real buyer commitments
A pre-order, a paid deposit, a signed LOI. These require a buyer's wallet and signature. AI cannot conjure them. The single most important output of validation (real behavioral commitments) is fully human.
### Cannot 2. Read body language and silence
In a customer interview, half the signal is what the buyer DOESN'T say. The hesitation, the pause, the rephrase. AI conversations have none of this. Don't ask AI to "act as a customer" and interview itself. The output looks plausible and tells you nothing about real buyers.
### Cannot 3. Predict YOUR market timing
AI's training data is historical and tends to lag the present by months or years. Your market's "why now" answer depends on a present-tense trend you can verify with your own eyes. AI can speculate, but it can't tell you whether the wave is cresting now or already past.
### Cannot 4. Tell you whether you can execute
"Should I build this?" includes a question only you can answer: can you build this, do you want to, do you have the runway? AI doesn't know your circumstances, your motivations, or your bank account. Be careful when AI tells you "you should build X". It has no information to make that call.
### Cannot 5. Detect when your interviews are biased
If you've been pitching too early in your customer interviews (contaminating them), AI reading the transcripts later can't always detect the bias. It just sees what the buyer said. The "watch yourself in real time" job is fully human.
## The honest mental model
AI is a force multiplier for the planning, structuring, and synthesis work. It is not a replacement for the validation work itself.
| Work | Who does it |
|---|---|
| Generating interview questions | AI (assisted) |
| Running the interviews | Human |
| Reading body language during interviews | Human |
| Synthesizing 15+ transcripts | AI (with human review) |
| Designing pre-order tests | AI (assisted) |
| Asking buyers to pre-order | Human |
| Getting credit cards on file | Human |
| Computing willingness-to-pay band | AI (from human-collected data) |
| Stress-testing your pricing | AI |
| Deciding whether to ship V1 | Human (with AI advisory) |
The split looks roughly like: AI handles 40-60% of the prep and synthesis time; humans handle 100% of the buyer-facing work.
## How ShipFit uses AI
ShipFit's 9-stage flow is built on this split:
- **Interview questions** for stages 2 (Who Pays?), 3 (What Hurts?), 7 (Will They Pay?) are AI-generated from your buyer + hypothesis inputs.
- **Framework lenses** at every stage (Mom Test, JTBD, Van Westendorp, 7 Powers, MoSCoW) shape the AI's diagnostic questions against your decisions. Thin or contradictory inputs surface as Areas to Clarify on the Quick Take.
- **Synthesis** of any logged interview takeaways into stage outputs.
- **Stress-testing** at every stage: the AI flags when a decision is weakly-supported.
- **Exports** at stage 9: the AI generates either a **Universal Prompt** (one prompt for any AI chat: ChatGPT, Claude, Gemini) or tool-specific configurations: `.cursorrules` + domain rules for Cursor, `CLAUDE.md` + slash macros for Claude Code, `.windsurfrules` + pin guide for Windsurf, plus presets for v0.dev, Lovable, Replit, and Gemini/Antigravity. The validated decisions land directly in your dev environment instead of dying in a Notion doc.
What ShipFit explicitly does NOT do:
- Run the interviews for you (humans only)
- Generate fake buyer commitments (humans only)
- Tell you to ship something it hasn't pressure-tested (the framework checks gate this)
- Be agreeable when your answer is weak (the framework checks override the LLM's default slop)
The result: AI accelerates the work without compromising the signal.
## Common mistakes when validating with AI
**1. Treating AI feedback as ground truth.** It isn't. AI tells you what's plausible given its training data. Ground truth comes from buyers.
**2. Not counter-prompting.** Default-prompted, the AI will encourage you. Force the brutal-honesty mode every time.
**3. Asking AI to simulate buyer interviews.** The simulation is convincing and useless. Real interviews surface the unexpected; simulations only surface what the model can already predict.
**4. Using AI to convince yourself an idea is good.** You can always get the AI to agree if you prompt it long enough. That's not validation; that's confirmation bias with an electric assistant.
**5. Skipping framework checks.** AI without a framework is a vibes engine. Framework checks (Mom Test, JTBD, etc.) are what make the AI's output structured and defensible.
## The bottom line
AI is a useful tool in idea validation if you use it for the parts of the work it's actually good at (structuring, synthesizing, pressure-testing) and keep it out of the parts where it can only give you confirmation bias dressed as analysis. Default-prompted AI tells you what you want to hear. Counter-prompted AI tells you what you need to hear. The discipline is mostly in the prompting, the framework checks, and the willingness to do the real human work that no LLM can do for you.
### Competitive Analysis for Early Ideas: The Honest Version
URL: https://shipfit.ai/validate-your-business-idea/competitive-analysis
> Competitive analysis for pre-launch ideas. The 7 Powers lens, substitute-identification, and underserved-niche test every founder claims to pass but few do.
## Why most early-stage competitive analysis is theater
The default founder competitive analysis is a 2x2 with axes like "Easy to use" and "Affordable" and your product placed conveniently in the upper-right quadrant. That diagram tells investors nothing and operationalizes nothing. It's a hand-wave dressed as analysis.
Real competitive analysis answers two questions:
1. **Where in the market is there a buyer segment that every existing player is failing?**
2. **Once you ship, what defensible advantage prevents the incumbents from crushing you?**
If you can't answer both, the right move is to keep researching, not to start building.
## The three-list exercise
A focused 60-90 minute pass.
### List 1. Direct competitors
Same product, same buyer. Examples for a hypothetical pre-code validation tool:
- Buildpad
- Validator AI
- Idea Validator (UseSaaSKit)
- ChatGPT used for validation conversations (technically not direct, but it's eating the same buyer's mindshare)
For each: pricing, recent funding (Crunchbase), employee count (LinkedIn), growth signal (BuiltWith for tech-stack adoption; SimilarWeb for traffic. Both have free tiers), top 3 complaints in their 3-star reviews.
### List 2. Substitutes (the underrated category)
Different product, same job. For pre-code validation, substitutes include:
- "Just talking to a few friends"
- Spreadsheet-based DIY market sizing
- Books (*The Mom Test*, *Lean Startup*, *Sprint*)
- Strategy consultants ($5K-$25K per engagement)
- "Just start building and figure it out"
- Asking an AI assistant generically
These are usually MORE entrenched than direct competitors because they're zero-friction and habit-embedded. "Just talking to friends" doesn't have a sales process you can disrupt. It's the buyer's default behavior. Your job is to make your product enough better than the default that the buyer changes habits.
### List 3. Adjacent players
Players one step away who could enter your market on a side-quest. For pre-code validation:
- Notion (could ship a "validation template" pack)
- Linear (could add a planning surface)
- ChatGPT (already eating part of this market)
- HubSpot (could bundle a validation module with its CRM)
If any adjacent player could ship your core feature in a quarter, that's a real threat to your defensibility. Plan for it.
## The 7 Powers screen
Once you have the three lists, ask: when this business matures, which of [Hamilton Helmer's 7 Powers](/frameworks/7-powers) will I have?
- **Scale economies**. Unit cost drops as you grow (rare for early-stage SaaS; more relevant for marketplaces and infra)
- **Network economies**. The product gets more valuable as more people use it (Facebook, Slack, eBay)
- **Counter-positioning**. Your business model is something an incumbent can't copy without cannibalizing themselves (Netflix vs Blockbuster, Stripe vs legacy)
- **Switching costs**. Once a customer is in, leaving is painful (Salesforce, Workday, accounting tools)
- **Branding**. Buyers prefer you for non-functional reasons (Apple, Stripe at this point)
- **Cornered resource**. You have exclusive access to something competitors don't (patent, licensed data, regulatory approval)
- **Process power**. Accumulated organizational know-how that's hard to replicate (Toyota's production system, classic example)
For new entrants, the realistic answer is almost always **counter-positioning**. You're not big enough for scale, not networked enough for network effects, no switching costs because nobody's using you yet, no brand yet, no cornered resource, no process at scale. What you can have: a business model that incumbents structurally can't copy.
If your honest answer to "which 7 Power will I have?" is "the product is better," you don't yet have a moat. Better products lose to worse products with moats all the time.
## Finding the underserved niche
The most common path to counter-positioning for early-stage startups is finding the specific buyer segment that every existing player is failing.
Three search patterns:
**Pattern 1. Pricing mismatch.** Existing players priced for enterprise; mid-market or SMB or solo gets ignored. Stripe's first wave was developers ignored by Authorize.net and BluePay (both priced for big merchants). Linear's first wave was small dev teams ignored by JIRA (priced for enterprise).
**Pattern 2. Complexity mismatch.** Existing players are powerful but hard to use; the underserved segment wants simple. Notion vs Confluence. Carrd vs Webflow.
**Pattern 3. Job-to-be-done mismatch.** Existing players are technically the same category but solving a different job. Calendly vs Microsoft's built-in calendar scheduling. Same category (scheduling), different job ([JTBD](/frameworks/jobs-to-be-done): "schedule a meeting with someone outside my org without 4 emails").
To find the underserved niche, read 1- and 3-star reviews of every direct competitor on G2, Capterra, Trustpilot. Pattern-match the complaints. Three or more independent reviewers saying the same thing is signal. The complaint pattern names the underserved segment.
## When there are no direct competitors
If your three-list exercise turns up zero direct competitors, treat it as a yellow flag, not a green one.
Possibilities, in decreasing order of likelihood:
1. **The problem isn't painful enough.** Buyers haven't been willing to pay for solutions, so the market hasn't formed. Test this by going deep on the [Mom Test](/frameworks/mom-test). If buyers can't describe spending real money/time on this problem in the past, you're inventing a market.
2. **The market is too small.** Existing players didn't bother because the SOM is too low. Run the [market research](/validate-your-business-idea/market-research) numbers honestly.
3. **You're early.** Genuine first-movers exist but they're rare. If you're confident the timing is right, your [market research "why now"](/validate-your-business-idea/market-research) answer should explain why incumbents can't or won't enter quickly.
4. **You've defined the category wrong.** The competitors exist but in a different framing. Reframe your buyer's job-to-be-done and the competitors usually appear.
Genuinely uncontested markets are 5-10% of "no direct competitors" claims. The other 90-95% of the time, founders just haven't looked hard enough.
## Common mistakes
**1. The 2x2 with you in the corner.** Useless. Tell me the buyer segment and the JTBD instead.
**2. Ignoring substitutes.** Spreadsheets and "do nothing" beat your product more often than direct competitors do.
**3. "Our advantage is the product is better."** Better products lose to worse products with moats every day. Pick a power.
**4. Underestimating adjacent players.** A well-funded adjacent player who can ship your feature as a side-quest is your real long-term competitor, not the lookalike startup in your wedge.
**5. Doing competitive analysis once and never updating.** Markets shift fast in software. Redo every 6 months minimum.
## What ShipFit does at this stage
Stage 4 of the [9-step playbook](/validate-your-business-idea) is **How to Win?**. The output is a single **THIS WINS** card: the one solution approach that scores highest on Opportunity, Viability, and Feasibility, and that solves all of your above-the-line problems. Each card includes:
- **Why this wins**: three crisp reasons (e.g. *Laser-focused ROI claim*, *Zero-friction workflow*, *Deep integration*)
- The category tags that frame the angle (Browser Extension + Jobs-to-be-Done + LTSE)
- A description of how the product behaves in the real workflow it inserts itself into
- **Problems this solves**: the 3 above-the-line pains it covers, with the exact wording from your buyer interviews
Under the hood:
1. The three-list scaffold (direct competitors, substitutes, do-nothing) generated from your buyer persona and category inputs.
2. Public data points on direct competitors (funding, employee count, pricing tier) sourced from the citations attached to the output.
3. The 7 Powers lens applied so each solution approach (Stage 4) is mapped to a candidate power, not just a feature claim.
4. Competitor weakness signals — sourced from Reddit, G2, Trustpilot, App Store, Play Store, Capterra — surfaced as candidate openings you could win against.
When the analysis surfaces "no power available, no underserved niche, market mature," the verdict at Stage 1 will reflect that. Most founders skip this step and find out the hard way 12 months later.
## The bottom line
Competitive analysis isn't a slide. It's the answer to: "where in the market is the buyer everyone's failing, and once I serve them, what stops the incumbents from crushing me?" If you can't answer both. Specifically, by name and by 7 Power. Your competitive position isn't real. It's hope. Hope is not a strategy.
### Idea Validation: What It Is and What Most Founders Get Wrong
URL: https://shipfit.ai/validate-your-business-idea/idea-validation
> Idea validation isn't asking friends if they like it. It's behavioral proof: money down, calendar time, signed letters of intent. The threshold that counts.
## What "validate" actually means
The word "validate" gets used to mean two completely different things, and the gap between them is where founders lose 6-12 months of their life.
**Definition A (what most founders think):** Validation = "I told some smart people about my idea and they said it sounded good."
**Definition B (what actually works):** Validation = "I generated behavioral evidence that real buyers will pay for this solution. The evidence cost them something. Money, time, or reputation. Not just words."
Definition A is free. It's also useless. People are polite, especially smart people, especially in a 1-on-1 conversation where you've already invested visible effort. They will encourage you. They will not pay for your product, but they will encourage you, and most founders mistake the encouragement for the prediction.
Definition B is what this guide covers. It's harder to get. It's also the only kind of validation that correlates with shipping a product anyone buys.
## The four methods that actually produce signal
Listed in increasing order of evidence strength.
### Method 1. Mom Test interviews (informational)
The [Mom Test framework](/frameworks/mom-test) by Rob Fitzpatrick (2013) is the foundation. The rule: never mention your idea. Ask about the buyer's life, their past behavior, their current workarounds. The questions that produce signal are past-tense and specific:
- "Tell me about the last time you had to solve [problem X]."
- "What did you do? Walk me through it step by step."
- "How much time did it take? How much did it cost?"
- "Who did you talk to about it?"
- "What did you try that didn't work?"
What you're looking for: at 10+ interviews, do three or more unrelated buyers describe the same pain in the same words? If yes, you have a real problem worth solving. If no, you have either the wrong buyer profile or the wrong problem framing.
What this method does NOT prove: that they will pay you. That's the next two methods.
### Method 2. Fake Door Test (light commitment)
A **Fake Door Test** is a landing page for a product that doesn't exist yet. Drive real traffic to it. See who actually tries to buy. The actions visitors take tell you whether there's real demand, or just polite interest.
**The brutal truth: people lie about what they'll buy.** Only actions with friction count. Surveys, upvotes, and "I'd definitely use this" are noise.
Not all engagement is equal. Someone entering a credit card proves more than someone clicking "like." So when you read the results, weight the signals by how much commitment each one took:
| Signal tier | What counts | Weight |
|---|---|---|
| **🥇 Gold** | They tried to pay you. Credit card entered, deposit made, payment attempted. Pre-order with payment, deposit collected, annual plan purchased. | 100% |
| **🥈 Silver** | Real commitment, no money yet. Booked a demo, filled a detailed form, gave a phone number, accepted a calendar invite. | 70% |
| **🥉 Bronze** | Time + effort spent. Watched the full demo video, returned to the page 3+ times, read the long-form FAQ. | 30% |
| **🚫 Worthless** | Email signup with one field. "Notify me when it launches." Upvotes. Likes. Survey "yes I'd pay for this." | 10% |
How to read the page:
1. **Drive ~500–2,000 targeted visitors** from a single source (ad campaign, Twitter post, niche community post). Mixed-source traffic muddies the signal.
2. **Calculate a weighted conversion rate** using the tiers above. A page that converts 3% to Gold is wildly stronger than one that converts 30% to Worthless.
3. **Anything above 1% Gold-tier conversion is a strong indicator.** Below 0.5% Gold means people like the idea but won't pay for it. Which is the same as "won't buy" once it's real.
The trap most founders fall into: counting Worthless-tier signal as validation. Email signups have weak correlation with revenue because the friction is too low. Anyone signs up for things. Almost nobody types in a credit card.
ShipFit's Stage 7 (Will They Pay?) uses this exact tier system. The output is a Smoke test plan with the Gold / Silver / Bronze / Worthless signal weights laid out, so when you run the Fake Door test yourself you're not counting Worthless-tier engagement as validation.
### Method 3. Paid pre-orders (real commitment)
Ask buyers to pre-pay, even at a discount. This is the strongest signal short of an actual product launch.
The number that matters isn't "how many pre-orders did you get." It's "what conversion rate from interested-buyer-conversation to pre-order did you achieve." 3-5+ pre-orders from 30 conversations is meaningful. 1 pre-order from 100 conversations is a no.
Stripe makes this easy: take pre-order payments as `setup_intent` (no charge until launch), or use a "deposit" pattern (refundable amount that proves intent without committing the buyer to a launch date you might miss).
### Method 4. Signed letters of intent (B2B only)
For B2B SaaS, an LOI is a non-binding written commitment from a buyer that, when product X exists at price Y, they will buy. It includes the buyer's signature and contact info, and ideally specifies expected contract size.
LOIs are the gold standard for B2B validation because they require sign-off from someone with at least nominal budget authority. If you can't get an LOI, you can't get the eventual sale either. The friction is the test.
Realistic target: 3-5 signed LOIs from your target buyer profile before you build. If 10 enterprise sales conversations produce zero LOIs, your buyer profile, pricing, or value prop is wrong.
## What doesn't work (and why)
These methods feel like validation but produce no useful signal:
**Surveys**. Stated preference and revealed preference are different species. People say they'll pay for things they'll never pay for, and vice versa. Survey data has near-zero correlation with revenue. The only useful "survey" is the one Rahul Vohra developed at Superhuman ([read more on the Superhuman PMF Engine](/frameworks/superhuman-pmf-engine)). And that one is administered AFTER product launch to existing users, not pre-launch to strangers.
**Friends and family interviews**. Friends are polite. Family is more polite. They want you to succeed and will say what they think helps. If your validation set is your closest 6 founder friends, you have validated absolutely nothing. You've collected encouragement.
**Counting upvotes / likes / followers**. Vanity metrics. Eric Ries's term in [The Lean Startup](/frameworks/lean-startup-validation) (2011). They feel like progress. They correlate weakly with revenue at best.
**"I'd use that" responses to a pitch**. The moment you pitch, the conversation contaminates. Useful interviews never include a pitch in the first 25 minutes. The Mom Test exists to operationalize this.
**Influencer endorsements**. A well-known person saying nice things about your idea is helpful for distribution later, but it's not validation. Influencers will support things they'd never personally pay for.
## The signal threshold (when you're "validated enough")
Use this as a gate before writing any production code:
**Four conditions, all required:**
1. **10+ buyer conversations** with people who match your defined persona (not friends, not vague "potential users").
2. **At least 7 of them described the pain in their own words**, without you prompting or pitching first.
3. **At least 3 of them committed to pay**. Pre-order, deposit, or signed LOI for B2B. At your proposed price point.
4. **You have a "why now" answer** that doesn't depend on a hypothetical future trend. The market timing has to be present-tense.
Below all four conditions: not validated. Don't write production code yet. Stay in interview mode.
Above all four: write the MVP. The validation work is done; product execution is the next risk.
## Common mistakes that ruin validation
**1. Pitching too early.** Founders mention their idea in the first 5 minutes. The interview is then useless because the buyer is now reacting to the idea, not describing their actual life. Hold the pitch until the last 5 minutes, and only pitch if you need a commitment.
**2. Asking hypotheticals.** "Would you use this?" predicts nothing about whether they would, in fact, use this. Replace every hypothetical with a past-tense behavioral question.
**3. Mistaking interest for intent.** "Sounds cool" is not intent. "Here's $50 for the first version" is intent. Stop confusing the two.
**4. Stopping at 3-5 conversations.** Pattern emerges around 10-15. Anything less is anecdote. The brain wants to declare victory at 3 conversations because doing 12 is harder. Push through.
**5. Building before defining the buyer.** Validation that isn't tied to a specific buyer persona is meaningless. "Founders" isn't a buyer. "B2B SaaS founders running pre-seed startups in Europe who haven't shipped yet" is. Get the buyer specific in [stage 2 of the playbook](/validate-your-business-idea) before you start any validation work.
## Where this fits in the 9-stage playbook
Idea validation isn't one stage in the [ShipFit 9-step flow](/validate-your-business-idea). It's the methodology that runs through stages 1-7. The flow is:
- Stage 1 ([Worth Building?](/validate-your-business-idea/market-research)) — Market verdict. TAM/SAM/SOM, competitor landscape, and a "why now" trend check. First cut at whether the market exists at all.
- Stage 2 (Who Pays?) — Primary buyer. Proto-personas paired with willingness-to-pay and LTV/CAC estimates so the buyer is named with enough economic precision to drive every later stage.
- Stage 3 (What Hurts?) — Core problems, ranked. Mom Test discipline + Do-Say Gap analysis applied to surface the pain points by frequency × intensity. The output is your above-the-line problem list.
- Stage 4 ([How to Win?](/validate-your-business-idea/competitive-analysis)) — Solution approach. 3 candidate solutions scored on problem-solution fit, each mapped to a moat via [7 Powers](/frameworks/7-powers) + [Blue Ocean Strategy](/frameworks/blue-ocean-strategy).
- Stage 5 ([What's V1?](/validate-your-business-idea/mvp-scope)) — MVP scope. [MoSCoW](/frameworks/moscow) + Feasibility-Impact applied to feature candidates, producing three MVP packages (Lean / Balanced / Full) so the scope-vs-effort tradeoff is explicit before you commit.
- Stage 6 ([How to Charge?](/validate-your-business-idea/pricing-validation)) — Pricing model. [Van Westendorp PSM](/frameworks/van-westendorp) produces a defensible price band; the Pricing Position chart places your candidate price against the competitor pack.
- Stage 7 (Will They Pay?) — Demand proof. Smoke test plan + pre-sales playbook (pre-orders, deposits, LOIs, Fake Door conversion) — the behavioral evidence that runs *before* the build commitment.
Each stage's output feeds the next. Skipping a stage means the one after it runs on assumed inputs, which is how 9-stage playbooks turn into 18-month build cycles for products nobody buys.
## What ShipFit does at this stage
ShipFit doesn't run the interviews for you (no software can). What it does:
1. **Generates a buyer-specific question set** for Stage 3 (What Hurts?) — Mom-Test-style questions phrased in past-tense behavior, tuned against the buyer profile you defined at Stage 2.
2. **Captures and synthesizes your interview takeaways** alongside the framework lenses (Mom Test, [JTBD](/frameworks/jobs-to-be-done)), so the pain points feed into Stage 4's solution approaches and Stage 5's MVP scoring.
3. **Outputs a Smoke test plan and Pre-sales playbook at Stage 7** with the Gold/Silver/Bronze/Worthless signal tiers and behavioral validation criteria — the framework you run against your own data once buyers see it.
4. **Generates handoff artifacts at Stage 9** — Universal Prompt or tool-specific exports for Cursor, Claude Code, Windsurf, v0, Lovable, Replit, Gemini/Antigravity — so the validated decisions land in your dev environment instead of dying in a Notion doc.
If you've never run idea validation before, [start your playbook free](https://app.shipfit.ai/register?utm_source=shipfit&utm_medium=spoke&utm_campaign=idea-validation) and walk through stages 1-7. The free tier covers stages 1-2; the $5 Taster Pack covers all the validation work.
## The bottom line
Idea validation is unfun, slow, and ego-bruising. Building is fast, dopaminergic, and feels like progress. The founders who shipped products people bought spent more time on validation than building. The founders who shipped products nobody bought did the opposite.
The math is brutal but simple: 2-4 weeks of validation saves 6-12 months of building the wrong thing. Skip it and you join the [35-38% of failed startups that cite "no market need" as the cause](/validate-your-business-idea). Run it and you find out, cheaply and early, whether the idea you're committed to is one worth committing to.
### MVP Scope: How to Define V1 Without the Feature Trap
URL: https://shipfit.ai/validate-your-business-idea/mvp-scope
> MVP scoping that survives contact with reality. MoSCoW + ICE applied honestly, the impact-effort matrix, and the test for whether a feature belongs in V1.
## The MVP that wasn't
The most expensive mistake in startup history isn't building the wrong product. It's building the right product but at version 1.3 instead of version 1.
The founder who knows what to build but ships the polished, feature-complete, "ready" version of it 6 months late has lost the same battle as the founder who built the wrong thing. They've burned the runway, they've missed the market timing, and they've never tested the hypothesis that V1 was supposed to test.
This guide is the scoping discipline that prevents that.
## The one rule of MVP scoping
For every feature you're considering for V1, ask: **"If we ship without this, does the hypothesis still get tested?"**
If the answer is yes, the feature isn't Must. It's Should-Have or Could-Have. It belongs in V2 or V3, not V1.
If the answer is no. Without this feature, we genuinely cannot tell whether buyers will pay. The feature is Must. It ships in V1.
The trap is that founders feel everything is a Must because everything sounds useful. "Users will want X" is true for almost every X. The relevant question isn't "would users want this?" It's "does the absence of this prevent us from testing whether the business works?"
## The MoSCoW gate
[Dai Clegg's 1994 MoSCoW framework](/frameworks/moscow) gives you four buckets:
## The impact-effort matrix
Once you have a candidate Must list, score each feature on two axes:
**Impact** (1-10): how much does this feature move the hypothesis test?
**Effort** (1-10): how many engineer-days to build it?
Plot them:
| Effort \ Impact | High impact | Low impact |
|---|---|---|
| **Low effort** | V1 (build first) | Skip or V3 |
| **High effort** | V1 only if hypothesis-blocking; else V2 | V4 / never |
The "high effort, low impact" quadrant is where most MVPs go to die. Engineers love these features because they're technically interesting. Founders sign off because the feature "felt important." Six months later, V1 ships with a beautifully-architected feature that didn't move the conversion needle.
The fix: be brutal about the impact score. If you can't articulate in one sentence how the feature changes the hypothesis test, the impact is below 5.
## The ICE-scoring version
[ICE scoring](/frameworks/ice-scoring) is the numerical version of the matrix:
**ICE = Impact × Confidence × Ease**
For each feature:
- Impact: how much does this move the metric (1-10)
- Confidence: how sure are you about the impact (1-10)
- Ease: how easy to build (1-10, where 10 is easiest)
Multiply. Rank. Cut the bottom 60%. The remaining 40% is V1.
The gotcha: founders inflate Confidence for pet projects. Run ICE with a co-founder or a brutal advisor. If Confidence is 9 but you can't name three pieces of evidence supporting it, the real Confidence is 4.
## What to polish vs. leave rough
V1 has finite polish budget. Spend it where the buyer's first impression forms:
**Polish:**
- Landing page (this is where conversion is won or lost)
- Signup flow
- The one core "aha moment" interaction
- Pricing page
**Leave rough (and the world won't end):**
- Admin / settings pages
- Edge-case error states
- Integrations beyond the primary 1-2
- Mobile responsiveness (if your buyer is desktop-first)
- Onboarding email sequences beyond the first welcome
The mistake most founders make: they polish the admin dashboard their internal team uses and ship a confusing signup flow. The signup flow loses 60% of would-be converts on the first session. The admin dashboard nobody sees doesn't matter.
## Scope creep. Three early warning signs
Once V1 scope is locked, watch for these:
1. **The Must list grows during the build.** This is fatal. V1 scope should ONLY shrink (when you discover something is harder than estimated and you cut it), never grow. New great ideas go to a V2 file, not into V1.
2. **Sprint reviews include "we also did X."** Engineers building features that weren't planned is a process problem. Catch it in the first sprint and don't let it pattern-set.
3. **Launch date moves back by 1-2 weeks every 2 weeks.** This is the death spiral. Each delay enables more "while we're at it" additions, which cause more delays. Break the spiral by hard-locking the launch date and cutting features instead.
## The Lean Startup connection
Eric Ries's [Lean Startup framework](/frameworks/lean-startup-validation) (2011) introduced the "build-measure-learn" loop. The MVP is the smallest build that enables one measure-learn cycle.
The two most-cited MVP examples in the book are deliberately tiny:
- **Dropbox**. Drew Houston's MVP was a 3-minute video explaining what the product would do. It tested whether the demand was real (it was. The beta waitlist exploded). No actual file-sync product was built for the MVP test.
- **Zappos**. Nick Swinmurn's MVP was buying shoes from local stores when orders came in. It tested whether people would buy shoes online (they would). No inventory was built for the MVP test.
Both validated the hypothesis at near-zero engineering cost. Both were embarrassingly small. Both worked.
The lesson isn't to literally build a video as your MVP (the bar is higher now). The lesson is: name the hypothesis V1 tests, then strip everything that isn't required to test it.
## Common mistakes
**1. Calling everything a Must.** If your Must list has 12 items, you're not scoping. You're listing.
**2. Polishing the wrong things.** Polish the conversion path. Leave the admin tools rough.
**3. No locked V1 scope.** If V1 isn't written on a wall before build starts, scope will creep. Lock it.
**4. Building before defining the hypothesis.** "What does V1 prove?" should have a one-sentence answer before any code gets written. If it doesn't, you're not building an MVP, you're building a product hoping someone will buy it.
**5. Treating the MVP as the eventual product.** V1 tests the hypothesis. V2 is the product. Mixing the two means V1 is too ambitious and V2 never gets the focus it needs.
## What ShipFit does at this stage
Stage 5 of the [9-step playbook](/validate-your-business-idea) is **What's V1?**. The output is your MVP scope, sorted into three buckets:
| Bucket | What goes here | Cut rule |
|---|---|---|
| **DIFFERENTIATOR** | The 3-5 features that make the buyer pick you over the incumbent. *"Why you pick us over the other guy. This is your bet."* | Keep all. |
| **DELIGHT** | Features users will love but can't afford yet. *"Cut first."* | Most of these go to V2. |
| **OPERATIONAL** | The plumbing required to make the Differentiators work (auth, billing, basic admin). | Keep the minimum. |
Each feature carries an ICE-style score (0-10) plus an effort tag (S/M/L), so the cut decisions are visible instead of vibes. The "Cut first" instruction on Delight is deliberate: it's the single most-resisted feedback ShipFit gives, and the single most-validated way to ship in 4-8 weeks instead of 6 months.
Under the hood:
1. Your feature wishlist gets parsed and each feature dropped into one of the three buckets.
2. [MoSCoW](/frameworks/moscow) and [ICE](/frameworks/ice-scoring) lenses applied to each feature against the V1 hypothesis you wrote.
3. Output is three MVP packages — Lean, Balanced, Full — so you can see the scope/effort tradeoff explicitly before you pick.
4. Deferred items (Delights, Shoulds, Coulds) land in a V2 file with effort tags, so the cut features are parked instead of lost.
The output drops into your dev environment via [Q9 exports](/validate-your-business-idea/with-ai): Universal Prompt for any AI chat, or tool-specific configs for Cursor + Claude Code + Windsurf + v0 + Lovable + Replit + Gemini. So the scope discipline survives the handoff to engineering.
## The bottom line
MVP scoping isn't about being minimal for minimal's sake. It's about being scoped enough to test one hypothesis, fast enough to learn before runway runs out, and disciplined enough to cut everything that doesn't serve that test. Most products fail because their V1 was actually V1.3. Don't build that one.
### Pre-Launch Market Research: Numbers Founders Actually Need
URL: https://shipfit.ai/validate-your-business-idea/market-research
> Pre-launch market research that informs decisions: TAM, SAM, SOM done honestly, market timing, why-now signals, and the competitor density that kills ideas.
## Why founder market research is mostly theater
Open any seed-stage pitch deck. Slide 3 says "the market is $200 billion." Slide 4 says "we'll capture 1%." Slide 5 says "$2 billion ARR by year 5."
That's not research. That's three numbers in a row that nobody can defend.
Real pre-launch market research answers a smaller, harder question: **can this business sustain itself with the ten-customer version of itself, and is the timing right NOW?** If yes, you have permission to build. If no, you don't.
This guide is the small-honest version. Two numbers (SOM + price) and one answer (why now). Done in a day, not a quarter.
## SOM first, not TAM first
Most founders do TAM → SAM → SOM. Top-down. The numbers come out huge and meaningless. The honest approach is the opposite: start at SOM and build up.
### Step 1. Define your buyer with painful specificity
Not "founders." Not "B2B SaaS." Something like: "B2B SaaS founders running pre-seed startups in Europe who've already raised but haven't shipped."
How many such people exist? **Count them.** Crunchbase lists every pre-seed company by geography and funding stage. LinkedIn Sales Navigator lets you filter by job title + company size + location. For the example above, the answer is roughly 2,000 people, and you can verify that within an hour.
That count IS your SOM denominator. Skip this step and every downstream number is a guess.
### Step 2. Estimate honestly what fraction you can reach in year 1
If you have a strong launch plan with [ICE-scored channels](/frameworks/ice-scoring) and a real warm-contact list, 5-15% of the SOM denominator is honest. If you have neither, 1-3% is honest. If you say 50%, you're hallucinating.
For 2,000 buyers × 10% reach × 5% conversion to paid = 10 paying customers in year 1. At $99/month, that's $11,880 ARR. Is that a business? For a solo founder bootstrapping, maybe. For a venture-backed seed-stage company, no.
### Step 3. Multiply by price to get SOM revenue
If SOM revenue doesn't clear your minimum-viable-business threshold, you have three options:
1. **Find a denser buyer pool.** Different vertical, geography, or company size.
2. **Raise the price.** If your buyers have budget, charge for it. See [pricing validation](/validate-your-business-idea/pricing-validation).
3. **Walk away.** Kill the idea now, save the 12-24 months.
### Step 4. SAM and TAM (now, not first)
Once SOM is real and defensible, SAM = the same buyer profile across all geographies and adjacent verticals you could plausibly serve (typically 5-20x SOM). TAM = the global population of that buyer persona (typically 10-50x SAM).
These numbers matter for investor conversations and long-term planning, not for the build/no-build decision. The build/no-build decision lives at SOM.
## The "why now" answer
A market exists. A buyer exists. Why is this the right moment to build the solution?
The answer has to point to a present-tense, concrete trend. Three categories that work:
- **Technology enabler**: a new capability made the solution possible. LLMs in 2023-2024 enabled a whole class of products that weren't viable in 2020.
- **Regulation shift**: a new rule created a market. GDPR (2018) created markets for consent-management and data-mapping tools. SOC 2 audits creating a market for compliance-automation tools.
- **Behavior shift**: a habit changed. Remote-work mainstreaming created markets for async-collaboration tools. The "PLG" GTM motion gaining traction in 2020-2022 created markets for self-serve-friendly billing tools.
Answers that DON'T work:
- "I think people are ready for this." Not a trend, a guess.
- "AI is changing everything." Too broad. Which specific capability, enabling which specific solution?
- "The current tools are bad." That's been true for a decade. Why is now different?
If you can't answer "why now" in one sentence with a concrete trend, the timing isn't right. Most second-time-rejected startups fail at this question.
## Competitor density (the cheap version)
A 30-minute exercise. Three lists.
**Direct competitors**. Same product, same buyer. List 5-10. Note: pricing, recent funding, public revenue/growth signals (Crunchbase, BuiltWith, LinkedIn employee growth).
**Substitutes**. Different product, same job. The Mom Test surfaces these naturally. If your buyer currently solves the problem with spreadsheets, Notion, a part-time freelancer, or "just deal with it," those are your substitutes. They're often harder to displace than direct competitors because they're embedded in habits.
**Adjacent players**. Players one step away who might enter your market. Stripe entering payroll. Notion adding databases. If a well-funded adjacent player could ship your feature as a side-quest, that's a meaningful threat.
Then identify the underserved niche. The specific buyer segment where every existing solution is too expensive, too complex, or focused on the wrong job. That niche is your wedge. If you can't find one, the market is mature and you need an unusually strong [7 Powers angle](/frameworks/7-powers) to win. Usually counter-positioning, because incumbents can't cannibalize their existing customers to compete with you on price/simplicity.
## Tools that actually help
Skip the $50K Gartner subscription. Most pre-launch research can be done with:
- **Crunchbase**. Competitor density, funding signals, company counts by stage
- **LinkedIn**. Buyer-count via job title + company size + geography
- **Google Trends**. Keyword search interest over time (good for "why now" validation)
- **G2 / Capterra reviews**. What current users like and hate about competitors
- **Reddit + targeted Slack communities**. Raw demand language (use this for [Mom Test](/frameworks/mom-test) prep)
- **Annual reports** of incumbents. What they say about market dynamics in their own 10-K
Build your own database. Don't buy one. The act of building it teaches you the market.
## Common mistakes
**1. TAM-first thinking.** "The market is $200B" is a vibe, not a number. Start at SOM.
**2. Inflating reach assumptions.** Honest reach is 1-15% of SOM in year 1, depending on your distribution. Anything above 20% is hallucination.
**3. No "why now."** A market timing answer that depends on a future trend ("people will soon want this") is wrong. The trend has to be present-tense.
**4. Ignoring substitutes.** Spreadsheets are your competitor. So is "just deal with it." Underestimating substitutes is the single most common mistake in early-stage competitive analysis.
**5. Buying research reports instead of doing research.** A $50K Gartner report tells you what an analyst thinks. Talking to 15 buyers tells you what they do. The second beats the first for pre-launch decisions every time.
## What ShipFit does at this stage
Stage 1 of the [9-step playbook](/validate-your-business-idea) is **Worth Building?**. The market research gate. The output is a **Quick Take** with four sections you can read in 60 seconds:
- **Verdict**: one of *Promising*, *Promising, Needs Focus*, *Needs Major Pivot*, or *Don't Ship*. Plus a **Signal Confidence Level** (High / Medium / Low) so you know how much weight to put on it.
- **What we can see**: market size band, growth signal, the gap your idea fills, and the citations behind every number.
- **Areas to Clarify**: the specific weak spots in your input (vague buyer, missing pain, no geographic scope) that ShipFit refuses to guess at. Fix these before stage 2.
- **Key Opportunities**: 2-4 angles ShipFit thinks the market actually rewards, written as one-liners you can test against your own conviction.
Under the hood:
1. SOM computed bottom-up from your buyer persona inputs, not top-down from analyst reports.
2. Your "why now" answer mapped against the three trend types — technology, regulation, behavior. Future-tense answers ("people will soon want this") show up as a weak signal in the verdict.
3. Competitor table with public signals (funding, growth, pricing) you can verify within an hour, sourced from the citations attached to the Quick Take.
4. When the verdict is *Needs Major Pivot* or *Don't Ship*, the output includes pivot angles to consider before you walk away.
## The bottom line
Pre-launch market research isn't about producing a TAM slide. It's about producing a defensible answer to: **can this business sustain itself, and is now the right moment?** Two numbers (SOM + price) and one timing answer. Done honestly, in a day. Skip the multi-month consultant engagement.
### Product Launch Plan Template: The 7-Step Playbook (2026)
URL: https://shipfit.ai/validate-your-business-idea/launch-plan
> Free product launch plan template covering the 7 decisions that decide whether your launch makes revenue. Buyer-channel fit, week-1 checklist, success metric.
## The launch-plan template most founders are missing
Most product launch plan templates online are activity lists: "post on Twitter, email your list, submit to Product Hunt, do an outreach campaign." That isn't a plan. That's a checklist of activity dressed as strategy.
A real launch plan answers seven questions, in order. Each one gates the next. If you can't answer Q1, the rest is wishful thinking.
Below is the template. Copy it, fill in the gaps, ship it. If you'd rather have it generated for you with framework checks at every step, run the [9-step ShipFit playbook](/validate-your-business-idea); the launch plan is what it produces at stage 8.
## The 7 decisions a launch plan locks down
### 1. Who is the launch FOR?
Not "founders." Not "developers." Not "small businesses." A specific buyer with budget authority and a problem painful enough to act on launch day.
The right answer reads like: "B2B SaaS founders running pre-seed startups in Europe who've already raised but haven't shipped." That's specific enough to map to a channel.
If you can't write your buyer in one sentence at this level of specificity, you don't have a launch problem. You have a [Who Pays problem](/validate-your-business-idea/idea-validation), and your launch will fail no matter how many channels you pick.
### 2. Where does that buyer already pay attention?
The honest version of go-to-market. Not "where do I want them to be," but "where are they actually spending hours of their week before they've ever heard of me."
Examples:
- B2B SaaS pre-seed founders → Twitter, Indie Hackers, specific Slack communities (e.g., On Deck), maybe a16z/YC newsletters
- Enterprise IT buyers → Gartner / Forrester reports, vendor-led webinars, AWS re:Invent and similar conferences
- Indie hackers / solo developers → Hacker News, Indie Hackers, dev.to, specific subreddits, Twitter (still)
- Healthcare practitioners → trade publications, conference exhibits, peer referrals, almost never social
If you genuinely don't know where your buyer pays attention, you do not yet have validation. Go back to the [Mom Test](/frameworks/mom-test) and add five more interviews where you ask "what newsletters or communities do you read for this kind of thing?"
### 3. Which 2 channels score highest by ICE?
Once you have a list of 5-10 plausible channels, run [ICE scoring](/frameworks/ice-scoring) on each:
| Channel | Impact (1-10) | Confidence (1-10) | Ease (1-10) | ICE score |
|---|---|---|---|---|
| Twitter launch thread | 7 | 8 | 9 | 504 |
| Indie Hackers post | 6 | 9 | 8 | 432 |
| Outreach to YC alumni | 8 | 5 | 4 | 160 |
| Product Hunt launch | 8 | 6 | 6 | 288 |
| LinkedIn post | 4 | 5 | 8 | 160 |
**Pick the top two. Ignore the rest.** Three channels means each one gets one-third of your attention and produces one-third of the result. Two channels means you can actually be present in both for the first 48 hours, which is when launch traction is decided.
### 4. What is the launch message?
One sentence that does three jobs: names the problem, names the buyer, makes the buyer feel seen.
Wrong: "ShipFit is the AI-powered all-in-one decision engine for founders building products."
Right: "If you've ever shipped a product nobody bought, this is the playbook you should have run before writing code."
The right version names a specific failure pattern (shipped + nobody bought), implies a specific buyer (founders who've launched at least once), and offers a specific fix. The wrong version is an SEO description.
Test the message before launch day. Send it to 20 of your interview subjects and ask: "Would this make you click? Why or why not?" If under half say yes, the message is wrong, not the channel.
### 5. What does week 0 actually look like, by the hour?
Most launches fail on day 1 because nobody mapped the hour-by-hour. Here's the actual template:
**T-7 days** (one week out)
- Final QA pass on the product
- Landing page copy locked (no more "should I change the headline?" debates)
- Pricing page final
- 3 onboarding flows tested with strangers, not friends
**T-3 days**
- Personal outreach list ready: 50-200 warm contacts who match the buyer profile and might be willing to share
- DMs / emails drafted, personalized hooks per contact (no "hey checking in" mass blasts)
- Backup support coverage scheduled (if launch goes well, you'll need to answer 100+ messages in 24 hours)
**T-1 day**
- Communities (Slack, Discord, Reddit) where you've been active for at least 3 months: warm-up posts queued, not promotional yet
- Email list teaser sent ("something I've been working on, more tomorrow")
**Day 0 (launch day)**
- 8am buyer-timezone: primary channel post (Twitter thread, Product Hunt submission, etc.)
- 11am: secondary channel post
- 1pm: email blast to your full list
- 3pm: reach out to first 20 warm contacts personally
- All day: respond to every comment within 1 hour; track which message variants get the most replies
**Day +1**
- Reach out to next 50 warm contacts
- Update the landing page based on day-0 confusion ("everyone asked X, add a sentence about it")
- Post follow-up in primary channel ("first 24 hours: here's what we learned")
**Day +3**
- Honest post-launch retro: what worked, what didn't, what's the metric tracking
- Decide where to double down
**Day +7**
- Measure against the metric you set in Q6 below
- Decide: scale, pivot the message, or rethink the channel mix
### 6. What metric proves the launch worked?
Set this BEFORE launch. Not after.
Pick one of these, in increasing order of signal strength:
- **Email signups** (weak. Many people sign up for things they'd never pay for)
- **Demos booked** (medium. Friction is calendar time, which is real but limited)
- **Free trials started with non-trivial actions** (medium-strong. They did something inside the product)
- **Paid conversions** (strong. Money down)
- **Revenue** (strongest. Pre-orders, contracts, deposits)
For a pre-revenue product with a paid tier, "paid conversions in 14 days" is usually the right metric. Set a target number. "Below 30% of target, the launch had a positioning problem. 30-70%, the launch was OK but channel mix was wrong. 70%+, scale what worked."
This step is where most launch plans cheat. They define success vaguely ("get the word out") and then any outcome counts as a win, which is the same as no outcome counting. Pick a number. Live with it.
### 7. What's the kill / pivot rule?
If launch underperforms, what do you do?
Three honest answers:
1. **Kill the channel mix, not the product** if the channels were wrong but the people who DID find it converted well. (E.g., Product Hunt launch flopped but 5/10 people from a Slack community converted to paid. The channel was wrong, the product is fine, double down on Slack.)
2. **Kill the message, not the product** if the channels were right but the conversion was weak. (E.g., right people saw it, but few clicked through to signup. The message wasn't matching the pain.)
3. **Kill the launch and go back to validation** if the conversion was weak everywhere. The product or buyer is wrong. This is the hardest call to make and the one most founders avoid for 6-12 months too long.
Lock this rule before launch. After launch, you will be too emotionally invested to pick #3 without a pre-commitment.
## The free template (copy this into Notion or a doc)
```
PRODUCT LAUNCH PLAN. [Product Name]
Launch Date: [YYYY-MM-DD]
1. BUYER (one sentence, specific):
_________________________________________________
2. CHANNELS (top 2 by ICE score, with scores):
Channel A: ____________________ ICE: ___
Channel B: ____________________ ICE: ___
3. MESSAGE (one sentence, names the problem + buyer):
_________________________________________________
4. WEEK SCHEDULE (T-7 through T+7. See template above)
5. SUCCESS METRIC + TARGET NUMBER:
Metric: ____________________
Target: ____________________
Floor (below this, kill): ____________________
6. KILL/PIVOT RULES (pre-commit before launch):
If channels wrong: ______________________________
If message wrong: _______________________________
If conversion weak everywhere: __________________
7. WARM CONTACT LIST (50-200 names, with hooks):
[Spreadsheet or table here]
```
Print it. Post it on the wall. Cross things off as you do them.
## The launch math nobody runs
Run this before launch day, not after.
Estimated launch-day reach × estimated conversion to signup × estimated signup-to-paid conversion = estimated paid customers from launch.
Realistic numbers for a pre-revenue B2B SaaS with a $19/mo tier:
- Launch reach (top-of-funnel impressions): 5,000-50,000 over 7 days for a well-targeted launch
- Signup conversion: 1-3% of impressions (so 50-1,500 signups)
- Signup-to-paid conversion: 2-10% in the first 30 days (so 1-150 paid customers)
If those numbers don't add up to a launch you're proud of, the gap isn't a channel problem. It's that your buyer pool is too small or your conversion rate at any stage is unrealistic. Better to know this before you spend two weeks on launch prep than after.
## What ShipFit ships at the end of stage 8
If you run the full [9-step ShipFit playbook](/validate-your-business-idea), stage 8 produces a populated version of the template above: your buyer is locked in by stage 2, your channels are scored by ICE in stage 8, your message draws from the [JTBD job statement](/frameworks/jobs-to-be-done) you wrote in stage 4, and the kill/pivot rules borrow logic from your [pricing validation](/validate-your-business-idea/pricing-validation) thresholds.
### The Product Playbook fills in as you go
Every decision you make across the 9 stages writes back into a single living document: the **Product Playbook**. Each section unlocks as you complete the matching stage, so by the time you reach the launch decision the page already shows your verdict, your buyer, your above-the-line pains, your winning angle, your V1 scope, and your pricing position. Stage 8 then drops the launch slot in: pricing model, entry price, price position, positioning line, and primary channels.
Once all 9 decisions are made the playbook hits its **Blueprint Complete** state, with a single **Export Now** CTA that hands the playbook off to stage 9.
Then **stage 9 (What to Export?)** turns the launch plan into specs for the tools you actually build with. Either a **Universal Prompt** (one prompt, any AI chat: ChatGPT, Claude, Gemini), or tool-specific configurations: `.cursorrules` + domain rules for Cursor, `CLAUDE.md` + slash macros for Claude Code, `.windsurfrules` + pin guide for Windsurf, plus presets for v0.dev, Lovable, Replit, and Gemini/Antigravity. The same validated playbook becomes the spec your codebase ships from.
The power combo most founders pick: **Cursor for editing + Claude Code for terminal**. The exports are pre-configured for that pairing.
## The kindest version of the truth
Most launches don't fail because the founder picked the wrong channel. They fail because the founder skipped the buyer-definition step at the top of this template, then optimized their launch for whoever happened to show up. Whoever shows up usually isn't a buyer. They're traffic.
Lock the seven decisions before you ship. The launch will look smaller (two channels, one message, one metric) and convert dramatically better than the 30-channel "marketing plan" your friends will tell you to run.
### SaaS Pricing Strategy Validation: Set a Price You Can Defend
URL: https://shipfit.ai/validate-your-business-idea/pricing-validation
> How to price a product you're about to launch: pricing validation that produces a defensible price, using Van Westendorp PSM and willingness-to-pay interviews.
## Why most founder pricing is wrong
Most founder pricing decisions follow this process:
1. Look at competitor prices.
2. Average them.
3. Subtract 20% to "be competitive."
4. Pick a round number.
This is not strategy. It's matching. It leaves money on the table when you're underpriced and chases buyers away when you're priced for the wrong segment.
Real pricing validation produces a number with three properties:
- **It maps to a defined buyer's willingness to pay** (you have evidence, not vibes).
- **It clears your unit economics** (you make money at this price, not just revenue).
- **You can defend it under pushback** (when a prospect says "that seems expensive," you have a sentence that works).
This guide is the validation discipline that produces that number.
## The four numbers
Every pricing decision rests on four numbers. Know all four before you set a price.
3 is the venture-scale threshold. Below means raise the price, lower CAC, or accept it as a lifestyle business.' },
]} />
### 1. SOM revenue at price X
How much revenue does your serviceable obtainable market produce if everyone in it converted at price X?
(SOM buyer count) × (realistic conversion rate, 1-5%) × (price X) = SOM revenue at X
If SOM revenue at your candidate price doesn't clear your minimum viable business threshold, the price is wrong (or the SOM is). See [market research](/validate-your-business-idea/market-research) for SOM math.
### 2. Willingness-to-pay range from interviews
What price range do real buyers describe as acceptable? Get this from 20+ interviews with the [Mom Test discipline](/frameworks/mom-test) applied. The question that works: "When you last tried to solve this problem, what did you spend or budget?"
If the typical answer is "$10K/year on a competitor," you can charge $100-300/month (with a path to $500+). If the typical answer is "nothing, I just deal with it," you're not validated. The problem isn't painful enough.
### 3. Van Westendorp band
Run the [Van Westendorp Price Sensitivity Meter](/frameworks/van-westendorp) on 20-50 buyers. The four-question survey produces:
- **Lower bound, PMC** (Point of Marginal Cheapness): where "too cheap" crosses "expensive". Below this, more buyers doubt the quality than think the price is fair
- **Upper bound, PME** (Point of Marginal Expensiveness): where "too expensive" crosses "bargain". Above this, more buyers walk away than see a good buy
- **Optimal Price Point (OPP)**: where "too cheap" crosses "too expensive". The price with the smallest combined objection, which is not the same as the most revenue
- **Indifference Price Point (IPP)**: where "expensive" crosses "bargain". Half the buyers read the price as cheap, half as expensive
PMC to PME is the band. OPP and IPP both sit inside it. The band is wider and more honest than any single number, so use it as a constraint: your price has to live inside it. The [full framework page](/frameworks/van-westendorp) covers how to plot the curves and which respondents to drop first.
### 4. Unit economics at price X
For SaaS, the question is: at price X, is LTV/CAC > 3?
- **LTV** (lifetime value) = price × average customer lifetime (in months)
- **CAC** (customer acquisition cost) = sales + marketing spend / new customers
If LTV/CAC isn't 3+ at your candidate price, your business doesn't scale. Either raise the price, lower CAC (better channels, better conversion), or accept that the business is a lifestyle business, not a scaling one. All three are valid. Knowing which you're building is the discipline.
## Test 3-5 prices, not 1
The most common pricing-test mistake is testing one price. A single-price test tells you whether THAT price works, not whether you're leaving money on the table or chasing buyers away.
Test a 3-5 price spread, typically following a geometric progression:
| Tier | Price | Test purpose |
|---|---|---|
| Anchor low | $9/mo | Floor. Too cheap to take seriously? |
| Mass | $29/mo | Volume play |
| Premium | $79/mo | Where most SaaS lives |
| Enterprise lite | $199/mo | Test if buyers exist in your space |
| Enterprise | $499/mo | Sanity check |
Don't ship all 5. The point of the test is to find the elasticity curve so you can pick 1-3 final tiers with confidence.
A common pattern in the data: conversion drops off a cliff between $29 and $79, suggesting your buyer pool segments at $50/month. You then launch a $29 tier (mass) and a $79 tier (premium) and skip the $9 tier (too cheap, attracts wrong customers) and the $199+ tiers (no buyer pool yet).
## Pricing model matters more than price
Before obsessing over the number, validate the model.
**Per-seat** (Slack, Notion, Linear)
- Pros: scales naturally with customer; predictable
- Cons: friction at adoption. "I have to budget for the whole team"
- When to use: B2B where the buyer = the user (team productivity tools)
**Per-usage** (Stripe, AWS, OpenAI API)
- Pros: aligns price with value delivered; no waste
- Cons: hard to budget; sticker shock on heavy users
- When to use: when value scales with usage (infrastructure, API)
**Flat / tiered** (Basecamp, ConvertKit, Webflow)
- Pros: predictable billing; easy to understand
- Cons: leaves money on the table for power users; alienates light users
- When to use: when usage doesn't vary much across customers
**Freemium** (Notion, Loom, Calendly)
- Pros: massive top-of-funnel, viral potential
- Cons: 95-97% of free users never convert; requires PLG mechanics
- When to use: network effects or virality; marginal cost near zero
**Free trial** (most SaaS)
- Pros: high conversion (10-30%); buyer sees value before paying
- Cons: requires fast time-to-value; trial expiration nudge mechanics
- When to use: default for most B2B SaaS
Pick the model based on your buyer's purchase behavior and your unit economics. Get the model right; tune the number later.
## The willingness-to-pay interview script
Five questions, in this order, with at least 15 target buyers:
1. "When you last tried to solve [problem], what did you do?"
2. "How much did it cost. In money, time, or attention?"
3. "If I told you there was a tool that did X for $Y/month, what would your first reaction be?"
4. "What would have to be true for you to pay $Y/month for this?"
5. "How would you justify this expense to [boss / partner / yourself]?"
The signal isn't the price number they give. It's question 5. The justification model. If they can articulate the justification cleanly, they're a real buyer at that price. If they can't ("I dunno, it just seems like a lot"), they're not.
Run 15-20 of these. Patterns emerge. The patterns name your price.
## Common mistakes
**1. Picking a price by averaging competitors.** That's matching, not strategy. Competitor pricing is one input among many.
**2. Setting price once and never revisiting.** Pricing is an ongoing decision, not a launch one. Annual review minimum.
**3. Testing one price point.** You learn nothing about elasticity. Test a spread.
**4. Asking "how much would you pay?"** Predicts nothing. Replace with past-spend and justification questions.
**5. Skipping unit economics.** A price that doesn't clear LTV/CAC > 3 is a price you can't scale at. Doesn't matter how validated the willingness-to-pay is.
**6. Free tier by default.** Free tiers should be a deliberate choice, not a default. Most products that ship a free tier never recover from the conversion math.
## What ShipFit does at this stage
Stage 6 of the [9-step playbook](/validate-your-business-idea) is **How to Charge?**. Pricing validation. The output is your **Pricing Position**: where your candidate price sits in the competitive landscape, scored against four zones.
| Zone | What it means |
|---|---|
| **Value Zone** | You're priced below most competitors but above the cheap end. Easy entry, room to raise. |
| **Premium Zone** | Above competitors. Defensible only if you have a clear differentiator the buyer recognizes. |
| **Budget Zone** | Cheapest in the market. Signals "not serious" to enterprise buyers. Volume play only. |
| **Overpriced Zone** | Above the Premium Zone with no matching differentiator. Buyers won't even consider you. |
The output is a **Pricing Position** chart placing your candidate price against the Value / Premium / Budget / Overpriced zones, plus an **Optimal Price Point** recommendation drawn from the Van Westendorp curves.
The full Stage 6 output:
1. Van Westendorp questions phrased for your buyer + product, with the four-curve diagram and the OPP / IPP / PMC / PME labels.
2. A pricing position chart placing your candidate price against the competitor pack.
3. A pricing model recommendation (per-seat, per-usage, tiered, freemium, etc.) keyed to your buyer profile.
4. Tiering guidance with the "what a prospect will say" framing — the objection you should be ready to answer at the price you've chosen.
Stage 6 is the most-skipped stage in founder workflows. It's also the highest-leverage one for revenue per customer. Don't skip it.
## The bottom line
Pricing isn't a number; it's a decision made up of four numbers (SOM revenue, WTP range, Van Westendorp band, unit economics) and one structural choice (model). Real pricing validation produces a price you can defend, a model that scales, and a unit-economics story that makes the business work. Founders who do this work charge 2-5x what their peers charge for similar products. That gap is mostly discipline, not market positioning.
---
## Frameworks
### AEIOU Framework: A Structure for Field Observation
URL: https://shipfit.ai/frameworks/aeiou-framework
> Activities, Environments, Interactions, Objects, Users. The AEIOU observation framework gives field research a structure so notes are comparable across sessions.
## What AEIOU is
AEIOU is a framework for structuring observational research. It sorts what you record in
the field into five categories: **activities, environments, interactions, objects** and
**users**.
It was developed in 1991 at Doblin, the Chicago innovation consultancy, as a coding scheme
for ethnographic data. The categories were chosen to be mutually exclusive and, between
them, to cover a scene, so that two researchers watching the same session produce notes
that can be compared rather than two personal essays.
It is a **capture** structure, not an analysis method. It tells you what to write down. It
has no opinion about what any of it means.
## Why it matters
Unstructured field notes are shaped by what you already expected to see. You write down
the things that confirm your model of the work and skim past everything else, and you do
not notice you are doing it.
Five fixed headings interrupt that. A column that stays empty is itself a finding: an hour
of observation with nothing in Interactions usually means you watched someone work alone
on a task that is actually collaborative, and you happened to catch the solitary part.
The empty column is also the one people quietly fill in from memory on the train home,
which defeats the entire exercise. Leave it empty. An honest blank is worth more than a
plausible sentence.
## The five categories
## When to run it
## AEIOU in practice: Airbnb in New York
Observation beating analytics, in a case where the analytics were working perfectly and reporting nothing useful.
## AEIOU vs the alternatives
## When it won't help you
## Further reading
- Rick E. Robinson's writing on the origins of the framework at Doblin.
- [Empathy Maps](/frameworks/empathy-maps). Where AEIOU notes go to be synthesised.
- [The Mom Test](/frameworks/mom-test). What to do when you can only talk, not watch.
- [Jobs to be Done](/frameworks/jobs-to-be-done). Turning observed behaviour into a reason for switching.
- [Design Thinking](/frameworks/design-thinking). The wider process the empathize stage sits inside.
### Aggregation Theory: Why Owning Demand Beats Owning Supply
URL: https://shipfit.ai/frameworks/aggregation-theory
> Ben Thompson's Aggregation Theory: the three conditions, how aggregators commoditise suppliers, and why most companies calling themselves platforms are not aggregators.
## What Aggregation Theory is
Aggregation Theory is Ben Thompson's explanation of why internet-era companies accumulate
power by owning the customer relationship rather than by owning supply. He set it out on
Stratechery in 2015 and has extended it across a large body of subsequent writing.
The argument starts from a value chain with three parts: **suppliers, distribution,
customers**. In the pre-internet economy, power sat with whoever controlled distribution,
because distribution was expensive and scarce. The internet made it free, which did not
merely reduce that advantage but relocated it entirely.
What is scarce now is **attention and the customer relationship**. A firm that owns those
can set the terms on which suppliers participate, and suppliers become interchangeable from
the user's point of view.
## The three conditions
## The virtuous cycle
The mechanism is self-reinforcing once it starts, which is why aggregation produces such
durable positions and why it is so hard to reach.
## Aggregator or platform
The distinction is the most useful practical thing in the theory, and the two words get
used interchangeably by people who mean quite different structures.
An **aggregator** owns the customer relationship. Suppliers come on its terms and weaken
over time, because users think of the aggregator rather than of who supplied the thing.
A **platform** lets suppliers reach customers while those suppliers keep their own
relationship. The suppliers get stronger. Their brands survive, and they can leave.
These lead to opposite strategies. An aggregator invests in the user experience and in
keeping suppliers substitutable. A platform invests in supplier tools and in making
suppliers succeed. Building one while describing yourself as the other is a reliable way
to spend money on the wrong things.
## When to use it
## Aggregation in practice: Netflix and Blockbuster
One firm owned the distribution. The other owned the relationship with demand. Only one of those turned out to be the durable asset.
## When it won't help you
## Further reading
- Ben Thompson, *Aggregation Theory*, Stratechery (2015). The original essay, and still the clearest statement.
- Thompson's subsequent Stratechery writing on aggregators and platforms, where the distinction is worked out in detail.
- [7 Powers](/frameworks/7-powers). Network economies, which is aggregation expressed as a barrier.
- [Disruptive Innovation](/frameworks/disruptive-innovation). The other main explanation of how incumbents lose.
- [Playing to Win](/frameworks/playing-to-win). Where in the chain you are choosing to compete.
### Biomimicry: Borrowing Mechanisms From Biology
URL: https://shipfit.ai/frameworks/biomimicry
> How biomimicry works as a design method, the function-first process that separates it from surface imitation, and its honest limits for software.
## What biomimicry is
Biomimicry is a design method that **borrows mechanisms from biology** to solve human
problems. Janine Benyus named and popularised it in her 1997 book, though the practice of
looking to nature for solutions is very much older.
What makes it a method rather than a source of inspiration is a single discipline:
**function first**. You start from a function you need performed, not from an organism you
find interesting. Starting from the organism produces an analogy in search of a problem,
which is the form most of the popular examples take.
## Why the discipline matters
Biomimicry has two reputations. In materials science and hardware it has a genuine record:
self-cleaning surfaces from lotus leaves, drag reduction from shark skin, adhesives from
gecko feet. Each of those borrowed a specific physical mechanism, and each produced a
product that works for reasons you can measure.
In business writing it has a much weaker one, because it usually arrives as metaphor. "Our
platform is like a mycelial network" describes something without instructing anything, and
the difference between the two reputations is entirely the function-first discipline.
The reliable test is whether the analogy survives being asked how. "Like a mycelial
network" collapses on the first follow-up question. "A beak that enters a denser medium
without a shockwave" does not, because it names a mechanism somebody can go and
measure.
## The process
## Two modes, and which one you are in
Biomimicry operates in two quite different modes, and most disagreement about whether it
"works" is really disagreement about which one is meant.
**Literal mechanism transfer** copies the physics or chemistry that makes a biological
solution work. This is where the famous results come from, and it needs a physical problem:
energy, materials, structure, temperature, mechanical load. Software problems are usually
not physical, so the literal mode applies narrowly, mainly in optimisation and search.
**Analogical borrowing** takes the strategy rather than the mechanism. How does an organism
handle abundance it cannot process? How does it decide what to ignore? These map onto
product and scope questions genuinely, and this is the mode that belongs in a scoping
exercise alongside cross-industry analysis.
The mode you are in decides what counts as success. In the literal mode, if the mechanism
does not transfer you have nothing. In the analogical mode the test is softer but still
real: does the borrowing tell you to build something differently, or does it only give you
a nicer way to describe what you already had?
## When to use it
## Against the alternatives
## Biomimicry in practice: the 500 Series Shinkansen
The case that gets used to sell the method, told with the part that makes it reproducible.
## When it won't help you
## Further reading
- Janine Benyus, *Biomimicry: Innovation Inspired by Nature* (1997). The source.
- AskNature, the Biomimicry Institute's function-indexed database, which is organised the way the method says to search.
- [SCAMPER](/frameworks/scamper). The Adapt prompt, of which this is a specialised version.
- [Design Thinking](/frameworks/design-thinking). The process this fits inside.
- [Blue Ocean Strategy](/frameworks/blue-ocean-strategy). A more reliable route to genuinely different options in a business context.
### Blue Ocean Strategy: The Strategy Canvas and Four Actions
URL: https://shipfit.ai/frameworks/blue-ocean-strategy
> Kim and Mauborgne's framework in plain terms: the strategy canvas, the four actions, the six paths, and the tests that separate a blue ocean from a red one.
## What Blue Ocean Strategy is
Blue Ocean Strategy is a framework for creating new market space rather than competing in
an existing one. It was introduced in 2005 by W. Chan Kim and Renée Mauborgne, both
professors at INSEAD, in the book *Blue Ocean Strategy: How to Create Uncontested Market
Space and Make the Competition Irrelevant*, and expanded in a 2015 revised edition and in
*Blue Ocean Shift* (2017).
The framework divides markets into two kinds. **Red oceans** are existing industries with
defined boundaries and known rules, where competitors fight over the same demand and
margins compress as the space gets crowded. **Blue oceans** are market spaces that do not
yet exist, where demand is created rather than fought over.
Its central claim is **value innovation**: that differentiation and low cost are not a
trade-off if you change which factors the industry competes on. Cutting hard on the
factors an industry over-serves pays for raising the factors it ignores, so the offering
can be both more distinctive and cheaper to produce than the incumbent's.
The framework's signature tool is the **strategy canvas**, a chart plotting competitors
across the factors buyers value, on which a blue ocean appears as a curve with a visibly
different shape from the industry cluster.
## Why it matters: value innovation
Conventional strategy asks you to choose. Differentiate and charge a premium, or strip the
offering down and compete on price. The two are treated as ends of a single frontier, and
picking a spot on it is the decision.
Value innovation is the claim that the frontier itself moves.
This is either the most useful idea in modern strategy or the most convenient one,
depending on the day and on whether the person explaining it to you is selling something.
Both readings survive contact with the evidence. It is worth holding both.
This is also the fastest way to check whether a claimed blue ocean is one. If the new
positioning costs *more* to deliver than the incumbent's, no eliminating has happened, and
what you have is a premium product in a red ocean.
Blue Ocean is the second most-selected framework in ShipFit's own engine, applied to about a
third of the ideas that reach the strategy stage. It also sits inside a very small club:
nineteen frameworks are available and three of them account for nine selections in ten.
Two readings are available. Either most ideas genuinely sort into a handful of strategic
shapes, or an engine with nineteen options and three habits is not really choosing. We lean
towards the first, and we are aware that we would.
## When to run it
## Where to look: the six paths
Most teams start by asking how to beat the competitors they already track, which is why
their answers stay inside the red ocean. The Six Paths Framework redirects the question at
six boundaries an industry treats as given.
## Who fills a blue ocean: three tiers of noncustomers
An uncontested market space is worth nothing if nobody is in it, and the most common way
this framework fails is a founder discovering a genuinely empty space that is empty for a
good reason.
Kim and Mauborgne's answer is that blue oceans are filled by people who are not buying
today, and that those people come in three groups with different reasons. That turns "is
there demand?" into a question you can research.
## The strategy canvas
The canvas is the framework's analytical core. The horizontal axis lists the factors the
industry competes on. The vertical axis is how much of each factor an offering delivers.
Each competitor becomes a curve.
Two things are visible on that chart that no amount of prose delivers. The incumbents are
**variations of each other**, which is what an industry looks like from the outside. And
the divergent curve is **lower on most factors**, not higher, because the cuts are what
pay for the two places it goes high.
## The four actions
The gap between the industry cluster and a new curve is produced by four moves, and they
are meant to be used together.
Eliminate is the hardest and the one teams skip, because cutting a factor buyers appear to
value feels reckless. It is also where the money comes from. Cirque du Soleil's two largest
cuts, animals and star performers, were the two largest cost lines in a traditional circus,
and cutting them is what funded the theatrical production values that defined the category
it created.
## Does your curve pass?
A canvas can be drawn for any product, including a thoroughly red-ocean one. Kim and
Mauborgne give three tests that separate the two.
## Before you commit: the strategic sequence
A divergent curve is a hypothesis, not a business. The framework's own validation order
tests it in a specific sequence, and the sequence is the opposite of how most teams work.
## Blue Ocean in practice: [yellow tail]
The case from the book itself, chosen here because the value curve goes down on almost every factor the industry considered essential.
## Blue Ocean vs Porter, 7 Powers and "differentiation"
Differentiation deserves the last row. It usually means the same factors as everyone else,
scored slightly higher, which on a canvas is the incumbent shape nudged upward. Blue Ocean
requires the shape to change, and a shape only changes if something was given up.
## When it doesn't work
The framework attracts more criticism than its popularity suggests, and a reader who has
met it elsewhere will discount this page if it goes unmentioned.
## ShipFit and Blue Ocean
Stage 4 of ShipFit (How to Win?) applies Blue Ocean alongside [7 Powers](/frameworks/7-powers).
The two answer different halves of the same question: Blue Ocean identifies where the
opening is, and 7 Powers identifies what will keep it once incumbents catch up.
The module asks you to list the competitive factors in your category and surfaces ones you
are likely to miss, plots incumbent positions, forces explicit eliminate, reduce, raise and
create decisions, and flags when the resulting curve fails to diverge. Where it does not
diverge, the stage reports a red-ocean risk rather than a positioning statement, and
recommends changing buyer segment or approach.
## Where this sits in the sequence
Blue Ocean tells you where to compete. It does not tell you whether the problem is real, or
what will protect the position once you have it.
## Further reading
- W. Chan Kim & Renée Mauborgne, *Blue Ocean Strategy* (2005, revised 2015). The source. Use the revised edition; it adds ten years of cases and two new chapters.
- W. Chan Kim & Renée Mauborgne, *Blue Ocean Shift* (2017). The implementation handbook, and considerably more practical about the human side of getting a team to accept the eliminate row.
- [7 Powers](/frameworks/7-powers). What will defend the position once the ocean starts to redden.
- [Jobs to be Done](/frameworks/jobs-to-be-done). For identifying the underserved job your divergent curve is meant to serve.
- [The Mom Test](/frameworks/mom-test). How to test the buyer-utility gate without leading the witness.
- [Lean Startup validation](/frameworks/lean-startup-validation). For running the strategic sequence as real experiments rather than analysis.
- [TAM SAM SOM calculator](/calculators/tam-sam-som). Sizes the new space bottom-up, which is the honest answer to whether the ocean is big enough to swim in.
- [GTM (Go-to-Market)](/glossary/gtm). An uncontested market still needs a route to the buyers in it.
### Brand Strategy Framework: Positioning, Voice, Taglines
URL: https://shipfit.ai/frameworks/brand-strategy-framework
> The four layers of a brand strategy in dependency order, why teams start at the wrong one, and how to write a positioning statement a competitor could not copy.
## What a brand strategy framework is
A brand strategy framework is a structure for deciding what a company stands for and how
it expresses that. It has four layers, and they depend on each other in order:
**positioning**, **personality**, **voice**, and **expression**.
It was assembled rather than invented. Al Ries and Jack Trout's *Positioning* (1981)
supplied the central claim, that a brand occupies a place in the buyer's mind rather than
in the market. Jennifer Aaker's 1997 work gave brand personality measurable dimensions.
The voice and identity layers came out of agency practice through the 1990s and were
formalised mostly by people writing style guides.
Positioning names who you are for and against what alternative. Expression is the name,
the tagline and the identity. Almost every brand project starts at the fourth layer,
because the fourth layer is the enjoyable one.
## Why it matters
The reason to do this in order is not tidiness. Each layer is a constraint on the next
one, and a layer without a constraint above it gets filled in from taste.
Run it backwards and the effect is specific. The identity is chosen because somebody liked
it, the voice is written to suit the identity, the personality is reverse-engineered to
justify the voice, and the positioning statement is written last, in an afternoon, to sit
at the front of the deck. Every layer is consistent with the one below it and none of them
is connected to a buyer.
The result looks professional and decides nothing. Six months later somebody asks whether a
particular campaign is on brand and there is no way to answer, because the only thing the
document actually constrains is the colour of the buttons.
## The positioning statement
One sentence, three components: the buyer, the alternative, the basis.
> For **[specific buyer]**, who currently **[uses this alternative]**, we are the
> **[category]** that **[basis of difference]**, because **[reason to believe]**.
The template is not the hard part. The hard part is the test that follows it: hand the
finished sentence to somebody and ask whether a direct competitor could put their name on
it and have it remain true.
Most positioning statements fail that test. They describe the category, in flattering
terms, with the company's name at the front. That version is comfortable to write and
comfortable to present, and it is useless the moment a buyer is comparing two options,
which is the only moment positioning exists for.
## Voice, including the awkward moments
Voice is usually written as a list of adjectives, and the list is nearly always the same
one: human, authentic, bold, approachable. Those cost nothing. Nobody has ever set out to
be inhuman, inauthentic, timid and forbidding, so claiming the opposite constrains no
future decision.
The alternative is to state voice as positions on independent axes, because a position
names what you are giving up.
Then write the awkward surfaces first. The error message, the failed payment, the price
rise, the refusal, the refund. Brands are formed in the moments that go wrong, and a voice
guide written entirely from the marketing site will be contradicted by the product inside a
week, because the product speaks more often and at worse moments than the website ever
does.
The other neglected surfaces are the boring ones: invoices, transactional email, the 404
page, the cookie banner. Every customer sees them and no brand project covers them.
## Brand strategy in practice: Liquid Death
A case worth including because it is the strongest available argument for brand as a
product decision, and because it also shows the condition that makes that argument work.
## What this is not a substitute for
Brand strategy is frequently reached for when the real problem is that the product is not
differentiated, and a rebrand is a more pleasant project than admitting that.
Which brings us to a number from our own engine, offered here because it makes the point
better than an assertion would. Differentiation is exactly the thing an automated tool
should be able to call honestly, and it turns out to be the thing ours is least willing to
be rude about.
If a tool built to score differentiation finds it almost everywhere, a founder assessing
their own idea should assume they are at least as generous. Brand cannot manufacture a
difference that is not there. It can only make a real one legible.
## When to run it
## When it won't help you
## Further reading
- Al Ries and Jack Trout, *Positioning: The Battle for Your Mind* (1981), for the original
argument that the contest happens in the buyer's head.
- April Dunford, *Obviously Awesome* (2019), for the most practical modern method of
arriving at a position, particularly for software.
- Jennifer Aaker, "Dimensions of Brand Personality" (1997), for the empirical basis of the
personality layer.
- [GTM strategy framework](/frameworks/gtm-strategy-framework), which decides where you
say it once this has decided what you say.
- [Playing to Win](/frameworks/playing-to-win), for the where-to-play choice that
positioning has to inherit.
### Buyer Persona Canvas: The Five Rings of Buying Insight
URL: https://shipfit.ai/frameworks/buyer-persona-canvas
> Adele Revella's Five Rings of Buying Insight, the questions that produce each one, and why a persona built without buyer interviews informs no decision.
## What a buyer persona is
A buyer persona is a research-based profile of the person who decides to buy. The term was
coined by Tony Zambito in 2002, and the research methodology behind the modern version was
formalized by Adele Revella of the Buyer Persona Institute, in her 2015 book *Buyer
Personas*.
Revella's contribution is a specific answer to what a persona must contain. She calls it
the **Five Rings of Buying Insight**: the priority initiative that made this buyer act now,
the success factors they expect, the barriers that make them doubt you, the criteria they
actually compare on, and the journey they take to decide. Each is a question that can only
be answered by asking someone who recently made the decision.
That last constraint is the framework's real argument. A persona assembled from internal
opinion is decoration regardless of how well it is formatted, and the stock photo and the
alliterative name are symptoms rather than the disease.
## Why it matters
Walk into a typical SaaS company and ask to see their buyer personas. You will usually get
a one-pager with a stock photo, a name like Marketing Mary, a list of demographics, and
three bullets about goals and challenges.
Ask what decision that document has changed and the room goes quiet.
Nobody is embarrassed by this, which is the interesting part. The persona was never
meant to change a decision. It was meant to exist, so that when somebody asks whether you
have personas, you do.
One thing worth knowing before you write a persona: the buyer you are probably describing is
not the one the industry writes about. Across 358 ideas classified by ShipFit's buyer stage,
enterprise barely appears. The advice literature is overwhelmingly about enterprise sales
cycles, and the actual population is prosumers and small teams.
The failure is not the format. It is that nothing on the page came from a buyer, so
nothing on it can contradict what the team already believed. A persona that cannot
surprise you cannot inform you, and its only remaining function is to make the team feel
researched.
## When to run it
## The Five Rings of Buying Insight
The ring most teams skip is **Perceived Barriers**, because asking a customer what nearly
stopped them buying feels like inviting them to reconsider. It is also the ring that most
directly changes your website, since the barriers are exactly what a visitor is silently
weighing while reading it.
## How many personas you need
One, in almost every case.
Early-stage companies routinely produce six personas, one per job title they have ever
sold to, and the result is that no piece of messaging is written for anyone in particular.
Three is a reasonable ceiling for a company with genuinely distinct buyer types. Six is not
research; it is a segmentation decision that has been avoided by writing it down.
The test is whether two personas would ever lead you to write different copy, price
differently, or build a different feature. If they would not, they are one persona with
two job titles.
## Personas in practice: the Segway
A product evaluated by everyone who mattered, none of whom was asked to describe the person buying it.
## Buyer personas vs the alternatives
## When it won't help you
## ShipFit and the Buyer Persona Canvas
Stage 2 of ShipFit (Who Pays?) builds the persona from your market research rather than
from a template. It produces the buyer's role and context, the tools they already pay for,
budget authority, how they buy, where they gather, and a verbatim statement of what is on
their mind, which is the raw material for the priority-initiative and barriers rings. The
output feeds Stage 3's problem scoring and Stage 6's pricing, so the persona is used rather
than filed.
## Where this sits in the sequence
The persona comes after you know the problem is real and what job the buyer is hiring for.
It is the step that turns a stack of interview notes into something the whole team can act
on.
## Further reading
- Adele Revella, *Buyer Personas* (2015). The source of the Five Rings and the argument for interview-based research.
- Tony Zambito's writing on buyer insight, which coined the term in 2002 and remains the origin point.
- [The Mom Test](/frameworks/mom-test). How to run the interviews without leading the witness.
- [Jobs to be Done](/frameworks/jobs-to-be-done). The complementary lens: what the buyer is hiring a solution to do.
- [Van Westendorp](/frameworks/van-westendorp). What the persona is worth once you need a price.
- [ICP](/glossary/icp). The organization-level definition the persona sits inside.
- [Blue Ocean Strategy](/frameworks/blue-ocean-strategy). Where the barriers ring feeds a decision about which factors to compete on.
### Confidence Scoring: Rating How Much You Actually Know
URL: https://shipfit.ai/frameworks/confidence-scoring
> A method for scoring the reliability of the evidence behind a decision, so a well-researched conclusion and a confident guess stop looking identical.
## What confidence scoring is
Confidence scoring rates **how reliable the evidence behind a claim is**, on a scale from
an unsourced assumption up to an outcome you observed in your own product.
It is **ShipFit's own model** rather than an established framework. It applies
evidence-hierarchy thinking, which is entirely standard in research methodology, to the
inputs behind an ordinary product decision.
The problem it addresses is specific. Once a claim is written in a document, it loses its
provenance. "Buyers will pay around £2,000 a year" reads identically whether it came from
forty interviews or from one afternoon's thinking, and six months later it will be quoted
with the same authority either way.
## Why provenance disappears
A claim travels and its source does not. Someone writes "our buyers approve up to £2,000
without escalation" in a strategy document, having heard it once. It gets quoted in a
pricing discussion, then in a board deck, then in an onboarding document for a new hire,
and by the fourth retelling it is a fact about the business.
Nothing dishonest happened at any step. Documents simply do not carry footnotes well, and
the confident phrasing that makes a document readable is the same phrasing that strips out
uncertainty.
Tagging costs seconds per claim and is the entire intervention.
It also feels faintly bureaucratic, which is why it does not happen. The moment it pays
for itself arrives about nine months later, when somebody asks where the £2,000 figure came
from and the honest answer turns out to be that a founder heard it at a conference.
## The tiers
## The weakest link
## When to use it
## When it won't help you
## Further reading
- [The Mom Test](/frameworks/mom-test). How to gather tier-4 evidence rather than tier-3.
- [Van Westendorp](/frameworks/van-westendorp). A method whose output is explicitly stated preference, and which says so.
- [Lean Startup validation](/frameworks/lean-startup-validation). Producing tier-5 evidence deliberately.
- [ICE scoring](/frameworks/ice-scoring). Where the Confidence term does the same job inside a ranking.
- [Emotional Friction States](/frameworks/emotional-friction-states). Another ShipFit model, with the same caveats about calibration.
### Customer Journey Mapping: Stages, Touchpoints, Emotion
URL: https://shipfit.ai/frameworks/customer-journey-mapping
> How to build a customer journey map that changes a decision: the stages, what to record at each, and why most maps document the process you already knew.
## What customer journey mapping is
A customer journey map is a visualisation of everything a customer does, thinks and feels
across the stages of their relationship with a product, from first awareness through to
renewal or churn.
It emerged from service design and CRM practice through the 1990s and 2000s, and its
purpose is organisational as much as analytical: in most companies each team owns one part
of the experience and nobody sees the whole thing. The map makes the whole thing visible in
one place, and the interesting findings are almost always at the joins.
The failure mode is equally consistent. A map built from what the team already knows
documents the org chart with arrows on it.
## Why it matters
Every team can see its own segment of the customer experience and is measured on it.
Marketing sees acquisition, sales sees the deal, support sees the tickets, and product
sees usage. Each optimises its own stretch, and the customer experiences the joins.
Journeys break at handoffs, and handoffs are invisible from inside any one team. That is
the specific thing this instrument is for, and it is why running it inside a single team
usually produces very little.
So a quick diagnostic. If your journey map was drawn by one team, in one room, from
memory, you have not mapped the journey. You have mapped that team's understanding of it.
That is a genuinely useful artefact and a completely different one.
## The stages
## When to run it
## Journey mapping in practice: Disney MagicBand
A billion dollars aimed at queueing, and a useful example of a sound analysis producing a difficult programme.
## Journey mapping vs the alternatives
## When it won't help you
## Further reading
- The Nielsen Norman Group's research on journey mapping, which is the most rigorous freely-available treatment.
- [Empathy Maps](/frameworks/empathy-maps). The snapshot instrument that pairs with the sequence.
- [Jobs to be Done](/frameworks/jobs-to-be-done). The switch timeline, which is a journey map of the decision specifically.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas). The buyer's-journey ring, and who else had a say.
- [GTM](/glossary/gtm). What the journey has to be designed around commercially.
### Design Thinking: The Five Stages and Where They Break
URL: https://shipfit.ai/frameworks/design-thinking
> The five-stage design thinking process from Stanford's d.school, what each stage produces, and the honest limits founders hit when they run it on a startup.
## What Design Thinking is
Design Thinking is a **process**, and that distinction is worth making before anything
else. Most of the entries in this collection are frameworks: analytical lenses that take
inputs and return a verdict, a score or a range. Design Thinking returns none of those. It
is a sequence of activities you run, and what it produces is a well-framed problem and
some candidate solutions worth testing.
It starts from the people a solution is for rather than from the solution. It was
formalised at the Hasso-Plattner Institute of Design at Stanford, universally called the
d.school, and popularised through the design consultancy IDEO from the 1990s onward.
The version most people mean is the five-stage teaching model: **empathize, define,
ideate, prototype, test**. Its distinguishing move is to delay committing to a solution
until the problem has been stated in the user's own terms, which sounds obvious and is
almost never what happens in practice.
Because it is a process rather than a framework, judging it is different too. A framework
is right or wrong about a market. A process is either run properly or performed, and the
performed version is common enough to be the main thing this page warns about.
The stages are explicitly **iterative, not sequential**. They are drawn in a row because
a row fits on a slide, and that diagram is responsible for most of the misuse.
## Why it matters
The default way a product gets built is that somebody has an idea, the team builds it, and
the market is consulted at the end. Design Thinking is a structured argument for consulting
the market first, and for spending real time on the problem statement before anyone opens
an editor.
The cost of not doing it is not usually a bad product. It is a competent product aimed at a
problem nobody had, which is much harder to detect because everything about the execution
looks fine.
This is the failure that survives a retrospective. The code was clean, the launch went
out on time, the design review passed, everyone did their job. The thing works and nobody
wants it, and there is no line in the post-mortem template for that.
## The five stages
## When to run it
## Design Thinking in practice: the GE Adventure Series
The most quoted empathy case in the discipline, and it is quoted because the machine was already excellent.
## Design Thinking vs the alternatives
## When it won't help you
## Further reading
- Tim Brown, *Change by Design* (2009). The IDEO account.
- The Stanford d.school's Bootcamp Bootleg, a free short guide to running the five stages.
- [The Mom Test](/frameworks/mom-test). How to run the empathize stage without leading the witness.
- [Jobs to be Done](/frameworks/jobs-to-be-done). A sharper instrument for the same underlying question.
- [Lean Startup validation](/frameworks/lean-startup-validation). What to do with the options design thinking generates.
- [Empathy Maps](/frameworks/empathy-maps). The standard tool for synthesising the empathize stage.
### Disruptive Innovation: What Christensen Actually Meant
URL: https://shipfit.ai/frameworks/disruptive-innovation
> Low-end and new-market disruption, why incumbents rationally ignore both, and why most things called disruptive are not disruptive in Christensen's sense.
## What disruptive innovation is
Disruptive innovation is Clayton Christensen's theory. It explains how smaller entrants
displace established firms. It appeared in *The Innovator's Dilemma* (1997) and was extended
in *The Innovator's Solution* (2003). Christensen restated it in a 2015 HBR article, written
largely because the term had been so thoroughly misused.
It describes a **specific mechanism**, not a synonym for success. An entrant starts either
at the low end of an existing market, serving customers over-served by current products, or
in an entirely new market among people who previously went without. Incumbents rationally
ignore both, because serving either would reduce their margins. The entrant improves along
a trajectory until it satisfies mainstream customers, by which point the incumbent's
position is gone.
The word now generally means "new and successful". That is not what the theory says, and
it strips out the part that makes it useful.
## Why it matters
The practical value is not that you should aim to be disruptive. It is that the theory
tells you what kind of fight you are in. The answer changes what you need.
If you are selling a better product to the incumbent's best customers, you are in a
sustaining fight. Those are winnable, and they are won with resources, distribution and
execution, all of which the incumbent has more of. If you have entered somewhere they are
declining to go, you are protected by their own economics for as long as that calculation
holds.
Founders routinely believe they are in the second situation. Most are in the first.
The tell is simple and unwelcome. If your deck compares you favourably to the incumbent
on the incumbent's own measures, you are in a sustaining fight, whatever the cover
says.
While we are being blunt about what founders believe, here is the single most common
diagnosis ShipFit's strategy stage returns. It is not "your idea is bad". It is barely about
quality at all.
## The three positions
## The incumbent's calculation
The part of the theory that gets lost is that the incumbent is behaving correctly.
Their best customers are asking for more capability, not less. The disruptive segment is
small. Its margins sit below their corporate average, so serving it would dilute the
numbers they are measured on. Every incentive in a well-run company points away from it.
The manager who proposed chasing it would lose the argument on the merits.
## When to use it
## Against the alternatives
## Disruption in practice: Kodak
The most misused case in business writing, so it is worth stating what actually happened.
## When it won't help you
## Further reading
- Clayton Christensen, *The Innovator's Dilemma* (1997). The original.
- Christensen, Raynor & McDonald, *What Is Disruptive Innovation?*, HBR (2015). Written to correct twenty years of misuse.
- Jill Lepore, *The Disruption Machine*, The New Yorker (2014). The best-known critique, worth reading alongside.
- [7 Powers](/frameworks/7-powers). Counter-positioning, which is the same insight expressed as a barrier.
- [Blue Ocean Strategy](/frameworks/blue-ocean-strategy). Overlaps substantially with new-market disruption.
- [Jobs to be Done](/frameworks/jobs-to-be-done). Christensen's other theory, and the one that explains what non-consumers do instead.
### Emotional Friction States: Ranking Pain by What It Feels Like
URL: https://shipfit.ai/frameworks/emotional-friction-states
> A five-state hierarchy for scoring how much a problem hurts: overwhelm, anxiety, frustration, fear and resignation, and what each one predicts about willingness to buy.
## What the hierarchy is
Emotional Friction States is a five-level scale for judging how badly a problem hurts,
based on the emotional state it leaves someone in rather than on how often it happens.
It is **ShipFit's own model** rather than an established academic framework, and it is
worth saying that plainly. It draws on ordinary practice in customer discovery and on
behavioural economics, and it is offered here as a heuristic for ranking problems you have
already collected, not as received theory.
The reason it exists is that "how painful is this?" is a question people answer relative to
what they believe is possible. Someone who has concluded nothing can be done will rate a
serious problem as mild. Reading the state from their language and their workarounds
bypasses that.
## Why it matters
Ask a room of founders to rank their customers' problems and they will rank them by how
often they hear about them. That measures which customers are loudest, not which problems
are worth solving, and the two correlate weakly.
Loud and expensive are not the same thing. They get confused because only one of them
emails you.
Frustration in particular is over-represented in every feedback channel. It produces the
most complaints and often the least willingness to pay, because a frustrated person has
already found a workaround they can live with. Meanwhile the person who quietly rebuilt
half your workflow in a spreadsheet, and mentions it as though it were normal, never files
a ticket at all.
The scale of what a proper problem sweep turns up, from ShipFit's own corpus: ten problems
per idea, four in ten of them happening weekly, and a mean intensity of 70 out of 100. Read
that last figure sceptically. It is scored by a model from a founder's own description,
which is two layers of optimism stacked on top of each other.
## The five states
## Reading resignation
Resignation is the state worth the most and the hardest to detect, because every signal a
product team normally relies on depends on somebody complaining.
The tells are behavioural rather than verbal, and none of them involves a complaint.
## When to use it
## Against the alternatives
## Friction states in practice: Juicero
Before the hierarchy, a company that built superbly against a friction state that did not exist.
## When it won't help you
## Further reading
- [The Mom Test](/frameworks/mom-test). How to collect problems in a form that can be scored at all.
- [Jobs to be Done](/frameworks/jobs-to-be-done). The four forces, which explain why a painful problem still does not produce a switch.
- [Van Westendorp](/frameworks/van-westendorp). Turning an intensity band into an actual price.
- [ICE scoring](/frameworks/ice-scoring). Sequencing what survives the ranking.
- [Empathy Maps](/frameworks/empathy-maps). Where the say-do gap that reveals resignation becomes visible.
### Empathy Maps: Says, Thinks, Does, Feels
URL: https://shipfit.ai/frameworks/empathy-maps
> The four-quadrant empathy map from Dave Gray and Gamestorming: what goes in each quadrant, where the contradictions live, and why most maps are decoration.
## What an empathy map is
An empathy map is a template for organising what you know about one user into four
quadrants: what they **say**, what they **think**, what they **do** and what they **feel**.
It was created by Dave Gray of the consultancy XPLANE and popularised through the 2010
facilitation book *Gamestorming*.
Its purpose is not to summarise a user. It is to put four kinds of evidence side by side so
that the contradictions become visible, and the most valuable contradiction is between what
somebody says and what they actually do.
A user who tells you their current tool is fine, and who has quietly built three
spreadsheets around it, has told you something that neither quadrant reveals on its own.
## Why it matters
Interview notes are unusable in raw form. Twenty pages of transcript contain the finding
somewhere, and nobody on the team will read them twice. The map exists to compress that
into something a group can look at together and argue about.
The failure it prevents is subtle: a team that never lays the quadrants side by side will
reliably build for what users **said**, because that is the part that gets written down
and repeated. What they did is harder to record and much more predictive.
The give-away phrase is "users told us". It is almost never followed by a description of
anything a user did.
## The four quadrants
## When to run it
## Empathy mapping in practice: Google Glass
An empathy map has quadrants for what the user sees and feels. This is what happens when you fill them in for the user and nobody else.
## Empathy maps vs the alternatives
## When it won't help you
## Further reading
- Dave Gray, Sunni Brown & James Macanufo, *Gamestorming* (2010). Where the four-quadrant version was popularised.
- Dave Gray's 2017 Empathy Map Canvas, which adds goals, pains and gains around the original quadrants.
- [The Mom Test](/frameworks/mom-test). How to gather the material a map synthesises.
- [AEIOU](/frameworks/aeiou-framework). A structure for capturing observation in the field.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas). Where the synthesis turns into commercial decisions.
- [Customer Journey Mapping](/frameworks/customer-journey-mapping). When the question is about sequence rather than snapshot.
### Freemium Strategy: When a Free Tier Actually Works
URL: https://shipfit.ai/frameworks/freemium-strategy
> Freemium converts 2 to 5% of free users. The four conditions that have to hold before that arithmetic works, and why most B2B products fail at least one.
## What freemium is
Freemium offers a **permanently free tier** alongside paid plans. The free users are funded
out of the paying minority.
The term was coined by Jarid Lukin and popularised by Fred Wilson in 2006, though the model
long predates the name. What makes it distinctive is not that some users pay nothing. It is
that most of them never will, and the business is designed around that.
Published benchmarks put typical free-to-paid conversion at **2 to 5%**. That number is not
a failure state. It is the model working as designed, and it is why freemium is a volume
strategy before it is a pricing one.
## Why the arithmetic decides it
Start from the conversion rate and work backwards. At 3%, reaching three thousand paying
customers requires a hundred thousand free users. At 2%, it requires a hundred and fifty
thousand.
Now write down the total number of people who could plausibly use your product. For a
consumer tool or a horizontal product used by individuals, a hundred thousand is
reachable. For a B2B product serving, say, product teams at companies of 10 to 200 staff,
the entire addressable population may be smaller than the free-user count the model needs.
That is usually where the conversation should end, and usually where it does not.
The reason it does not end there is that freemium feels like a growth decision, and
growth decisions are exciting. This is a division problem. Division problems are not.
It is not only founders who reach for freemium by reflex. Given 173 products to price,
ShipFit's own engine recommended freemium-plus-tiered on nearly three-quarters of them,
including plenty where the audience arithmetic above cannot possibly work. When the default
answer is the same regardless of the question, the default is doing the thinking.
## The four conditions
## Where to put the boundary
The upgrade boundary should sit where **value genuinely increases**, not where withholding
something causes the most frustration.
This distinction sounds soft and is measurable. A limit people understand gets forgiven and
frequently converts: they hit it because they are getting value and want more. A limit that
feels punitive converts almost nobody, because the emotion it produces is resentment rather
than desire, and it costs you the goodwill that made offering a free tier worthwhile.
Role-based boundaries tend to work well. Gating collaboration or administration features
puts the line at team value rather than individual frustration, and published work on
freemium gating suggests it materially outperforms crippling core functionality.
## When to use it
## Against the alternatives
## Freemium in practice: Dropbox
A free tier that worked, examined for why, because the reasons are more specific than they look.
## When it won't help you
## Further reading
- Fred Wilson's 2006 writing on freemium, where the term entered wide use.
- [Value-Based Pricing](/frameworks/value-based-pricing). What the paid tiers should be anchored to.
- [Usage-Based Pricing](/frameworks/usage-based-pricing). The other model where the metric decision dominates.
- [Van Westendorp](/frameworks/van-westendorp). Pricing the paid tier, once the free one is decided.
- [Product-Led Growth](/frameworks/product-led-growth). The motion freemium usually sits inside.
- [TAM SAM SOM](/glossary/tam-sam-som). The audience arithmetic that decides whether any of this works.
### GTM Strategy Framework: Building a Launch Plan
URL: https://shipfit.ai/frameworks/gtm-strategy-framework
> The six parts of a go-to-market plan, the decision each one settles, and how to match a channel to your product rather than to your preferences.
## What a GTM strategy framework is
A GTM strategy framework is a structure for deciding how a product reaches its first
customers. It resolves six things in order: the **segment**, the **motion**, the
**channel**, the **message**, the **offer**, and the **metrics and timeline**.
It has no single author. The shape consolidated through enterprise marketing practice in
the 1990s and 2000s, and reached startups mainly through two books: Geoffrey Moore's
*Crossing the Chasm* (1991), which argued for winning one narrow segment before any other,
and Weinberg and Mares's *Traction* (2015), which argued for testing channels broadly and
cheaply before concentrating on one.
The framework is not the same thing as go-to-market itself. If you want the definition and
the four motions explained on their own, that is the [GTM glossary entry](/glossary/gtm).
This page is about the artefact: what a plan contains and how its parts have to agree.
## Why it matters
Most launch plans are not wrong. They are inconsistent, which is harder to see and worse
to live with. The segment section describes a solo freelancer, the pricing section implies
a departmental budget, and the channel section proposes a sales motion neither of them
supports. Each part was written by somebody competent, on a different day, without reading
the others.
Nobody catches it because reviewing a plan means reading it, and reading it means agreeing
with each section in turn. Contradiction between sections is invisible at the sentence
level, which is where all the attention goes.
The specific cost is a quarter. Not a failed launch, because a launch built on an
inconsistent plan usually produces some activity and some signups. It produces a number
nobody can interpret, which is more expensive than a clear failure, because it is
defensible for another three months.
## The six parts
Each part exists to settle one decision. A part that describes an intention rather than
settling a decision is not a section of a plan, it is a section heading with prose
underneath.
The middle column is the useful one. Every GTM template on the internet lists these six
headings. Very few of them mention that "small and mid-size businesses" is a census
category rather than a segment, or that "pricing TBC" is not a deferred detail but an
undecided segment, since price and segment are the same decision looked at twice.
## Matching channels to the product
Channels are usually chosen from familiarity, which is to say from whichever one somebody
on the team has done before. That is not irrational, and it is also not the question. The
question is which channels this product could pay for.
Every channel has a precondition. Paid needs a decided price, a converting page and margin
that survives the click cost. Organic search needs people searching for the problem in
words you can rank for, which rules it out for genuinely new categories, because nobody
searches for something they cannot name.
Note the last column. A channel that takes four months to report is not worse than one
that reports in three days, but choosing it without knowing that is how a launch loses a
quarter without anybody making a mistake.
## GTM in practice: Slack
Worth a case where the channel was derived from the product rather than picked from a
list, because it is the part of this that sounds abstract until you see it done.
## Against the alternatives
## When to run it
## When it won't help you
## Further reading
- Geoffrey Moore, *Crossing the Chasm* (1991), for the argument that one narrow segment
must be won completely before any other is attempted.
- Gabriel Weinberg and Justin Mares, *Traction* (2015), for the nineteen channels and the
case for testing cheaply before concentrating.
- [GTM (go-to-market)](/glossary/gtm) for the definition and the four motions.
- [Product-led growth](/frameworks/product-led-growth) for the motion with the strictest
preconditions.
- [Brand strategy framework](/frameworks/brand-strategy-framework), which answers what you
say once this has answered where you say it.
### Hamilton Helmer's 7 Powers: Which One Can You Actually Get?
URL: https://shipfit.ai/frameworks/7-powers
> The 7 Powers, each with its benefit and its named barrier, plus the Power Progression that decides which of them a startup can realistically build and when.
## What 7 Powers is
7 Powers is a framework for identifying durable competitive advantage. It was published in
2016 by Hamilton Helmer, a strategy adviser and investor, in the book *7 Powers: The
Foundations of Business Strategy*.
Its central claim is that only seven conditions allow a business to sustain returns above
its cost of capital once competitors have had time to respond. Helmer calls those
conditions *powers*. Each one requires two things at once: a **benefit**, meaning it
produces margin or volume for the business, and a **barrier**, meaning a competitor who
understands exactly what you did, and can afford to copy it, still rationally chooses not
to. An advantage with a benefit and no barrier is a head start, not a power.
The seven are scale economies, network economies, counter-positioning, switching costs,
branding, cornered resource, and process power. The framework is used widely in technology
investing, product strategy and startup positioning, and Helmer's terminology (particularly
counter-positioning) has entered general use.
The part that makes it practical rather than a taxonomy is the machinery underneath the
list. Seven powers rest on only four barriers, each of those barriers becomes available in
a specific phase of a business, and that is what determines which of the seven you can
realistically build today.
## Why it matters
Founders pitching investors say some version of "we will win because our product is
better". The real question underneath the polite nod is what stops a larger competitor from
copying you and crushing you with distribution. If the answer is "we will move faster",
that is a tactic, and tactics get copied.
The cost of not having an answer is not that you lose immediately. It is that you look fine
for about eighteen months.
That is the cruel part. Nothing looks wrong during the period when you could still have
done something about it. The metrics are up, customers are pleased, and the competitor who
will eventually take the market has not yet noticed you exist. The bill arrives later, all
at once, presented by somebody with a larger sales team.
Before the equation, a number that ought to embarrass us slightly, and does.
The most useful thing 7 Powers could possibly do inside an automated tool is tell a founder
their idea has no moat. We built an engine that scores exactly that, out of ten, and then we
went and looked at what it actually says.
Helmer states this formally in one equation, which is worth internalising because it shows
that power is not something you bolt on next to a good market. It is half the terms.
## When to run it
Three different questions get called "when" on this topic, and confusing them is common.
*When can each power be created?* is answered by the Power Progression further down. *Where
does this sit relative to other frameworks?* is answered at the end of the page. This
section is the third question: when should you sit down and do this analysis at all.
## What actually counts as a power
Helmer's definition is strict, and it has two halves. A power must produce a **benefit**
(margin, volume, pricing freedom) and it must have a **barrier** (a competitor who
understands exactly what you did, and can afford to copy it, still rationally declines).
Most claimed advantages have one and not the other.
This is where "we move faster" fails. It is a genuine benefit, shipping features costs you
less than it costs them, with no barrier whatsoever, because any competitor can hire
engineers. It is a head start, and head starts get taken back.
## The seven powers
## The barrier is the whole test
Seven powers, but only four barriers. Collapsing them shows what is really doing the work,
and it sets up everything that follows.
Notice the right-hand column. Each barrier belongs to a phase of the business, and it is
the **barrier** that is phase-bound. The powers simply inherit their phase from the barrier
they rest on. That single observation is the framework's most useful and least quoted
result.
## The Power Progression
Helmer's Power Progression maps each power to the window in which it can be *created*. Not
where it shows up on a balance sheet years later, but the phase during which the barrier
becomes available to you at all.
Read left to right, this is a schedule. It tells you that a power missed in its window is
not simply harder later, it is structurally unavailable, because the barrier it depends on
belongs to a phase you have left.
## Which power you can actually get
Now the two previous sections pay off. A startup sits at origination. Origination makes
exactly two barriers available. Therefore exactly two powers are on the table, and the
other five are ruled out by arithmetic rather than ambition.
Cornered resource is worth testing honestly and is genuinely rare: most claimed cornered
resources turn out to be ordinary hiring, which any competitor can also do. That leaves
counter-positioning as the realistic answer for most new entrants, which is why the rest of
this page spends its time there.
## Counter-positioning, and why incumbents don't respond
The usual telling of the Netflix story is that Blockbuster failed to act when they should
have. That reading is comforting and useless, because it suggests your protection is the
incumbent being slow.
Helmer's version is the opposite, and far more useful: the incumbent's non-response is
**correct on their own numbers**.
## How to find your counter-position
The pattern: find what the incumbent is financially dependent on, find the buyer that
dependency underserves, and adopt the model that serves that buyer and which the dependency
forbids them from matching.
## 7 Powers in practice: Vanguard
Helmer's own worked example, and the clearest demonstration of the difference between a barrier and a head start.
## 7 Powers vs Porter, Blue Ocean and "moats"
These are usually presented as rival frameworks. They are not. They answer different
questions at different levels, and they answer them in sequence.
## When 7 Powers won't help you
## ShipFit and 7 Powers
Stage 4 of ShipFit (How to Win?) applies 7 Powers as a gate. It asks which power the
business will hold at maturity, rejects "better product" and "we move faster" as answers,
and looks for counter-positioning candidates by analyzing your defined buyer and
competitive landscape for the incumbent dependencies that might be exploitable.
If you cannot name a power with conviction, ShipFit recommends pivoting to a buyer segment
with a clearer counter-positioning angle, or killing the idea. Most ideas do not have a
power. That is not a flaw in the analysis.
## Where this sits in the sequence
A power protects margin. It does not create demand, and it cannot be built around a product
nobody has chosen to keep using. Run this after you have evidence of that, not before.
## Further reading
- Hamilton Helmer, *7 Powers: The Foundations of Business Strategy* (2016). The source. Around 200 pages, dense but compact.
- [Blue Ocean Strategy](/frameworks/blue-ocean-strategy) (Kim & Mauborgne, 2005). The complementary lens: finding the space where a power is easier to establish in the first place.
- [Jobs to be Done](/frameworks/jobs-to-be-done). For identifying the buyer segment your counter-position will serve.
- [Lean Startup validation](/frameworks/lean-startup-validation). For testing whether your counter-positioning hypothesis survives real buyers.
- [The Mom Test](/frameworks/mom-test). The evidence you need before any of this is worth doing.
- [Startup valuation calculator](/calculators/startup-valuation). What a durable power is worth once it shows up in the multiple.
- [Churn rate](/glossary/churn). The clearest evidence a power is real: customers who do not leave.
### ICE Scoring: Prioritize Features Without Hand-Waving
URL: https://shipfit.ai/frameworks/ice-scoring
> ICE scoring ranks ideas by Impact times Confidence times Ease. How to score it honestly, where the arithmetic misleads, and how it really differs from RICE.
## What ICE scoring is
ICE scoring is a method for ranking ideas by multiplying three estimates: **Impact**,
**Confidence** and **Ease**. Each is rated 1 to 10, and the product is the score.
It was formalized and popularized by the growth marketer Sean Ellis around 2014, for
prioritizing growth experiments at speed. The framework predates him in various forms; what
Ellis contributed was the specific three-term version and the practice of scoring a backlog
as a team.
Its purpose is not precision. Three subjective estimates multiplied together do not produce
an accurate forecast, and treating the output as one is the most common misuse. The purpose
is to make the reasoning behind a ranking explicit, and in particular to force the
Confidence term into the conversation, where it functions as an audit of how much evidence
anyone actually has.
## Why it matters
Most founder feature lists are ranked by enthusiasm. What the founder is excited about
floats to the top, what the team agrees is important sits in the middle, and what nobody
loves slides off the bottom. This produces a defensible-looking order with no reasoning
attached, which means it cannot be argued with and cannot be wrong.
ICE's contribution is that it makes the disagreement specific. Two people who rank an item
differently now have to disagree about a number and say which one, and that conversation is
usually more valuable than the score it produces.
The Confidence term is where this bites. Asking "what is your confidence, and what evidence
is it based on?" reliably exposes that the exciting idea is a hunch and the boring one has
data behind it.
Expect that conversation to be mildly unpleasant the first two or three times. That is
the framework working. A scoring session where everybody agrees immediately has not scored
anything.
## When to run it
## A worked ranking
That ordering is the framework's characteristic distortion and it is worth sitting with.
The email digest is a small feature nobody would call strategic. It ranks near the top
because Ease and Confidence are both high, and they carry the same weight as Impact.
ICE will reliably surface cheap, certain, low-value work. That is a feature when you are
running weekly growth experiments and a serious problem when you are building a product,
which is why the ranking is an input to a decision rather than the decision.
## Confidence is the audit
Impact and Ease are estimates. Confidence is a claim about evidence, and it is the only one
of the three that can be checked.
Scores drift upward over time if nobody enforces this, because a high Confidence gets your
idea built. The term is worth defending precisely because it is the one with an incentive
attached.
## ICE vs RICE and the others
The practical rule: use ICE when everything on the list reaches a broadly similar audience,
which is the normal early-stage case. Move to RICE when that stops being true, usually once
you have distinct user segments and features that serve only one of them.
## When it won't help you
## ShipFit and ICE
ShipFit uses ICE-style scoring in Stage 5 (What's V1?) to rank candidate features once the
MoSCoW sort has decided what is in scope. Each feature carries a score and an effort tag,
grouped into Differentiator, Delight and Operational buckets so the build sequence is
ranked rather than guessed. The discipline ICE forces, naming the evidence behind each
Confidence number instead of guessing, is the part founders skip, and the scored list makes
that gap visible.
## Where this sits in the sequence
ICE comes third: after the release goal is known and after the scope has been cut.
## Further reading
- Sean Ellis and Morgan Brown, *Hacking Growth* (2017). The ICE method in the context it was designed for.
- Intercom's writing on RICE, which introduced the reach term and the effort divisor.
- [MoSCoW](/frameworks/moscow). The first cut, run before this one.
- [Lean Startup validation](/frameworks/lean-startup-validation). What the ranked experiments feed.
- [Superhuman PMF engine](/frameworks/superhuman-pmf-engine). Where the roadmap split comes from once you have users to survey.
- [Jobs to be Done](/frameworks/jobs-to-be-done). How to establish the metric that Impact is measured against.
### Jobs to be Done (JTBD): Stop Building Features Nobody Hires
URL: https://shipfit.ai/frameworks/jobs-to-be-done
> The JTBD framework in plain terms: the four forces of progress, the switch timeline, and how the Christensen and Ulwick schools actually differ.
## What Jobs to be Done is
Jobs to be Done is a framework for understanding why customers buy. It was developed
through the 2000s by Clayton Christensen, Bob Moesta and colleagues at Harvard Business
School, growing out of Christensen's earlier work on disruptive innovation.
Its central claim is that people do not buy products so much as **hire** them to make
progress on a job in their life, and that they fire them when something else does the job
better. The job, not the customer's demographic profile, is the stable unit of analysis.
Two people with nothing in common can hire the same product for the same job, and one
person can hire completely different products for the same job at different moments.
The practical consequence is that your competition is not the category you think you are
in. It is whatever the customer would otherwise have done, including nothing.
One thing to know before reading further: **two distinct schools share this name**, with
different units of analysis, different research methods and different outputs. Most
confusion about JTBD comes from reading one and then the other without being told they
differ.
## Why it matters
A feature list answers the question "what does our product do". It cannot answer "why
would anyone switch to it", and those are different questions with different answers.
The milkshake study is the standard illustration. A fast-food chain trying to sell more
milkshakes studied milkshake buyers and improved the milkshake along every dimension those
buyers said mattered. Sales did not move. Studying the job instead revealed that a large
share of milkshakes were bought before 9am by commuters who needed something to occupy a
long, boring drive, that would not leave crumbs, and that lasted the whole journey. The
competition was not other milkshakes. It was bananas, bagels and boredom.
Nothing about the buyer's demographics predicted that. The job did.
There is a small irony in how popular this has become. When ShipFit's engine is turned
loose on a real idea and allowed to pick whichever strategic framework fits, it reaches for
Jobs-to-be-Done more than any other, on roughly four ideas in ten. Which is either a
vindication of the theory or evidence that JTBD is the framework you reach for when you are
not sure what else to reach for. Both readings are available.
## When to run it
## The four forces
A switch is not caused by the new product being good. It is caused by four forces
resolving in its favour, and two of them are working against you the whole time.
## The timeline of a switch
The forces explain whether. This explains when, and the answer is usually "much earlier
than you think".
The practical implication is uncomfortable. If you only talk to people who bought, you are
sampling the end of this line, and the interesting decisions happened at the start of it.
Switch interviews are designed to reconstruct the whole timeline, working backwards from
the purchase to the first thought.
## The two schools
## Ranking what to build: the opportunity score
The outcome school's contribution is a way of turning "what should we build next" into
arithmetic. Customers rate each desired outcome on importance and on how well existing
solutions already deliver it. The gap is the opportunity.
## Writing a job statement
The progress school's output is a sentence, and the format matters because a loose one
smuggles the solution back in.
## Jobs-to-be-Done in practice: the milkshake study
This is the case that made the theory famous, and it deserves the space because the useful part is usually left out of the retelling.
## Jobs to be Done vs the alternatives
## When it won't help you
## ShipFit and Jobs to be Done
ShipFit uses JTBD at Stage 3 (What Hurts?) to reframe the problem statement as a hire
statement rather than a feature list. That statement then anchors every downstream
decision: who pays at Stage 2, what wins at Stage 4, what ships in V1 at Stage 5. Jobs
framed as features produce different, and usually bigger, first releases than the same
problem framed as a job, which is why the reframing happens before scoping rather than
after.
## Where this sits in the sequence
JTBD comes after you know the problem is real and before you decide what to charge for
solving it.
## Further reading
- Clayton Christensen, Taddy Hall, Karen Dillon & David Duncan, *Competing Against Luck* (2016). The progress school in book form.
- Tony Ulwick, *Jobs to be Done: Theory to Practice* (2016). The outcome school, and the source of the opportunity algorithm.
- Bob Moesta, *Demand-Side Sales 101* (2020). The most practical treatment of switch interviews.
- [The Mom Test](/frameworks/mom-test). How to run the conversations without leading the witness.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas). Where the job statement becomes something a whole team can use.
- [Van Westendorp](/frameworks/van-westendorp). What to run once you know the job and need a price.
- [7 Powers](/frameworks/7-powers). Orthogonal, and necessary: knowing the job does not stop anyone else serving it.
### Market Context Assessment: The Forces You Do Not Control
URL: https://shipfit.ai/frameworks/market-context-assessment
> A structured check on the external conditions around a market: regulation, technology, economics, behaviour and timing, and what each one changes about a launch decision.
## What a market context assessment is
A market context assessment is a structured check on the external conditions around a
market: **regulation, technology, economics, buyer behaviour and timing**.
It is **ShipFit's own method** rather than an established academic framework, and it is
worth saying so. It adapts standard environmental-scanning practice, principally PESTEL
analysis, whose lineage runs back to Francis Aguilar's work in 1967, and narrows it to the
forces a founder can act on inside a launch decision.
The purpose is to surface the things that will decide the outcome regardless of how well
the product is built. Founders spend almost all their attention on variables they control
and very little on the ones they do not, and the second group frequently matters more.
## Why it matters
Most launch post-mortems name an internal cause: the product was wrong, the team was
wrong, the marketing did not work. A meaningful share of failures are actually external,
and the most common of those is timing.
Being early is the difficult one, because it is indistinguishable from being wrong until
much later and consumes exactly the same runway. A product requiring a behaviour people
have not adopted fails in a way that looks identical to a product nobody wanted, and the
team learns the wrong lesson from it.
Which is the expensive part. A team that was early concludes the market does not exist,
shelves the idea, and watches somebody else ship more or less the same thing three years
later to considerable applause.
## The five forces
## The enabling condition
If there is one question to keep from this method, it is: **what became true recently that
makes this possible now?**
A good answer is specific and dated. Inference costs fell by an order of magnitude. A
regulation came into force. Remote work made a category of tool normal that was fringe
before. Each explains both why the opportunity exists and roughly when the window opened.
The absence of an answer is the finding.
## When to run it
## Against the alternatives
## Market context in practice: Webvan
The canonical case of a correct idea assessed against the wrong decade.
## When it won't help you
## Further reading
- Francis Aguilar, *Scanning the Business Environment* (1967). The origin of the practice this adapts.
- [TAM SAM SOM](/glossary/tam-sam-som). Sizing, once the conditions look workable.
- [Disruptive Innovation](/frameworks/disruptive-innovation). Why a favourable condition often produces several entrants at once.
- [7 Powers](/frameworks/7-powers). What you will need once the tailwind has brought your competitors in too.
- [The Mom Test](/frameworks/mom-test). The demand evidence a context scan cannot substitute for.
### MoSCoW Prioritization: Must/Should/Could/Won't to Scope V1
URL: https://shipfit.ai/frameworks/moscow
> MoSCoW sorts features into Must, Should, Could and Won't against a fixed date. The 60% capacity rule is the part most teams drop, and dropping it breaks the method.
## What MoSCoW is
MoSCoW is a prioritization method that sorts work into four fixed categories: **Must have,
Should have, Could have** and **Won't have**. The lowercase o's exist only to make the
acronym pronounceable.
It was created in 1994 by Dai Clegg at Oracle UK, for the Dynamic Systems Development
Method, an early agile framework. That origin matters more than it looks, because DSDM
assumed a **fixed delivery date** with variable scope, and MoSCoW is the instrument that
varies the scope.
Without a fixed date the method does nothing. If the deadline can move, everything can be
a Must, and the four categories become four labels applied optimistically. The discipline
is not in the buckets; it is in the question you put to each item: can this version ship
without it?
## Why it matters
The most common scope failure is not a missed deadline. It is a feature list where every
item carries the same urgency, which is what happens when nobody is willing to make the
sorting decision.
That list then meets a fixed date, and the sorting happens anyway, in the last two weeks,
under pressure, by whoever is closest to the code. MoSCoW moves the same decision to the
start, when it can be made deliberately and communicated.
Anyone who has been in the room for the last-fortnight version knows what it produces.
The features that survive are the ones that were nearly finished, not the ones that
mattered. Sunk cost does the prioritising, and it is very bad at it.
If you would like to see the 60% rule being ignored at scale, we have data on that, and it
is ours. ShipFit proposes a feature set, sorts it into Lean, Balanced and Full packages, and
recommends one of them. Here is what a tool built to cut scope actually recommends.
## When to run it
## The 60% rule
This is the part that most implementations drop, and dropping it is what turns MoSCoW into
four labels.
A team that loads all its capacity into Must has not been ambitious; it has removed the
contingency and guaranteed a late release. When that happens the post-mortem usually blames
estimation, which is the wrong diagnosis. The estimates were fine. There was nowhere for
them to be wrong.
## A worked sort
## Won't is a commitment
The fourth bucket is where the method is usually undermined. Teams treat Won't as "maybe
later", which makes it a shelf rather than a decision, and a shelf provides no protection
against the request arriving again next week.
Won't means: we are willing to say publicly that this is not in this version. If you are
not willing to say it out loud, you have not sorted honestly, and the item is really a
Should you have not costed.
The test is uncomfortable and it is the point. A Won't list you would be embarrassed to
show a stakeholder is a Won't list that will not survive contact with one.
## Prioritisation in practice: Burbn becoming Instagram
A Must list of one, arrived at by looking at what people used rather than at what the team had planned.
## MoSCoW vs the alternatives
## When it won't help you
## ShipFit and MoSCoW
ShipFit applies MoSCoW in Stage 5 (What's V1?). The stage defines the V1 hypothesis, then
runs every candidate feature through the cannot-ship-without test, producing three MVP
packages (Lean, Balanced, Full) with the Must list explicit in each. Should and Could items
are parked in a V2 file with effort tags, so deferred work does not get re-litigated when
scope creep arrives later.
## Where this sits in the sequence
MoSCoW is the first cut. It comes after you know what the release is for and before you
decide what order to build it in.
## Further reading
- Dai Clegg & Richard Barker, *Case Method Fast-Track: A RAD Approach* (1994). Where MoSCoW first appears.
- The DSDM Consortium's Agile Project Framework, which documents the 60/20/20 allocation and the timebox assumption behind it.
- [ICE scoring](/frameworks/ice-scoring). What to run on the Must list once the sort is done.
- [Lean Startup validation](/frameworks/lean-startup-validation). What the scoped release goes on to test.
- [Jobs to be Done](/frameworks/jobs-to-be-done). How to establish the goal that Must is measured against.
- [The Mom Test](/frameworks/mom-test). How to be sure the problem is worth scoping at all.
- [MVP](/glossary/mvp). What the Must list adds up to.
### Pain Intensity Premium: Adjusting Price for How Much It Hurts
URL: https://shipfit.ai/frameworks/pain-intensity-premium
> A modifier that adjusts a baseline price by the emotional intensity of the problem it solves, and the sizeable caveats on using intensity as a pricing input.
## What the modifier is
The Pain Intensity Premium is an adjustment that moves a price **within an already-derived
range**, according to how acute the underlying problem is for the buyer.
It is **ShipFit's own model** rather than an established pricing framework, and that is
worth stating before anything else. It applies well-known findings about loss aversion and
urgency to a pricing decision. It has no empirical calibration, and it should be treated as
a heuristic for positioning inside a range rather than as a method for producing one.
The reason it exists is that two products can deliver identical measurable value and
command very different prices, and intensity explains a large part of the gap.
## Why intensity affects price at all
Loss aversion is one of the better-established findings in behavioural economics: people
work considerably harder to avoid a loss than to secure an equivalent gain.
Pricing inherits that asymmetry. A product framed as preventing something bad commands more
than an identical product framed as producing something good, and the size of that gap
tracks how vividly the buyer can picture the loss.
Which is why intensity matters and also why the model is dangerous. It is describing an
effect on the buyer's psychology, not on their budget, and those are different things that
frequently sit in different people.
Worth stating plainly, because the modifier is easy to over-apply: an intense pain held
by somebody with no budget is not a pricing signal. It is a sad story.
## The three conditions
## The bands
## When to use it
## When it won't help you
## Further reading
- [Emotional Friction States](/frameworks/emotional-friction-states). The intensity ladder this modifier reads from.
- [Value-Based Pricing](/frameworks/value-based-pricing). Where the baseline comes from.
- [Van Westendorp](/frameworks/van-westendorp). The acceptable range this moves within.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas). Establishing who actually holds the budget.
- [The Mom Test](/frameworks/mom-test). Reading intensity from behaviour rather than from ratings.
### Persona-Price Fit: Checking the Price Matches the Buyer
URL: https://shipfit.ai/frameworks/persona-price-fit
> A validation check that the price you set matches the segment you researched, and the four ways a defensible price still ends up aimed at the wrong person.
## What the check is
Persona-Price Fit is a validation step: a check that the price you arrived at is aimed at
the buyer you actually researched.
It is **ShipFit's own check** rather than an established framework, assembled from ordinary
segmentation and pricing practice. It sets no prices. It catches four specific mismatches
that survive a perfectly competent pricing process, and it takes under an hour if the
persona work and the pricing work were both done properly.
The reason it exists is that pricing and buyer research are usually done by different
people at different times, and nothing in either process checks that the outputs agree.
## Why the mismatch happens
Buyer research and pricing are usually separated. The persona work happens early, driven by
whoever is doing discovery. The price gets set later, often under time pressure before a
launch, and frequently by someone looking at competitors.
Nothing in either process checks that the two agree. The persona document says the buyer is
a five-person product team; the price implies a buyer with a departmental budget. Both are
reasonable documents and they describe different companies.
Nobody catches it, because catching it requires one person to read both documents in the
same week, and there is rarely a reason for anyone to do that.
## The four checks
## Value is not budget
The check that catches the most careful teams is the second-order one: a successful
value analysis makes this failure **more** likely rather than less.
You quantify the problem, establish that it costs the buyer forty thousand a year, and
price at a defensible fraction of that. The arithmetic is sound. Then you discover the
buyer's discretionary budget for tooling in this category is two thousand, and the forty
thousand is spread across salaries that nobody is going to reallocate this year.
## When to run it
## Against the alternatives
## When it won't help you
## Further reading
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas). Establishing the payer and their authority.
- [Value-Based Pricing](/frameworks/value-based-pricing). Where the price being checked comes from.
- [Van Westendorp](/frameworks/van-westendorp). The acceptable range, and who it was measured on.
- [GTM](/glossary/gtm). Whether the motion the price implies is the one you have.
- [CAC / LTV ratio calculator](/calculators/cac-ltv-ratio). Whether the acquisition cost the price supports is the one you are paying.
### Playing to Win: The Five-Question Strategy Cascade
URL: https://shipfit.ai/frameworks/playing-to-win
> Lafley and Martin's strategy cascade: winning aspiration, where to play, how to win, capabilities, management systems, and why the middle two carry the weight.
## What Playing to Win is
Playing to Win is a strategy framework built around five linked choices. It was published
in 2013 by A.G. Lafley, the former CEO of Procter & Gamble, and Roger Martin, then dean of
the Rotman School of Management, and it codifies the approach behind P&G's turnaround.
The five questions are: **what is our winning aspiration, where will we play, how will we
win, what capabilities must we have,** and **what management systems are required**.
Its central argument is definitional and worth stating plainly. Strategy is a set of
integrated choices about where to compete and how to win there. It is not a plan, not a
vision, not a list of goals, and not a budget. Those are all things a company produces
instead of a strategy when nobody is willing to exclude anything.
## Why it matters
Ask most teams for their strategy and you get a list of goals with numbers attached. Grow
revenue 40%. Enter two new segments. Improve retention. None of these is a strategy,
because none of them says what you will not do, and a choice that excludes nothing is not
a choice.
The cascade's contribution is that it makes the avoidance visible. It is genuinely hard to
answer "where will we play" without either excluding something or noticeably dodging.
The dodge has a recognisable shape. It usually begins "initially we are focused on" and
then names three segments.
The where-to-play choice is also what a positioning statement has to inherit, which is why
[brand strategy](/frameworks/brand-strategy-framework) cannot usefully be run before this
one.
## The five choices
## The exclusion test
The single most useful thing in the framework is a question you can ask about any
where-to-play answer: **what does this rule out?**
"Small and medium businesses in English-speaking markets" rules out enterprise, rules out
non-English markets, and implies things about pricing and support. That is a choice.
"Businesses that need better customer feedback" rules out nothing at all. Every company
with customers qualifies, which means the answer constrains no downstream decision, which
means the next four questions have nothing to push against.
The same test applies to how-to-win. If a competitor could write your answer in their own
deck without changing a word, you have not chosen anything.
A confession about this framework's popularity, or lack of it. ShipFit's engine can select
Playing to Win when it fits, and across 240 ideas it has done so three times. Three.
That is not a criticism of Lafley and Martin. It is a comment on what an automated system
reaches for when asked to produce a strategy quickly: the frameworks that generate an answer
from the inputs it already has. Playing to Win does not generate an answer. It demands a
decision, and demanding decisions is not what software is good at.
## When to run it
## Playing to Win in practice: Olay
Lafley ran this one himself, which is the main reason the book exists.
## Playing to Win vs the alternatives
## When it won't help you
## Further reading
- A.G. Lafley & Roger L. Martin, *Playing to Win: How Strategy Really Works* (2013). The source.
- Roger Martin's writing on the strategy choice cascade, which is more direct about the exclusion test than the book is.
- [7 Powers](/frameworks/7-powers). Whether your how-to-win survives a funded competitor.
- [Blue Ocean Strategy](/frameworks/blue-ocean-strategy). One route to a how-to-win that is genuinely hard to copy.
- [Jobs to be Done](/frameworks/jobs-to-be-done). How to make a where-to-play choice from evidence rather than assertion.
- [The Mom Test](/frameworks/mom-test). Confirming the segment you chose actually wants this.
### Product-Led Growth: When the Product Is the Funnel
URL: https://shipfit.ai/frameworks/product-led-growth
> How product-led growth actually works: time to value, the self-serve threshold, why PLG is a distribution decision, and the conditions under which it fails.
## What product-led growth is
Product-led growth is a go-to-market approach in which the **product does the selling**.
Users find it, try it, get value and upgrade without speaking to anyone.
The term was coined at OpenView Venture Partners around 2016 and popularised through their
benchmark work; the practice predates the name by roughly a decade.
Its defining constraint is easy to state and hard to meet: **value has to arrive before a
conversation does**. Everything else about PLG is downstream of whether that is possible
for your product, and for a great many products it simply is not.
## Why it matters
The economics are the argument. A sales-led motion costs real money per deal: a rep, their
tooling, their manager, and weeks of calendar time. That cost is fixed regardless of deal
size, which is why it collapses below a certain contract value.
PLG removes it. Where it works, the cost of serving one more customer is close to the cost
of serving none, and growth compounds instead of being purchased.
Where it does not work, teams spend a year building a self-serve funnel that terminates at
an implementation call.
The funnel is usually excellent by then. That is what makes it hard to abandon: a year
of good work sits in front of a door the buyer was never able to open by themselves.
For a strategy that dominates conference talks, PLG is selected surprisingly rarely when an
engine is choosing on the merits: about one idea in thirteen that reaches the strategy
stage. The frameworks ahead of it are all about understanding the buyer. PLG is about how
the buying happens, which is a later question, and most ideas do not survive long enough to
reach it.
## The precondition
## The loop
## When to use it
## Against the alternatives
## PLG in practice: Atlassian
The case everyone cites, examined for the preconditions rather than the outcome.
## When it won't help you
## Further reading
- OpenView's product-led growth benchmark work, which defined the category and still supplies most of the reference numbers.
- [Freemium Strategy](/frameworks/freemium-strategy). The pricing decision this gets confused with.
- [Usage-Based Pricing](/frameworks/usage-based-pricing). How PLG expansion revenue is usually structured.
- [GTM](/glossary/gtm). The four motions, and where PLG sits among them.
- [Superhuman PMF engine](/frameworks/superhuman-pmf-engine). Whether the product is good enough to sell itself yet.
### SCAMPER: Seven Prompts for Forcing New Options
URL: https://shipfit.ai/frameworks/scamper
> Substitute, combine, adapt, modify, put to another use, eliminate, reverse. A structured ideation technique, what it is good at, and what it cannot do.
## What SCAMPER is
SCAMPER is a checklist of **seven prompts** for generating variations on something that
already exists: substitute, combine, adapt, modify, put to another use, eliminate, reverse.
Bob Eberle assembled it in 1971 from lists of idea-spurring questions published by Alex
Osborn, the advertising executive who originated brainstorming, in the 1950s.
It is a **divergence** tool. It generates options and has no mechanism whatsoever for
judging them, which is not a flaw so much as a division of labour that people forget to
complete.
## Why it matters
A group asked to generate ideas produces about four, then stops. This is reliable and it
has a specific cause: in an ordinary meeting each idea is evaluated as it appears, and
evaluation is the mode that ends generation.
SCAMPER interrupts this twice. It hands you a prompt so nobody is staring at a blank page,
and it forces you to stay on one prompt after the obvious answers have run out. The
interesting material appears specifically in that uncomfortable stretch.
It does not feel like the interesting material at the time. It feels like a meeting that
should have finished, which is precisely why most sessions stop at four ideas.
## The seven prompts
## Reverse the belief, not just the order
The Reverse prompt is usually run as "what if we did it backwards", which produces
novelty and rarely produces anything usable.
The stronger version inverts an **assumption** rather than a sequence. What if customers
wanted fewer choices? What if the slower version were better? What if the thing everyone
treats as the core feature were the part to remove?
## When to use it
## Against the alternatives
## SCAMPER in practice: the Post-it Note
Put to another use, running in slow motion over twelve years, inside a company that already owned the material.
## When it won't help you
## Further reading
- Bob Eberle, *SCAMPER: Creative Games and Activities for Imagination Development* (1971).
- Alex Osborn, *Applied Imagination* (1953), where the underlying question lists originate.
- [Blue Ocean Strategy](/frameworks/blue-ocean-strategy). The four actions, which are SCAMPER with a strategic objective attached.
- [Design Thinking](/frameworks/design-thinking). The process whose ideate stage this fits inside.
- [Biomimicry](/frameworks/biomimicry). A more specific version of the Adapt prompt.
- [ICE scoring](/frameworks/ice-scoring). What to do with forty options.
### Superhuman's PMF Engine: Rahul Vohra Made PMF a Number
URL: https://shipfit.ai/frameworks/superhuman-pmf-engine
> Rahul Vohra's method for measuring product-market fit and improving it: the 40% benchmark, the survey mechanics that make it comparable, and the roadmap it produces.
## What the Superhuman PMF engine is
The Superhuman product-market fit engine is a method for measuring product-market fit and
then systematically improving it. It was described in 2018 by Rahul Vohra, founder of the
email client Superhuman, in a First Round Review article.
It asks active users a single question: **how would you feel if you could no longer use
this product?** The score is the share who answer "very disappointed", and the benchmark is
**40%**. That benchmark comes from earlier work by Sean Ellis, who observed across a set of
startups that products passing it tended to find sustainable growth and products below it
tended to struggle.
Vohra's addition is the engine. The score alone is a diagnosis, and a diagnosis you cannot
act on is of limited use. The method turns the survey responses into a roadmap by
segmenting them: study the fans to understand what you are already good at, and read the
improvement requests from the winnable middle while ignoring the group that was never going
to buy.
## Why it matters
"Product-market fit" is the most-cited concept in startup advice and the worst-defined.
Most founders know they want it. Few can say whether they have it. Almost none can say
whether they are getting closer month over month, which means the single most important
thing about the company is being tracked by feel.
The engine's contribution is that it makes fit a number you can move, and it does so
without requiring scale. Superhuman ran this while still in a waitlisted beta.
That constraint matters more than it sounds. A method that needs ten thousand users
before it produces a signal is useless exactly when you most need one.
## When to run it
## Running the survey properly
This is where most implementations go wrong, and the errors are quiet: the number still
comes out, it just is not comparable to the benchmark it is being read against.
## The roadmap the score produces
## What to do below 40%
The benchmark is a heuristic and a low score is diagnostic rather than fatal. Three moves,
in order:
1. **Re-segment before you rebuild.** Vohra's first move was not a product change. It was
narrowing the population: filtering to a specific user type raised the score
substantially without shipping anything. A mediocre score across everybody often
conceals an excellent score inside a segment you have not named yet.
2. **Read the main-benefit answers from the fans.** If the fans cannot articulate a
consistent benefit, you do not have a positioning problem, you have a product one.
3. **Only then build.** Half on the fans' stated benefit, half on the middle's blockers.
The failure mode at this stage is rebuilding for the not-disappointed group, on the
reasoning that they are the ones who are unhappy. They are not unhappy. They are
indifferent, and indifference is not a problem you can build your way out of.
## The engine in practice: Superhuman
The case the method is named after, with the numbers it actually produced.
## The PMF engine vs the alternatives
## When it won't help you
## ShipFit and the Superhuman PMF engine
The ICP definition locked at Stage 2 is what you segment the survey responses against, and
refining it for the very-disappointed cohort is how positioning sharpens over time. ShipFit
front-loads that definition so the segmentation step has something to segment by, rather
than being invented after the first disappointing score arrives.
## Where this sits in the sequence
The PMF engine runs after you have shipped something and have users engaged enough to have
an opinion about losing it.
## Further reading
- Rahul Vohra, *How Superhuman Built an Engine to Find Product/Market Fit*, First Round Review (2018). The source.
- Sean Ellis's earlier writing on the 40% benchmark, which is where the threshold originates.
- [Lean Startup validation](/frameworks/lean-startup-validation). The loop this measures the output of.
- [ICE scoring](/frameworks/ice-scoring). How to sequence the work the survey generates.
- [Jobs to be Done](/frameworks/jobs-to-be-done). Why the fans love it, in a form you can act on.
- [Churn rate](/glossary/churn). The behavioural number to read this against.
- [ICP](/glossary/icp). What you segment the responses by.
### The Lean Startup: Build-Measure-Learn Without Vanity Metrics
URL: https://shipfit.ai/frameworks/lean-startup-validation
> Validated learning, the build-measure-learn loop, what an MVP actually is, the three engines of growth, and the ten pivots Ries names rather than one.
## What the Lean Startup is
The Lean Startup is a method for building companies under conditions of extreme
uncertainty. It was published in 2011 by the entrepreneur Eric Ries, drawing on lean
manufacturing, customer development work by Steve Blank, and agile software practice.
Its central claim is that a startup is not a small version of a large company but an
organization whose purpose is to learn what customers want as quickly and cheaply as
possible. The unit of progress is **validated learning**: evidence about a risky
assumption, obtained from real customer behaviour rather than from opinion or analysis.
The method runs as a loop. Build the smallest thing that tests one assumption, measure what
happens, learn whether the assumption held, and decide whether to persevere or pivot. Its
best-known instrument, the **minimum viable product**, is defined as an experiment rather
than as a small product, which is the distinction most teams lose.
## Why it matters
When *The Lean Startup* shipped in 2011 it changed how early-stage teams talked about their
work. Within a few years "lean" had become a cargo cult: founders called underbuilt
products lean, called underfunded teams lean, and skipped the discipline that gave the word
meaning.
The discipline is unglamorous and it is the whole method. Name the assumption that would
kill you. Build only enough to test it. Measure with cohorts so the answer can be no. Most
teams do the first and third steps informally and the second step enthusiastically, which
produces a lot of shipping and very little learning.
"We are being lean" has become, in most rooms, a sentence about the budget. Ries wrote a
book about how to be wrong quickly, and the industry heard a book about spending less.
That is a very ordinary way for a good idea to be digested.
There is a finding in ShipFit's corpus that sits uncomfortably beside all of this, and it is
the strongest thing in the dataset. Whether a founder finishes a nine-stage validation
process is predicted, with almost embarrassing accuracy, by what they were told at stage
one.
## When to run it
## What an MVP actually is
A minimum viable product is the smallest thing that produces validated learning about one
assumption. It is an experiment, and it is judged by what it teaches rather than by what it
does.
That definition rules out most things called MVPs. A stripped-down version of the real
product, shipped to see how it goes, is not an experiment because no assumption was named
in advance and no result would have counted as a failure. It is version 0.8.
The forms that qualify are often not software at all: a landing page that measures whether
anyone will give you an email address, a concierge service you deliver by hand, a
Wizard-of-Oz product with a person behind the curtain. Each isolates one belief and puts a
number on it.
## The three engines of growth
The loop tells you to measure. The engine tells you which number.
## Pivot is not a binary
"Pivot or persevere" is the phrase everyone remembers, and it makes the decision sound like
a yes or no about changing direction. Ries names ten pivots, and the useful question is
which single element to change while keeping the validated learning from everything else.
## Lean validation in practice: the Dropbox video
The most efficient assumption test in the canon, and a useful reminder of how narrow a good test is.
## The Lean Startup vs the alternatives
## When it won't help you
## ShipFit and the Lean Startup loop
ShipFit front-loads the part of the loop that costs the most when skipped. Stage 1 forces
the leap-of-faith assumption into the open, and Stages 2 to 7 are the validation work that
tests it before you write code: buyer at Stage 2, pain at Stage 3, solution approach at
Stage 4, MVP scope at Stage 5, pricing at Stage 6, demand proof at Stage 7. The output is
an MVP defined as an experiment with a named hypothesis attached, rather than a feature
list with the word minimum in front of it.
## Where this sits in the sequence
The loop is where a scoped release goes to find out whether it worked.
## Further reading
- Eric Ries, *The Lean Startup* (2011). The source.
- Eric Ries, *The Startup Way* (2017). The same method applied inside large organizations.
- Steve Blank, *The Four Steps to the Epiphany* (2005). The customer development work Lean Startup builds on.
- [The Mom Test](/frameworks/mom-test). Cheaper than an experiment when the question is answerable by asking.
- [Superhuman PMF engine](/frameworks/superhuman-pmf-engine). What to run when the question is whether you have product-market fit at all.
- [MoSCoW](/frameworks/moscow). How to cut a candidate list down to something a loop can actually test.
- [ICE scoring](/frameworks/ice-scoring). How to sequence the experiments once you have more than you can run.
- [CAC / LTV ratio calculator](/calculators/cac-ltv-ratio). The arithmetic behind the paid engine.
### The Mom Test: Validate an Idea Without Lying to Yourself
URL: https://shipfit.ai/frameworks/mom-test
> The Mom Test is Rob Fitzpatrick's framework for customer interviews that generate real signal. Not praise. Three rules, applied step-by-step, with examples.
## What the Mom Test is
The Mom Test is a set of rules for customer interviews. It was published in 2013 by the
entrepreneur Rob Fitzpatrick, in a short book of the same name.
Its central claim is that a bad interview is the interviewer's fault. If you ask your
mother whether your business idea is good, she will say yes, because she loves you. The
name is the test: a good question is one your mother could not lie about even if she
wanted to, because it asks about her life rather than your idea.
Three rules follow from that. Talk about their life, not your idea. Ask about specific
things that already happened, not what they would do in future. Talk less and listen more.
The method is widely used in startup customer discovery, and its vocabulary, particularly
the phrase "the Mom Test" itself, has entered general use in product and founder circles.
## Why it matters
The failure mode this method addresses is not that founders skip customer interviews. Most
do them. The failure is that the interviews return encouragement, the founder reads
encouragement as evidence, and eighteen months later nobody buys.
That failure is invisible while it is happening. A meeting full of compliments feels
better than a meeting full of awkward specifics, so the useless conversation is also the
more enjoyable one. Founders come away energised and no better informed.
There is a specific sound to it, once you have heard it a few times. Lots of "I would
definitely use that", no dates, no numbers, no names of people who have the problem now.
Warmth is not evidence. It is just warmth.
What does the output of doing this properly look like? Across 280 ideas run through
ShipFit's problem-discovery stage, founders surfaced 2,888 distinct problems, which is about
ten each. Note the intensity distribution, and in particular note that the average problem
scores 70 out of 100. Either founders are very good at finding painful problems, or
everybody involved is grading generously. We would not bet against the second.
## When to run it
## The three rules
## Good questions and bad ones
Most bad questions are bad in the same way: they ask for a prediction, an opinion, or a
yes. All three are free to give.
The pattern in the right-hand column is that every good question asks about something that
has already happened. Past behaviour is a fact the person cannot be polite about. Future
behaviour is a guess they are making on the spot, to be nice.
## Commitment: what a good meeting actually produces
This is the part most summaries of the method leave out, and it is the answer to the
question every founder has after a promising conversation.
## The Mom Test in practice: Quibi
The most expensive demonstration available of what happens when the research says yes and the behaviour was never asked.
## The Mom Test vs other ways of asking
## When it won't help you
## ShipFit and the Mom Test
ShipFit applies Mom Test discipline at Stage 3 (What Hurts?). It ranks real pain points by
frequency and intensity, then generates the questions you should be asking your buyers,
phrased in past-tense behaviour rather than future-tense intention. The output is a ranked
problem list, the buyer profile to recruit against, and a synthesis sheet to log what you
actually hear, so the answers feed forward into pricing, MVP scope and launch.
## Where this sits in the sequence
The Mom Test comes first. Everything downstream, the buyer, the price, the scope, the
positioning, assumes somebody has confirmed the problem is real and worth money.
## Further reading
- Rob Fitzpatrick, *The Mom Test* (2013). The source. Around 130 pages and readable in an evening.
- Rob Fitzpatrick, *The Workshop Survival Guide* (2019). Useful if your research is turning into group sessions, where the rules change.
- [Jobs to be Done](/frameworks/jobs-to-be-done). Where the conversations go next, once you know the problem is real.
- [Van Westendorp](/frameworks/van-westendorp). What to run once you need a number rather than a narrative.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas). How to turn a stack of interview notes into something the whole team can use.
- [Lean Startup validation](/frameworks/lean-startup-validation). The loop these conversations feed.
- [Churn rate](/glossary/churn). The number that eventually tells you whether the problem you confirmed was worth solving.
### Usage-Based Pricing: Choosing the Value Metric
URL: https://shipfit.ai/frameworks/usage-based-pricing
> How usage-based pricing works, the five tests a value metric has to pass, why hybrid models now dominate, and where consumption pricing quietly fails.
## What usage-based pricing is
Usage-based pricing charges according to **how much a customer consumes** rather than how
many people have access to the product.
The model is old in utilities and telecoms. It became mainstream in software through cloud
infrastructure pricing in the 2010s, and accelerated again with AI products, where the
cost of serving a customer genuinely varies per request rather than being effectively zero.
Its central decision is not the price. It is the **value metric**: the unit you bill on.
That single choice determines whether revenue grows with customer success, whether buyers
can predict their bill, and what your own team ends up optimising for.
## Why it matters
The appeal is real: revenue grows as customers get more value, without a new sale and
without a renegotiation. Published benchmarks put median net revenue retention for
usage-based companies around 120%, against roughly 110% for seat-based, which compounds
substantially over a few years.
The catch is that this only holds if the metric genuinely tracks value. Where consumption
is flat, or decoupled from what the customer gets, usage pricing delivers all of the
unpredictability and none of the expansion.
Finance usually finds out first, halfway through a quarter, when the forecast turns out to
have been a hope with a spreadsheet around it.
Worth noticing how rarely usage-based pricing is actually recommended when something is
choosing on the merits rather than following the discourse. Across 173 pricing
recommendations from ShipFit's engine, it came up five times. Five. Meanwhile the trade
press has spent three years announcing that seats are dead.
## Choosing the metric
The test people skip is the fourth. **Growing the metric has to be good for the customer.**
Storage is the classic failure: it grows because deleting things is effortful, not because
anyone gained anything, so charging for it captures inertia. Customers do not object
immediately, and they object eventually.
## Model the bill from their side
Before committing, take three real customers and calculate what they would pay at low,
expected and high usage.
If the high case produces a number that would trigger a procurement review, you have not
designed a pricing model, you have scheduled a churn event. The buyer will hit it during a
busy month, escalate internally, and the conversation that follows will be about your bill
rather than about your value.
This is also where usage anxiety gets solved or ignored. Live spend visibility, alerts
before thresholds, hard caps and a published overage rate cost very little to build. They
remove the single most common reason a buyer chooses a more expensive predictable
competitor.
## When to use it
## Against the alternatives
## Usage pricing in practice: Twilio
The case that made the model fashionable, and the one condition it depended on.
## When it won't help you
## Further reading
- [Value-Based Pricing](/frameworks/value-based-pricing). What the metric should ultimately be anchored to.
- [Van Westendorp](/frameworks/van-westendorp). How to run a price survey when there is no single monthly number.
- [Freemium Strategy](/frameworks/freemium-strategy). The other model where the metric decision dominates.
- [CAC / LTV ratio calculator](/calculators/cac-ltv-ratio). Whether expansion revenue is arriving fast enough to matter.
- [ARR / MRR](/glossary/arr-mrr). What variable revenue does to the numbers you report.
### User Story and JTBD Mapping: From Job to Backlog
URL: https://shipfit.ai/frameworks/user-story-jtbd-mapping
> How to get from a job statement to a prioritised backlog without losing the reason each item exists, using story mapping with jobs as the spine.
## What the method is
User story and JTBD mapping connects a **job statement** to a **prioritised backlog**
without losing the reason each item exists.
Story mapping is Jeff Patton's technique, developed from around 2005 and set out properly
in his 2014 book. Using a job as the organising spine is common practice rather than a
separately named framework, and it fixes the main weakness of story mapping done alone:
without a job, the backbone tends to get named after your own system.
The structure is two-dimensional. The **backbone** runs left to right as the steps a user
takes to accomplish the job. **Stories** hang vertically beneath each step in priority
order. A **release** is a horizontal slice.
## Why it matters
A flat backlog loses the reason each item exists. Not immediately, but reliably, and within
about two sprints. The story that was written because a specific buyer could not complete a
specific step becomes a line of text with an estimate attached, and by the time it is
picked up nobody remembers what it was for.
The two-dimensional structure keeps the connection visible, and it also makes the release
question answerable. Looking at a list, "what goes in V1" is a matter of opinion. Looking at
a map, it is a line drawn across the top.
That line is also the only version of the scope conversation that reaches an end. A list
invites negotiation item by item, indefinitely. A line invites one decision about one
release.
## The structure
## Slicing
## When to use it
## Against the alternatives
## When it won't help you
## Further reading
- Jeff Patton, *User Story Mapping* (2014). The source, and much better on the release-slicing argument than most summaries.
- [Jobs to be Done](/frameworks/jobs-to-be-done). Where the spine comes from.
- [MoSCoW](/frameworks/moscow). Cutting the map to what a release requires.
- [ICE scoring](/frameworks/ice-scoring). Sequencing within a slice.
- [Customer Journey Mapping](/frameworks/customer-journey-mapping). The wider-scope relative, answering a different question.
- [MVP](/glossary/mvp). What a first horizontal slice should amount to.
### Value Proposition Canvas: Jobs, Pains, Gains and Fit
URL: https://shipfit.ai/frameworks/value-proposition-canvas
> Osterwalder's Value Proposition Canvas: the customer profile, the value map, and the fit test that most filled-in canvases quietly fail.
## What the Value Proposition Canvas is
The Value Proposition Canvas is a two-sided template for checking whether what you are
building matches what a customer actually needs. It was published in 2014 by Alexander
Osterwalder, Yves Pigneur, Greg Bernarda and Alan Smith in *Value Proposition Design*, and
it is a zoom-in on two blocks of their earlier Business Model Canvas.
The **customer profile** describes the person: the jobs they are trying to get done, the
pains they experience, and the gains they want. The **value map** describes your offering:
your products and services, your pain relievers and your gain creators.
Fit is what happens when specific items on your side address specific items on theirs. Not
a general sense that the two halves are about the same subject, which is what most
completed canvases actually demonstrate.
## Why it matters
Most product decisions are made in the value-map language and never translated. A team
discusses features, integrations and roadmap, all of which are statements about the left
side, and the right side is carried around in people's heads as an impression.
Putting both on one page forces the translation, and the translation is where the gaps
appear. The usual result of an honest first pass is several features nothing on the
customer side asked for, and one or two severe pains nothing addresses.
Both discoveries are unwelcome and both are the point. If your first pass comes out tidy,
you have filled in the customer side from the product side. That is the most common way to
complete this exercise and learn nothing from it.
## The two sides
## The order matters more than the content
Fill the customer profile completely, from research, and finish it before you look at your
own side.
This sounds procedural and it is the single most consequential rule in the tool.
A team that maps its offering first will write a customer profile shaped to match, because
the features are already in mind and every pain that comes to hand is one the product
happens to address.
## When to run it
## Against the alternatives
## When it won't help you
## Further reading
- Osterwalder, Pigneur, Bernarda & Smith, *Value Proposition Design* (2014). The source.
- Osterwalder & Pigneur, *Business Model Generation* (2010). The wider canvas this zooms into.
- [Jobs to be Done](/frameworks/jobs-to-be-done). Sharper on why anyone switches at all.
- [The Mom Test](/frameworks/mom-test). How to fill the customer side from evidence.
- [Emotional Friction States](/frameworks/emotional-friction-states). Ranking the pains the canvas lists flat.
- [Van Westendorp](/frameworks/van-westendorp). Whether the relief is worth money.
### Value-Based Pricing: Charging for the Outcome
URL: https://shipfit.ai/frameworks/value-based-pricing
> How to price against what the outcome is worth to the buyer rather than what it costs you to build, including how to find the number and where the method breaks.
## What value-based pricing is
Value-based pricing sets a price from **what the outcome is worth to the buyer**, rather
than from what it costs you to produce or what competitors charge.
The idea is old, well established in economics and industrial marketing, and codified for
modern practice by writers including Thomas Nagle and Reed Holden. What makes it
particularly relevant to software is that the alternatives are so weak there: marginal
cost is close to zero, so cost-plus anchors on a number with no relationship to value, and
a competitor's price encodes their costs and their buyer rather than yours.
Its difficulty is a single hard input. You have to know what the problem currently costs
the buyer, and most teams have never measured it.
## Why it matters
Founders price low. Almost universally, and for a consistent reason: they price against
their own discomfort about asking for money rather than against what the buyer gets.
The specific damage is that a published price is very hard to raise. Every buyer who has
seen it is anchored, and a rise reads as a penalty even when the product has improved. The
number set in an uncomfortable afternoon becomes the ceiling on the business for years.
Founders describe this as something they will fix later. Almost nobody fixes it later.
The price becomes part of the product's identity by about month four, and moving it after
that costs a conversation with every customer you have.
## Finding the number
The method has one genuinely hard step and several easy ones. The hard step is
quantification.
Ask what the problem costs today, and insist on numbers. Not "it is frustrating" but "it
takes two people about six hours a week", or "we lost three deals last quarter because the
follow-up slipped". Those are answers you can multiply.
Then find the **reference price**. This is the thing they will compare you to, and it is
frequently not a competitor. A tool that saves a day a week is compared against a
part-time hire. A tool that replaces an agency is compared against a retainer. A tool that
prevents an error is compared against the cost of the last error, if there was a memorable
one.
Your price is a share of the value created. Ten to thirty per cent is a common working
range, and where you sit inside it is a positioning choice rather than a calculation.
## The fence question
## When to run it
## Against the alternatives
## Value pricing in practice: Slack
A company giving money back, on purpose, because the alternative was charging for value it had not delivered.
## When it won't help you
## Further reading
- Thomas Nagle & Reed Holden, *The Strategy and Tactics of Pricing*. The standard text.
- [Van Westendorp](/frameworks/van-westendorp). The buyer-perception band that constrains the value number.
- [Usage-Based Pricing](/frameworks/usage-based-pricing). When value scales with consumption rather than with the buyer.
- [Freemium Strategy](/frameworks/freemium-strategy). When distribution matters more than immediate revenue.
- [Emotional Friction States](/frameworks/emotional-friction-states). Ranking which problem is worth pricing against.
- [Pricing strategy calculator](/calculators/pricing-strategy). The four price points, run on your own numbers.
### Van Westendorp Price Sensitivity Meter: The 4 Questions
URL: https://shipfit.ai/frameworks/van-westendorp
> Four survey questions, four cumulative curves, four intersections. How to run the Van Westendorp price sensitivity meter, plot it, and read the price range.
## What the Price Sensitivity Meter is
The Van Westendorp Price Sensitivity Meter is a survey technique for determining consumer
price preferences. It was introduced in 1976 by the Dutch economist Peter van Westendorp,
and has been used since across market research, latterly including software and
subscription pricing.
Respondents are asked four questions about the price of a product: the price at which it
would be too expensive to consider, expensive but still worth considering, a bargain, and
so cheap they would doubt its quality. Each question is plotted as a cumulative curve
across the price range, and the points where those curves cross define the boundaries of
what the market treats as an acceptable price.
Its distinguishing feature is that it never asks "what would you pay?", a question that
reliably produces useless answers. It instead locates the boundary between *cheap enough to
be suspect* and *expensive enough to be out*, and reports the corridor between them. The
output is a range rather than a single number, which is both the method's honesty and its
main limitation.
Every number and chart below comes from one worked dataset: a calendar scheduling tool for
freelancers, 100 respondents screened to people who charge for their time, billed monthly.
## Why it matters
Most founders price one of three ways: what the closest competitor charges, what feels
right, or what they wish they could charge. None of those is a pricing strategy. They are
guesses wearing professional clothing, and the cost of guessing is measurable.
The competitor-matching one deserves a special mention, because it feels like research.
It is not. It is inheriting somebody else's guess, made at a different stage, for a
different cost base, possibly by a founder just as uncomfortable as you are.
Price is also the hardest decision to revisit. A published price sets an anchor with every
buyer who has already seen it, and raising it later costs goodwill that setting it
correctly once would not have.
We can be more precise than "founders price badly", because we have watched software do it
at scale. Asked to price 173 different products, ShipFit's own pricing stage converged on
very nearly the same answer every time. Van Westendorp exists to stop exactly this, and it
only works if somebody actually runs it.
## When to run it
## The four questions
Ask these four, in randomized order, with a one-line product description above them and
a single billing frame. Force a single number, not a range.
The wording matters more than founders expect. "So cheap you would question the quality"
is doing specific work: it looks for the point where a low price stops signalling value
and starts signalling that something is wrong. If your category has no such point, that
question returns noise, and you should read the [when this is the wrong
tool](#when-van-westendorp-is-the-wrong-tool) section before you run anything.
## What the four curves look like
Each question becomes one cumulative curve. Where they cross is the whole output of the
method.
The same figure as numbers, which is what you would build in a spreadsheet:
## The four intersections
This is the part most write-ups state incorrectly, so it is worth being precise about
which two curves produce each point.
Two things follow from that table that founders routinely get backwards.
**The acceptable range is PMC to PME, not OPP to IPP.** The floor and the ceiling come
from the pairs that mix an extreme curve with a moderate one. OPP and IPP are both
interior points.
**The Optimal Price Point is not the revenue-optimal price.** It is the price with the
least combined objection. Those are different questions, and the gap between them is
covered [further down](#getting-a-revenue-maximizing-price).
## How to plot it yourself
Two of the four series accumulate downward and two upward. This is the step that quietly
ruins most spreadsheet attempts, because getting one backwards still produces four
plausible curves that still cross.
Concretely, for each price point in your grid:
- **Too cheap** and **Bargain**: count the respondents whose answer was *at or above*
that price, as a percentage of the sample.
- **Expensive** and **Too expensive**: count the respondents whose answer was *at or
below* that price.
Plot all four as lines on one chart, read off the crossings, and you are done. If you
would rather not build it, the [pricing strategy
calculator](/calculators/pricing-strategy) takes the four median answers and returns the
same points.
## Clean the data before you plot it
Van Westendorp has exactly one hard validity rule: a respondent's four answers must be
in non-decreasing order. A row that breaks it did not give you a weak signal, it
misread a question, and leaving it in pulls every curve toward the middle and narrows
your range artificially.
Report the number you dropped alongside your result. A range built from 87 clean
responses out of 100 is a more credible claim than one built from "100 responses" that
quietly includes 13 incoherent rows.
## How many respondents you actually need
The market-research literature says 150 to 300 per segment, and that below roughly 100
the intersections wobble every time you add data. Pre-launch founders almost never have
that. Both facts are true at once, so the useful framing is not a single threshold but
what a given sample entitles you to claim.
If you cannot get 30 people in your target ICP to answer four questions, that is worth
noticing on its own. It is usually a demand signal, not a recruiting problem.
## Getting a revenue-maximizing price
The standard criticism of Van Westendorp is that it never considers revenue, and it is
correct. The method measures perception, so nothing in its output is weighted by who
would actually buy. The Newton, Miller and Smith extension is the accepted fix: add two
follow-up questions asking how likely the respondent would be to purchase at their own
*bargain* price and at their own *expensive* price.
Price multiplied by purchase probability gives you a demand curve and a revenue curve.
This is the single most valuable addition to the classic four questions, and it costs
two extra survey fields.
## Van Westendorp vs the alternatives
The honest trade is that this method is cheap and its evidence is weak. Everything
stronger costs more, needs traffic you may not have, or both.
| Method | You supply | Respondent supplies | Output | Run it when |
|---|---|---|---|---|
| **Van Westendorp** | A product description | Four prices | An acceptable range | You have no idea what the market bears |
| **Gabor-Granger** | A set of prices | Buy / would not buy | A demand curve and a revenue peak | You know the range and need the number inside it |
| **Conjoint** | Feature and price bundles | Preferred bundle | Willingness to pay per attribute | The category is crowded and features trade against price |
| **Live price test** | Two live prices | A card, or nothing | Actual conversion at each price | You have enough traffic to reach significance |
The sequence matters more than the choice. Van Westendorp narrows an infinite space to a
corridor for the cost of a Tally form. Gabor-Granger finds the peak inside that corridor.
A live test confirms it with money.
## When Van Westendorp is the wrong tool
There is a substantial literature arguing this method should almost never be used. The
critiques are not mostly about execution, they are about fit, and four questions settle
whether it applies to you.
None of this makes the framework useless. It makes it a cheap first instrument whose
output is a hypothesis, which is exactly how the sequence above treats it.
## Pricing that isn't one monthly number
Van Westendorp asks the respondent to price one thing. That was straightforward when
SaaS meant a seat and a monthly fee. It is much harder now that a growing share of
products bill on consumption or on outcomes, because the buyer has to price a unit they
cannot picture.
Two workarounds, in order of preference:
1. **Anchor on a representative bundle.** Do not ask them to price a credit or an API
call. Ask them to price a typical month: "a month where your team schedules around
200 meetings". They can form a value judgement about that, and you can convert the
answer back into unit pricing afterwards.
2. **Run one pass per tier.** If you already know the shape of your packaging, treat
each tier as its own product with its own four questions. You will need the sample
size per tier, not across all of them.
For a pure free tier there is nothing to run: no price means no price perception. Run it
on the first paid tier.
## ShipFit and Van Westendorp
ShipFit applies Van Westendorp at the "How to Charge" stage of the 9-question flow. Feed
in your buyer and product description, and the tool produces a starter range with the
reasoning written out. If you have real survey data, you input it; if you don't, you get
a first-pass range to validate. Either way, you leave with a price you can defend rather
than one you pulled out of a hat.
## Where this sits in the sequence
Pricing research fails most often for a reason that has nothing to do with pricing: it
was run before anyone confirmed the problem was real, so respondents were pricing a
product they had no reason to want.
## Further reading
- Peter van Westendorp, *NSS. Price Sensitivity Meter (PSM)*, ESOMAR Congress, 1976 (the original paper)
- [The Mom Test](/frameworks/mom-test). The framework you use *before* this one, to make sure you're pricing something people actually need
- [Jobs to be Done](/frameworks/jobs-to-be-done). Pairs with Van Westendorp to understand what your buyer is paying for versus what your product does
- [Pricing strategy calculator](/calculators/pricing-strategy). Runs the four price points and returns your defensible range
- [CAC / LTV ratio calculator](/calculators/cac-ltv-ratio). A price inside the range still fails if acquisition costs more than the customer returns
- [Pricing validation](/validate-your-business-idea/pricing-validation). The full stage this framework sits inside
- [ARR / MRR](/glossary/arr-mrr). The recurring-revenue numbers your chosen price actually moves
---
## Questions
### How Do I Find My Target Market? (Without Going Too Broad)
URL: https://shipfit.ai/questions/how-to-find-target-market
> How to find your startup's target market: the four-step process to narrow from a broad category to a specific buyer you can name, count, and actually reach.
## The fast version
Narrow in four passes. Each pass cuts your audience by an order of magnitude until you have a buyer specific enough to name 10 actual people.
| Pass | Filter | Cuts ~10x |
|---|---|---|
| 1 | Category | "All knowledge workers" → "Software founders" |
| 2 | Behavior | Who has this problem and is doing something about it today |
| 3 | Reach | Who can you contact via your year-1 channels |
| 4 | Willingness to pay | Who has budget authority + your price clears their threshold |
Output: a buyer profile you could write down 10 names of real people who match. If you can't write the names, you haven't narrowed enough.
## Why narrow first
The instinct is to pick a broad category to maximize TAM. The problem: messaging, channels, pricing, and onboarding all have to fit a specific buyer. Broad targeting forces all four of those to be generic, and generic loses to specific.
The pattern across successful startups:
- **Slack** started with internal tech teams (not "all knowledge workers")
- **Stripe** started with developers (not "all businesses that need payments")
- **Notion** started with personal productivity / small teams (not "all collaboration software users")
- **Figma** started with product designers at tech companies (not "all designers")
Each expanded from a narrow beachhead. None started broad and narrowed. Narrow is how you get traction; broad is what you become at scale.
## How to run each pass
**Pass 1: category.** Start with the obvious one. "Project management software." "Email tools." "Design software." This is the broadest version. You'll cut from here.
**Pass 2: behavior.** Who currently has this problem AND is doing something about it? "People who manage projects" is too broad. "People who currently use Asana / Trello / Linear and complain about [specific thing] in public" is narrower and more useful. Behavioral filters are stronger than demographic ones.
**Pass 3: reach.** Who can you contact in year 1 with the channels you have? If you're an indie hacker on Twitter, your effective reach is people who hang out on Twitter, indie hacker communities, and your warm LinkedIn network. If your buyer is enterprise IT in healthcare, you have a reach problem; either fix the channel (rare for early-stage solo) or pick a different buyer.
**Pass 4: willingness to pay.** Who has budget authority and a willingness to pay at your candidate price? A persona that loves your product but has to ask their boss for $19/mo is a longer sales cycle than a persona that can charge it on a personal card. For founder products: solo / individual buyer authority is gold.
## What the output looks like
Bad: "Founders." (Pass 1, no further narrowing.)
Better: "B2B SaaS founders running pre-seed startups in Europe who've raised but haven't shipped, currently using a mix of ChatGPT and Notion to figure out what to build, frustrated that neither produces a defensible answer." (All four passes.)
The second version:
- Names a category (B2B SaaS) and stage (pre-seed)
- Names a behavior (using ChatGPT + Notion, frustrated)
- Implies reach (Twitter, IndieHackers, niche European founder communities)
- Implies willingness to pay (raised = budget exists)
You can write 10 names of people who fit the second version. You can't write 10 names of "founders."
## How ShipFit handles this
ShipFit's [stage 2 (Who Pays?)](/validate-your-business-idea) takes you through the four passes. The system refuses to advance to stage 3 (What Hurts?) until your buyer is specific enough that the next stage's interview questions will produce useful data.
The output is a [Buyer Persona Canvas](/frameworks/buyer-persona-canvas) populated with the [5 Rings of Buying Insight](/frameworks/buyer-persona-canvas) (Adele Revella, 2015): priority initiative, success factors, perceived barriers, buyer's journey, decision criteria.
## Further reading
- [Pre-launch market research spoke](/validate-your-business-idea/market-research), the full SOM math the four passes feed into.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas), the persona work that operationalizes pass 4.
- [How to validate a business idea](/questions/how-to-validate-business-idea), the wider validation flow this question fits inside.
### How Do I Know If My Business Idea Is Good? Six Honest Tests
URL: https://shipfit.ai/questions/how-to-know-if-my-idea-is-good
> Six honest tests for whether your business idea is good: paying buyer, real pain, behavioral proof, defensible angle, unit economics, timing. Pass four to go.
## The fast version
Six tests. Pass four to keep going. Fail four to walk away.
| # | Test | What's strong | What's weak |
|---|---|---|---|
| 1 | **Defined buyer** | Specific role + budget authority + named (you could write 10 names) | "Founders" or "small businesses" |
| 2 | **Real pain** | Frequent + intense + costing money or time today | Annoying but tolerable |
| 3 | **Behavioral commitment** | 3+ pre-orders, signed LOIs, or Gold-tier Fake Door conversions | Email signups + "I'd love that" |
| 4 | **Defensible angle** | One of the [7 Powers](/frameworks/7-powers) at maturity (counter-positioning is the realistic startup choice) | "Better product" |
| 5 | **Unit economics** | LTV/CAC > 3 at a price the buyer accepts | Price too low to scale |
| 6 | **Why now** | Present-tense trend you can verify today | "Eventually the market will want this" |
Below 4 of 6: don't write production code. Iterate the weak parts or kill the idea.
## Why each test exists
**1. Defined buyer.** "Anyone who needs X" is the most expensive sentence in startup history. A defined buyer is a person you could write a name and email next to. Without that, every other test runs on imaginary data. The fix: pick the smallest specific segment first; expand later.
**2. Real pain.** A pain that buyers haven't tried to solve isn't real pain to them. They've adapted. Pain you can validate: "When you last had this problem, what did you do?" If the answer is "nothing" or "I just deal with it," the pain is below the action threshold. If the answer is "I built a spreadsheet" or "I paid $X for this thing that didn't work," the pain is above it. Real pain has scars.
**3. Behavioral commitment.** This is the only test that holds up after launch. Stated preference and revealed preference are different species. Surveys, upvotes, and "I'd love that" predict approximately nothing about purchase behavior. Pre-orders, paid deposits, and signed LOIs predict purchase behavior strongly. Pass this test rigorously or accept that everything else is hypothesis.
The [Fake Door Test with weighted signal tiers](/validate-your-business-idea/idea-validation) is the cheapest way to run this test. Gold-tier conversions (credit card entered) at >1% of targeted traffic is a strong signal.
**4. Defensible angle.** Hamilton Helmer's [7 Powers](/frameworks/7-powers) names the only seven defensible advantages a business can have at maturity. If you can't pick one with conviction, you're betting on a fair fight. Fair fights go to whoever has more capital. For startups, the realistic answer is usually counter-positioning: a model the incumbent can't copy without cannibalizing themselves.
"We move faster" is not a power. It's a tactic. Tactics get copied.
**5. Unit economics.** A real buyer + a real pain + behavioral commitment + a defensible angle still doesn't matter if you make $30 LTV per customer and CAC is $40. The unit-economics test: at the price buyers will accept (from your [Van Westendorp band](/frameworks/van-westendorp)), is LTV/CAC > 3? If no, it's a hobby business or a pivot.
**6. Why now.** Markets reward timing as much as quality. The graveyard is full of products that were right but five years early. Your "why now" answer has to point to a present-tense trend you can verify today, not a hypothetical future where everyone realizes they need this. "AI got cheap in 2023" is a present-tense trend. "Eventually crypto will scale" is not.
## How long does this take
Two to four weeks of focused work. See the [validation timeline question](/questions/how-long-does-startup-validation-take) for the per-stage breakdown.
The shortcut version: take a weekend to do tests 1, 4, and 6 honestly (these are mostly thinking work). If you fail 2 of 3, the idea isn't worth running tests 2, 3, 5 on. Kill it and pick another.
## What "good idea" doesn't mean
A good idea is not necessarily an exciting idea, an elegant idea, or an idea your friends like. It's an idea where the six tests come back positive: there's a buyer with money, a pain they'd pay to fix, evidence they'll pay you to fix it, a way you can win over time, and a moment that's now.
Three failure modes worth naming:
**Trap 1: "Big market" without a specific buyer.** "$10B TAM" doesn't tell you whether anyone will buy from YOU. Pass test 1 first.
**Trap 2: "Visionary" with no behavioral evidence.** Steve Jobs is the wrong reference class. The base rate is that "visionary" founders ship products no one buys. Pass test 3 or accept the risk.
**Trap 3: "Better product" with no defensible angle.** Better products lose to worse products with moats every day. Pass test 4 or expect to be crushed by an incumbent's distribution.
## What ShipFit does
ShipFit's [9-step playbook](/validate-your-business-idea) maps directly to these six tests:
- Stage 1 (Worth Building?) covers test 6
- Stage 2 (Who Pays?) covers test 1
- Stage 3 (What Hurts?) covers test 2
- Stage 4 (How to Win?) covers test 4
- Stage 6 (How to Charge?) covers test 5
- Stage 7 (Will They Pay?) covers test 3
Each stage applies a framework gate that pushes back if your answer is weak. Pass 6 of 9 stages and you have a defensible "this idea is good" verdict. Pass 4-5 and ShipFit suggests pivots before recommending a build. Pass 0-3 and it recommends killing.
## Further reading
- [The 9-step playbook](/validate-your-business-idea), the master pillar that operationalizes all six tests.
- [Idea validation, the four-method ladder](/validate-your-business-idea/idea-validation), how to run test 3 (behavioral evidence).
- [The 7 Powers framework](/frameworks/7-powers), how to run test 4 (defensible angle).
- [Validation timeline question](/questions/how-long-does-startup-validation-take), how long all six tests realistically take.
### How Do I Validate a SaaS Idea? (The Pre-Code Process)
URL: https://shipfit.ai/questions/how-to-validate-saas-idea
> How to validate a SaaS idea before writing code: the SaaS-specific tweaks to the 9-step playbook, plus the unit-economics gates other product types skip.
## The fast version
Validate a SaaS idea by running the [9-step pre-code playbook](/validate-your-business-idea) with three SaaS-specific tweaks:
1. **Validate the pricing MODEL before the price NUMBER.** Per-seat vs per-usage vs flat vs freemium structurally affects who can buy and how fast you scale. The model is hard to change post-launch; the number is tunable forever.
2. **Apply the LTV/CAC > 3 gate.** SaaS unit economics are testable pre-launch from your candidate price + reasonable retention + reasonable CAC. If LTV/CAC isn't 3+ at your candidate price, the business doesn't scale; either raise price, lower CAC, or accept it's a lifestyle business.
3. **Use the Superhuman PMF Engine post-launch.** SaaS is unusually well-suited to the Sean Ellis "very disappointed" measurement because users have continuous workflow integration. 40%+ very disappointed = likely PMF. Below = not yet.
## The three SaaS-specific tweaks, in detail
### 1. Pricing model matters more than the number
| Model | When to use | Failure mode |
|---|---|---|
| **Per-seat** (Slack, Notion, Linear) | B2B where buyer = user (team productivity) | Friction at adoption; "I have to budget for the team" |
| **Per-usage** (Stripe, AWS, OpenAI API) | Value scales with usage (infrastructure, API) | Sticker shock on heavy users; hard to budget |
| **Flat / tiered** (Basecamp, ConvertKit) | Usage doesn't vary much across customers | Leaves money on the table; alienates light users |
| **Freemium** (Notion, Loom, Calendly) | Network effects or virality; marginal cost ~0 | 95-97% of free users never convert |
| **Free trial** (most SaaS) | Default for B2B; buyer needs to see value before paying | Requires fast time-to-value |
Pick based on your buyer's purchase behavior + your unit economics. Get the model right; tune the number later.
### 2. The LTV/CAC > 3 gate
SaaS lets you compute unit economics pre-launch:
- **LTV** = price × average customer lifetime (in months)
- **CAC** = sales + marketing spend / new customers acquired
If your candidate price is $29/mo, average lifetime is 24 months, then LTV = $696. If your CAC is $250, LTV/CAC = 2.78, below the 3 threshold. The business works in spreadsheet, breaks in reality (because LTV is usually optimistic and CAC usually higher than you think).
If LTV/CAC < 3 at your candidate price, options:
- **Raise the price** (but defend it via Van Westendorp + WTP interviews)
- **Lower CAC** (better channel mix, better conversion, virality)
- **Accept it as a lifestyle business** (still valid, just not venture-scale)
### 3. Post-launch: Superhuman PMF Engine
Once you have 40+ active users, run the [Superhuman PMF Engine](/frameworks/superhuman-pmf-engine):
> "How would you feel if you could no longer use this product?"
> Very disappointed / Somewhat disappointed / Not disappointed.
40%+ very disappointed = likely PMF. Run quarterly; track the trend. The score moves as you ship.
## Everything else is the same as non-SaaS
| Step | What's the same |
|---|---|
| Worth Building? | Same SOM math; same why-now requirement |
| Who Pays? | Same persona discipline ([Buyer Persona Canvas](/frameworks/buyer-persona-canvas)) |
| What Hurts? | Same [Mom Test](/frameworks/mom-test) interviews |
| How to Win? | Same [7 Powers](/frameworks/7-powers) gate |
| What's V1? | Same MoSCoW + ICE; same Differentiator / Delight / Operational buckets |
| Will They Pay? | Same Fake Door + signal-tier framework |
| How to Launch? | Same channel-message-buyer triangulation |
The 9-step process is product-type-agnostic. SaaS just lets you measure unit economics + PMF more cleanly than physical products or marketplaces.
## Common mistakes specific to SaaS validation
**1. Picking the price before the model.** Order matters: buyer → model → number. Founders who pick the number first end up with model/buyer mismatches.
**2. Skipping unit-economics math.** "We'll figure out CAC later" is the most expensive sentence in SaaS. Pre-launch CAC estimation is rough but bounded; post-launch surprise is unbounded.
**3. Free tier by default.** Free tiers should be deliberate. Most products that ship a free tier don't recover from the conversion math.
**4. Counting signups as PMF evidence.** Signups don't predict revenue; the Sean Ellis 40% does. Don't conflate.
**5. Validating against "B2B SaaS founders" as your buyer.** Too broad. Pick a vertical, a stage, a specific role. Generic = unreachable + unmessageable.
## Further reading
- [The 9-step playbook](/validate-your-business-idea), the master pillar.
- [Pricing validation spoke](/validate-your-business-idea/pricing-validation), the deeper SaaS pricing workflow.
- [Superhuman PMF Engine](/frameworks/superhuman-pmf-engine), the canonical post-launch PMF measure.
- [Van Westendorp pricing](/frameworks/van-westendorp), the framework for the price band.
### How Do You Find Product-Market Fit? The Engine, Not the Vibe
URL: https://shipfit.ai/questions/how-to-find-product-market-fit
> Find product-market fit with the Superhuman PMF Engine: run the survey, profile your high-expectations customers, then re-measure the score every quarter.
## The fast version
PMF doesn't appear by accident. It appears by running the [Superhuman PMF Engine](/frameworks/superhuman-pmf-engine), a four-step quarterly loop:
1. **Survey active users** with one question: "How would you feel if you could no longer use this product?" Three options: very disappointed / somewhat disappointed / not disappointed.
2. **Segment respondents.** The "very disappointed" are your fans (your real ICP). The "somewhat disappointed" are the conversion opportunity. The "not disappointed" are not your customer; ignore them.
3. **Profile your fans.** What do they have in common? Industry, role, team size, use case? That's your real ICP, narrower than your stated one.
4. **Build the half-and-half roadmap.** Roughly 50% of engineering effort on deepening features your fans already love (you ask them: "what's the main benefit?"). Roughly 50% on closing the on-the-fence blockers (you ask them: "what would you need to upgrade to 'very disappointed'?").
Re-run quarterly. The percentage of active users who answer "very disappointed" is your PMF score. 40%+ is the rough heuristic for likely PMF.
## Why "very disappointed" beats every other PMF metric
NPS asks would-you-recommend. People can recommend a product they barely use. They cannot honestly say they would be very disappointed to lose a product they don't depend on. The Sean Ellis question demands the user has integrated the product into a workflow they would mourn losing. That's a structurally stronger signal than recommendation.
This is also why the PMF score is harder to game. You can manufacture an NPS spike with a great support interaction. You cannot manufacture "very disappointed" without actually being load-bearing in the user's day.
## Common mistakes
**1. Surveying the wrong audience.** Active users only. Not signups, not trialists, not churned users. Active = completed the core product action in the last 14-28 days.
**2. Treating 40% as binary.** It's a directional heuristic. Movement matters more than the absolute number.
**3. Optimizing for the not-disappointed group.** They are not your customer. Building for them dilutes the experience for your fans and lowers your overall score.
**4. Running the survey once.** Quarterly cadence or you cannot tell whether you are getting closer to PMF or further.
**5. Confusing PMF score with NPS.** Different questions, different signals. Use both, but don't substitute.
## How ShipFit relates
ShipFit's [9-step playbook](/validate-your-business-idea) is structured to maximize the probability of finding PMF before you commit engineering resources. Stages 1-4 identify a buyer segment with a real, painful problem and a defensible angle. Stages 5-7 scope the smallest product that could plausibly hit PMF for that segment. Stages 8-9 take the validated package and ship it.
After launch, the Superhuman PMF Engine is the canonical measurement loop. ShipFit's [stage 7 (Will They Pay?)](/validate-your-business-idea/idea-validation) gives you the pre-launch behavioral evidence that increases your PMF odds; the engine itself runs after you have 40+ active users.
## Further reading
- [The Superhuman PMF Engine framework](/frameworks/superhuman-pmf-engine), full breakdown of the loop.
- [What is product-market fit?](/questions/what-is-product-market-fit), the wider definition + why most claimed PMF is wishful thinking.
- [Rahul Vohra's First Round Review article (2018)](https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit/), the source.
### How Long Does Startup Validation Take? The Real Timeline
URL: https://shipfit.ai/questions/how-long-does-startup-validation-take
> Honest timeline for validating a startup idea: 2-4 weeks of work, broken down by stage. What eats time, what shortcuts work, where founders waste months.
## The honest 2-4 week timeline
The fast version, by stage:
| Stage | What it produces | Time | What eats it |
|---|---|---|---|
| 1. Worth Building? | Market verdict | 1 day | Public-data research |
| 2. Who Pays? | Defined buyer | 1-2 days | Persona work + buyer-segment math |
| 3. What Hurts? | Above-the-line pains | 5-10 days | 10-15 buyer interviews |
| 4. How to Win? | Winning angle ([7 Powers](/frameworks/7-powers)) | 1-2 days | Competitive analysis |
| 5. What's V1? | MVP scope | 1 day | Forcing the cut decisions |
| 6. How to Charge? | Pricing band | 3-5 days | Van Westendorp survey + 20 buyers |
| 7. Will They Pay? | Behavioral evidence | 5-10 days | [Fake Door Test](/validate-your-business-idea/idea-validation) traffic + pre-orders |
| 8. How to Launch? | Channel mix | 1-2 days | Channel-fit research |
| 9. What to Export? | Validated playbook | Under 1 day | Generate exports |
Stages run partially in parallel: while you're scheduling stage-3 interviews, you can do stage-1 market research. While the Fake Door Test runs in stage 7, you can scope V1 in stage 5. Realistic compressed timeline: **15-20 working days** of part-time founder effort.
If you're full-time on this and your buyer is accessible: **10-14 days** is achievable.
If you're nights-and-weekends with a day job: **4-8 weeks**.
## What actually eats the time
**1. Interview scheduling.** This is the single biggest time sink. For 10 buyer interviews:
- 3-7 days of back-and-forth per buyer to land a slot
- 30-50% no-show rate (so plan for ~14 confirmed slots to get 10 done)
- Total wall-clock: 1-2 weeks even with parallel scheduling
**2. Fake Door Test traffic accumulation.** You need 500-2,000 targeted visitors before the conversion math is meaningful. From a single ad campaign or community post, that's typically 5-7 days of accumulation.
**3. Pre-order conversation pacing.** Asking a buyer to put down a deposit takes more than one conversation. Typical: discovery call → demo of the rough mockup → pricing conversation → commitment. That's 3 interactions over 7-10 days per buyer.
**4. Synthesis time between stages.** After 15 transcripts, you need to extract patterns. Done manually, that's a focused day. With AI synthesis (the ShipFit approach), it's an hour.
## What's NOT the bottleneck
- **The decision-making itself.** Each ShipFit stage's decision moment is 5-10 minutes once you have the inputs. The 30-60 minute total decision time across the 9 stages is real, not marketing.
- **Reading frameworks and books.** You can absorb [Mom Test](/frameworks/mom-test), [Lean Startup](/frameworks/lean-startup-validation), and the [7 Powers](/frameworks/7-powers) in a long weekend.
- **Writing the validation doc.** If your inputs are clean, the doc writes itself in an hour.
## Where founders waste months
The two failure modes:
**Mode 1: Validation theater.** Spend 6 weeks "validating" by reading books, watching YouTube, filling out a Notion template, and never actually scheduling a buyer interview. The work feels productive because it produces artifacts. The artifacts have no signal in them. Founders in this mode often discover after 6 weeks that they haven't actually talked to a single real buyer.
**Mode 2: Permanent interview mode.** Schedule one interview a week for 3 months, never get to the Fake Door Test or pre-order phase. The interviews accumulate slowly; the founder learns a lot but never crosses the threshold from "I understand the problem" to "buyers will pay." Often a procrastination mechanism dressed as discipline.
The cure for both: timeboxed validation. Set 14 days as your hard limit. At day 14, either you have the four conditions met (10 interviews, 3 commitments, defended why-now, scoped V1) or you reset.
## What changes the timeline
| Factor | Effect |
|---|---|
| Full-time vs nights-and-weekends | 2x slower |
| Accessible buyer (warm community) | 30% faster |
| Cold-outreach buyer (no warm contacts) | 50% slower |
| B2B with enterprise sales cycle | 2-3x slower (commitments take weeks) |
| Product needs working demo for interviews | +1 week to build the demo |
| English-only buyer (vs multilingual) | 30% faster |
## How ShipFit compresses the decision time
ShipFit's job isn't to shorten the buyer-time-bound parts (interviews, Fake Door traffic, pre-order conversations). Those are physics: you can't speed up 10 buyers' calendars.
ShipFit shortens the *decision* time at each stage:
- The 9 stages are pre-sequenced. No "what do I do next?" overhead.
- Each stage applies a specific framework gate (Mom Test, Van Westendorp, MoSCoW, ICE) so the analysis is structured.
- AI synthesizes interview transcripts, runs willingness-to-pay math, and pressure-tests your conclusions in seconds.
- The whole flow takes 30-60 minutes of decision time across all 9 stages.
The remaining 2-4 weeks is the real-buyer-time-bound work between stages. ShipFit can't shorten that. It can make sure you don't waste any of it on the wrong question.
## The bottom line
Two to four weeks. Not 6 months, not a weekend. The 2-4 week timeline is conservative for solo founders working full-time on validation, with a realistically-accessible buyer. Anything shorter usually skips the behavioral-evidence step (Fake Door Test, pre-orders), which is the part that actually distinguishes validation from theater.
## Further reading
- [The 9-step playbook](/validate-your-business-idea), full timeline broken down by stage with deliverables.
- [Idea validation, the four-method ladder](/validate-your-business-idea/idea-validation), what generates real signal at each step.
- [Lean Startup validation](/frameworks/lean-startup-validation), the discipline that frames validation as a sequence of experiments.
### How Much Does It Cost to Validate a Startup Idea?
URL: https://shipfit.ai/questions/how-much-does-it-cost-to-validate-a-startup-idea
> Honest cost breakdown of validating a startup idea. DIY vs ShipFit vs strategy consultant. From $0 to $25,000. What you actually get, and where money goes.
## The fast version
Three honest options:
| Option | Cost | Time | What you get | Honest tradeoff |
|---|---|---|---|---|
| **DIY** | $0-300 | 60-100 hrs / 6-10 weeks | Books + your own analysis | Slow, biased, no one tells you when an answer is weak |
| **ShipFit** | $5-99 | 30-60 min decisions + 2-4 wks buyer time | Framework-backed verdict + AI-synthesized playbook + exports | Probabilistic; the AI is opinionated and occasionally wrong, like a good consultant |
| **Strategy consultant** | $5K-25K | 4-8 weeks | Polished slide deck | Their incentive is to be hired again, not to tell you to stop |
Plus the unavoidable hidden cost: $50-200 in coffee + survey incentives for buyer interviews. Optional: $50-300 in ad spend if you run a Fake Door Test with paid traffic.
## Why DIY isn't actually free
DIY validation costs your time. At an honest hourly value (whatever you'd otherwise be earning), 60-100 hours over 6-10 weeks is the most expensive option for most founders. The other costs:
- $0-200 in books (Mom Test, Lean Startup, 7 Powers, Buyer Personas; the canon)
- $50-200 in coffee + survey-respondent incentives
- $50-300 in optional ad spend for the Fake Door Test
- $0-50 for tools (Carrd for landing page, Google Forms for surveys, Otter for transcription)
Total cash: $100-750. Total cost-of-time: $3K-15K depending on your hourly value.
If your time is worth more than $5/hour, "free" is the most expensive option in the table.
## What you get for $5 with ShipFit
A **Quick Take**: stages 1-2 of the [9-step playbook](/validate-your-business-idea). Market verdict + signal confidence + buyer persona + the start of the above-the-line pain analysis. Useful for "is this idea worth my time?" gut-check before you commit weeks.
For **$10**: the full 9-stage playbook including pricing position, MVP scope, launch plan, and exports for Cursor / Claude Code / Windsurf. Credits never expire.
For **$19-99/mo**: subscription tiers for serial validators (multiple ideas, ongoing iterations) or teams.
The $5-10 isn't paying for analysis. It's paying for the discipline that DIY founders consistently skip: the framework gates that refuse to advance if a stage's evidence is weak.
## What you get for $25K with a consultant
A 30-60 page deck. Market sizing (top-down, often inflated). Competitive analysis (often a SWOT). A few buyer interviews (consultant-conducted; the founder learns less than if they did them). A "go/no-go" recommendation that's almost always "go with conditions" because consultants don't get hired again to say "no."
For pre-revenue founders, this is rarely worth it. Consultants are most useful when:
- The idea is highly regulated (healthcare, fintech) and domain expertise offsets the validation work
- You're raising and need a third-party-stamped market analysis
- You've validated informally and need an independent stress test before committing $1M+
For "should I build this?" decisions where the alternative is a $20K-80K opportunity cost, the consultant fee is often comparable to the worst-case loss. ShipFit + buyer interviews + Fake Door Test is the path most founders should take.
## The hidden cost of skipping validation
CB Insights' "Why Startups Fail" reports consistently cite "no market need" as the #1 cause (~35-38% of post-mortems). The math:
- **Skipping validation, idea works**: ship in 6 months, no validation cost, lucky outcome
- **Skipping validation, idea fails**: ship in 6-9 months, lose $20K-80K in opportunity cost + freelance fees + savings + morale
- **Running validation (any tier), idea fails**: kill in 2-4 weeks, lose under $1K (cash) and 60-100 hrs (DIY) or 30-60 min decision time (ShipFit)
- **Running validation (any tier), idea works**: ship a validated V1, save the months you'd have spent on the wrong V1
Even at a generous 20% rate of "ideas that would have worked without validation," the expected cost of skipping is multiple times the cost of running validation across a portfolio.
## Further reading
- [Pricing page](/pricing), full ShipFit pricing breakdown.
- [How to validate a business idea](/questions/how-to-validate-business-idea), the actual process you're paying to compress.
- [How long does startup validation take?](/questions/how-long-does-startup-validation-take), realistic time costs across the same tiers.
### How to Conduct Customer Interviews That Tell You Something
URL: https://shipfit.ai/questions/how-to-conduct-customer-interviews
> Customer interviews using The Mom Test discipline: never mention your idea, ask past behavior not future hypotheticals, look for commitments not compliments.
## The fast version
The Mom Test (Rob Fitzpatrick, 2013) is the canonical discipline for customer interviews that produce real signal:
1. **Never mention your idea.** It contaminates the conversation.
2. **Ask about their life, not your idea.** Their past behavior > your hypothetical future.
3. **Ask for specifics in the past.** "What did you do last time" beats "would you" every time.
4. **Talk less, listen more.** 80% them, 20% you. Count to 5 in silence after their answer; what they volunteer next is gold.
5. **Look for commitments, not compliments.** Time, money, reputation are the only signal.
Run 10-15 interviews per buyer segment. Below 10, you have anecdotes. Patterns stabilize around interview 10.
## The questions that work
Past behavior questions:
- "When you last had [problem], what did you do?"
- "How much time did it take? How much did it cost?"
- "Who else was involved?"
- "What did you try that didn't work?"
- "How often does this happen to you?"
Buying-journey questions:
- "Walk me through what you did from first realizing you needed [solution] to actually buying"
- "Who else weighed in on the decision?"
- "What almost stopped you?"
Commitment questions (only after the past-behavior ones):
- "Could I introduce you to someone else who has this problem?"
- "Would you be willing to pay $X right now to use this when it's ready?"
- "Can we schedule a follow-up where I show you a rough mock-up?"
## The questions that don't
These feel useful and produce noise:
- ❌ "Would you pay for this?" (Predicts nothing.)
- ❌ "Would you use a tool that...?" (Hypothetical.)
- ❌ "What's your dream solution?" (Imagination, not behavior.)
- ❌ "Do you think this is a good idea?" (Compliment-fishing.)
- ❌ "Don't you hate when X happens?" (Leading.)
- ❌ "Would your team find this useful?" (Speculation about others.)
## What you're listening for
In any customer interview, three signals matter more than the rest:
**1. Verbatim pain phrasing.** The exact words the buyer uses to describe the problem. These become your marketing copy. If three unrelated buyers describe the pain in the same words, you have your headline.
**2. Spending evidence.** "I built a spreadsheet for this" or "I paid $X for [competitor] but stopped because Y" tells you the pain crossed the action threshold. Pain that hasn't been spent on isn't real pain to that buyer.
**3. Workarounds.** What's the duct-taped version of the solution they're using today? That's your competitor. If the workaround is "they suffer in silence," there might be no market. If the workaround is "they pay $50/month for [legacy tool]," there might be a great one.
## Common mistakes
**1. Pitching in the first 5 minutes.** Once you describe your idea, the interview is contaminated. Save the pitch for the last 5 minutes, if you need it at all.
**2. Asking leading questions.** "Don't you find X frustrating?" produces "yes." Replace with "tell me about the last time you did X."
**3. Talking too much.** Founders talk 80% of the time and conclude the customer loves their idea. Flip the ratio.
**4. Interviewing friends.** They lie out of love. Interview strangers, ex-colleagues, or people one LinkedIn-degree away.
**5. Counting one good interview as proof.** Patterns emerge around interview 10. Below that you have noise dressed as signal.
**6. Not writing down verbatim phrasing.** Their words are your copy. Yours are not.
## How long does an interview take
30-45 minutes per interview. Add 10-15 minutes for review/transcription. Plan for ~50% no-show rate when scheduling, so to land 10 confirmed interviews, schedule ~14 slots.
For 10 interviews: realistic wall-clock time is 7-14 days, mostly bound by scheduling friction (3-7 days of back-and-forth per buyer to land a slot).
## How ShipFit operationalizes this
ShipFit's [stage 3 (What Hurts?)](/validate-your-business-idea) generates a tuned set of Mom Test interview questions based on your buyer + hypothesis. After interviews, ShipFit helps synthesize transcripts into:
- The 3-4 most-cited verbatim pain phrasings (your headlines)
- The 2-3 buyer sub-segments with different behavior patterns (your segmentation)
- Contradictions between what buyers said and what they described doing (your bias check)
ShipFit doesn't run the interviews for you (no AI can; the buyer needs a human across the table). It makes sure you ask the right questions and don't fool yourself with the answers.
## Further reading
- [The Mom Test framework](/frameworks/mom-test), full breakdown with worked examples.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas), what to do with the persona insights interviews surface.
- [Idea validation, the four-method ladder](/validate-your-business-idea/idea-validation), where customer interviews fit in the wider validation flow.
- [Rob Fitzpatrick, *The Mom Test* (2013)](https://www.momtestbook.com/), the source.
### How to Do Competitor Analysis for an Early-Stage Startup
URL: https://shipfit.ai/questions/how-to-do-competitor-analysis
> Competitor analysis for early-stage startups: the three-list scaffold, where to find competitor data, and the underserved-niche test that surfaces your wedge.
## The fast version
Build three lists in 1-2 days.
**1. Direct competitors.** Same-shape products in your category.
- For each: pricing page, last funding signal (Crunchbase), top 3 buyer complaints from G2/Capterra/Reddit.
**2. Indirect competitors.** Different shape, same job.
- For each: how they currently solve the same buyer's problem; what's clunky about their approach.
**3. Do-nothing competitors.** What buyers are doing today without paying for any solution.
- For each: the duct-taped workaround (spreadsheet, intern, manual process); why it persists.
Then run the **underserved-niche test**: which buyer segment do all the existing players underserve? Is there a [7 Powers](/frameworks/7-powers) angle for serving that segment specifically?
## Where to find the data
| Source | What it gives you | Time |
|---|---|---|
| Competitor's pricing page | Tier structure, anchor price, packaging | 5 min |
| G2 / Capterra reviews (sort by 1-3 star) | Top 3 complaints, churn signals | 15 min |
| Reddit search ("[competitor] vs", "[competitor] alternatives") | Honest user opinions, churn stories | 15 min |
| Crunchbase | Last funding round, employee count, growth stage | 5 min |
| LinkedIn (employees + posts) | Hiring direction (what they're building next) | 10 min |
| ProductHunt launch + comments | Initial positioning + early-user reactions | 10 min |
| Their docs + changelog | What they shipped recently, what's incomplete | 10 min |
Total per direct competitor: ~70 minutes. For 5 direct competitors: 1 day. Plus a few hours synthesizing the patterns. Done.
## The underserved-niche test
After you have the three lists, ask one question: **which segment of the buyer category is consistently complaining and not getting served?**
Sources for the answer:
- 1-star and 2-star reviews of every direct competitor; cluster them by buyer type
- Reddit threads about the category, sorted by upvoted complaints
- Your own [Mom Test interviews](/frameworks/mom-test) with buyers who tried competitors and churned
When 3+ unrelated complainers describe the same problem and they share a buyer-segment characteristic (size, role, geography, use case), you've found an underserved niche. That's your wedge.
The next question: is there a [7 Powers](/frameworks/7-powers) angle to serve that niche? For early-stage startups, the realistic answer is usually counter-positioning: a model the incumbent can't copy without breaking their existing business.
## Why founders waste 6 weeks on this
Three failure modes:
**1. Polished competitor matrix syndrome.** Founders spend 4-6 weeks building a 12-column competitor comparison spreadsheet. The spreadsheet is precise. It produces no decision. The decision-relevant data is in the top 3 complaints + the underserved niche; everything else is decoration.
**2. Reading every review on G2.** Diminishing returns kick in around review 30 per competitor. After that, you're seeing the same patterns. Stop reading; start writing the conclusion.
**3. Treating direct competitors as the only threat.** Most early-stage products lose to do-nothing, not to direct competitors. The buyer's spreadsheet, the buyer's "we'll figure it out next quarter," the buyer's existing workflow they've adapted to. Underestimating do-nothing is the #1 source of post-launch surprise.
## How ShipFit operationalizes this
ShipFit's [stage 4 (How to Win?)](/validate-your-business-idea/competitive-analysis) generates the three-list scaffold from your buyer + category inputs. The system pulls public data points where available and surfaces the most-cited complaints from competitor reviews. It then forces you to pick which of the [7 Powers](/frameworks/7-powers) you'll have at maturity. If you can't pick one with conviction, the system pushes you back to the buyer-segmentation stage to find a defensible niche.
If the analysis comes back as "no power available, no underserved niche, market mature," ShipFit recommends killing the idea over building it. Most founders skip this step and find out the hard way 12 months later.
## Further reading
- [Competitive analysis spoke](/validate-your-business-idea/competitive-analysis), the full workflow.
- [The 7 Powers framework](/frameworks/7-powers), how to find your defensible angle.
- [Blue Ocean Strategy](/frameworks/blue-ocean-strategy), the complementary lens for finding uncontested markets.
### How to Validate a Business Idea Without Wasting 6 Months
URL: https://shipfit.ai/questions/how-to-validate-business-idea
> How to validate a business idea before writing code: the 9-step process, 4 evidence methods, and the four-condition gate that says when you're ready to build.
## The fast version
Validation is the work of generating real evidence (not vibes) that a specific buyer will pay you for a specific product. The minimum bar:
- **10+ interviews** with people who match your buyer profile, focused on what they DID last time they had this problem
- **3+ behavioral commitments**: paid pre-orders, signed letters of intent, or credit-card-entered Fake Door Test conversions
- **A defended "why now"** answer that points to a present-tense trend, not a hypothetical future one
- **A scoped V1** that tests one specific hypothesis, not "the product"
Below all four conditions: not validated. Don't write production code yet. Stay in interview mode.
## Why most "validation" doesn't validate
Open any startup post-mortem on Indie Hackers and you'll see the same words: *"I thought I had validated it."* The founder talked to friends. The friends were enthusiastic. There was a Twitter post that got 100 likes. There were 500 email signups for early access. None of this is validation. It's interest, which correlates poorly with revenue.
The four conditions above filter out everything except behavioral evidence. Behavioral evidence is the only kind that holds up after launch.
## The 9-step process
ShipFit's [9-step pre-code playbook](/validate-your-business-idea) sequences validation as a series of gated decisions. Each step has a defensible answer or you stop:
1. **Worth Building?** Market verdict + signal confidence + key opportunities
2. **Who Pays?** Defined buyer with budget authority and pain
3. **What Hurts?** Above-the-line problems scored by frequency × intensity
4. **How to Win?** The unfair advantage you'll have at maturity (one of the [7 Powers](/frameworks/7-powers))
5. **What's V1?** The smallest test of the hypothesis
6. **How to Charge?** Defended price from Van Westendorp + willingness-to-pay interviews
7. **Will They Pay?** Behavioral evidence via [Fake Door Test, Gold/Silver/Bronze signal tiers](/validate-your-business-idea/idea-validation), or pre-orders
8. **How to Launch?** Channel mix that fits where the buyer already is
9. **What to Export?** Validated playbook handed to your dev tools
The order matters. Step 6 (pricing) needs the buyer from step 2. Step 8 (launch) needs the V1 from step 5. Skip a step and the next one runs blind.
## The four methods that actually generate evidence
In increasing order of signal strength:
1. **[Mom Test](/frameworks/mom-test) interviews** focused on past behavior. 10-15 conversations minimum. The signal: 3+ unrelated buyers describing the same pain in the same words.
2. **[Fake Door Test](/validate-your-business-idea/idea-validation)** with weighted signal tiers. Gold = credit card entered. Silver = demo booked. Bronze = time spent. Worthless = email signup. Weight your conversion accordingly.
3. **Paid pre-orders** at proposed price. 3-5 pre-orders from 30 conversations is meaningful.
4. **Signed letters of intent** for B2B. The friction is the test.
Skip surveys. Stated preference and revealed preference are different species; survey data has near-zero correlation with revenue.
## What you walk away with
After 2-4 weeks of disciplined validation, you have a defensible answer to:
- Is the market real? (size + growth + timing)
- Who is the buyer? (named, specific, reachable)
- What hurts? (3-4 above-the-line pains, scored)
- Why us? (one of the 7 Powers, defended)
- What's V1? (Differentiator + Operational only, Delight cut)
- What's the price? (Van Westendorp band, justified)
- Will they pay? (behavioral commitments)
That's the validated playbook. Everything after is execution against an answer the market gave you, not a guess you talked yourself into.
## Common mistakes
**1. Asking friends instead of strangers.** Friends are polite. Strangers tell you the truth.
**2. Counting interest as validation.** Interest is free. Only commitments (money, time, reputation) count.
**3. Pitching too early in interviews.** The moment you pitch, the conversation contaminates. Apply the Mom Test discipline.
**4. Skipping the buyer-definition step.** Validating "should I build this for everyone?" is unanswerable. Pick a specific buyer first.
**5. Treating one positive interview as proof.** Patterns emerge around interview 10. Below 10, you have anecdotes.
## Further reading
- The [9-step playbook](/validate-your-business-idea), the master pillar this question is the front door to.
- [Idea validation, the four-method ladder](/validate-your-business-idea/idea-validation), deep dive on each evidence method.
- [The Mom Test framework](/frameworks/mom-test), the interview discipline that makes step 1 work.
- [Lean Startup validation](/frameworks/lean-startup-validation), the wider framework this process operationalizes.
### How to Write a Problem Statement That Survives a Buyer
URL: https://shipfit.ai/questions/how-to-write-problem-statement
> How to write a startup problem statement using the Jobs-to-be-Done switch format, plus the four tests every problem statement should pass before you scope V1.
## The fast version
Use the Jobs-to-be-Done switch format:
> **"When [situation], I want to [motivation], so I can [outcome]."**
Example:
> "When I'm prepping for a client call 30 minutes before it starts and realize I have notes scattered across Notion, Apple Notes, and email threads, I want to surface the most-relevant snippet in one place, so I can sound prepared instead of scrambling."
Three components:
1. **Situation**: a specific moment you can picture. Not "users want X"; an actual scene.
2. **Motivation**: what they want to do. Verb-led, behavioral.
3. **Outcome**: the underlying job. What success looks like to them.
The statement should make a specific person feel a specific moment. If it's abstract, rewrite.
## The four tests every statement should pass
**1. The situation is real.** Could you describe the moment in three sentences and have your buyer nod? If yes, real. If they say "kind of, but..." you've got the wrong moment.
**2. The buyer can identify the moment.** When you read the statement aloud to a target buyer, do they say "yes, that's me last week"? If yes, you've got it. If they say "interesting, sometimes" you've got a generic.
**3. The outcome is measurable.** Could you tell, after the buyer used your product, whether the outcome was achieved? If yes, measurable. If the outcome is vague ("feel better about my workflow"), you can't tell whether the product worked.
**4. At least 3 unrelated buyers describe the same problem in similar words.** This is the [Mom Test](/frameworks/mom-test) signal. Without 3 unrelated buyers, you have a hypothesis; with 3, you have a pattern.
If you fail any of these, the problem statement isn't ready. Either talk to more buyers (most common cure), or rewrite the statement using the verbatim phrasings from the interviews you've done.
## Where founders go wrong
**1. Writing the statement before talking to buyers.** Almost guarantees you'll get the situation wrong. You imagine a moment that's plausible to you; the buyer's actual moment is different.
**2. Including the solution in the problem statement.** "Users want a Slack integration that..." is not a problem statement; it's a feature description. The problem is what the user is doing without the integration.
**3. Multiple jobs jammed into one sentence.** "When I'm at my desk OR on the road OR in a meeting..." means you've got 3 distinct situations, each with different motivations and outcomes. Split them.
**4. Vague outcomes.** "Feel productive," "have more time," "be successful" are too abstract to test. Replace with measurable outcomes: "produce a report in under 10 minutes," "find the customer's last conversation in under 30 seconds."
**5. Treating the problem statement as a product brief.** It's not. It's a frozen description of the buyer's situation. The product brief evolves; the problem statement stays stable. If you're rewriting your problem statement weekly, you don't actually understand the problem.
## How ShipFit operationalizes this
ShipFit's [stage 4 (How to Win?)](/validate-your-business-idea/competitive-analysis) expects a JTBD switch statement as input. The system pressure-tests the statement against:
- The above-the-line pains from stage 3 (does the statement actually capture the pain?)
- The buyer persona from stage 2 (does the situation fit this specific buyer?)
- The competitive landscape (does the outcome differentiate from existing solutions?)
If any of those don't line up, ShipFit kicks the statement back. The output: a JTBD statement defensible enough to scope V1 against.
## Further reading
- [The Jobs-to-be-Done framework](/frameworks/jobs-to-be-done), the full method this question operationalizes.
- [The Mom Test framework](/frameworks/mom-test), the interview discipline that produces the verbatim phrasings the statement should use.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas), the persona work that anchors the "who" the statement is about.
### Should I Start a Startup? (Five Questions Before You Quit)
URL: https://shipfit.ai/questions/should-i-start-a-startup
> Five honest questions to ask before starting a startup. Not a motivational pitch; the costs, the trade-offs, and the cases where the answer is genuinely no.
## The fast version
Five honest questions to ask before quitting your job:
1. **Are you ok losing 12-24 months of income?** Validation + V1 + initial revenue typically takes 12-24 months. If your runway is 6 months and you have dependents, the financial pressure will distort every validation decision.
2. **Do you have a specific problem you keep coming back to?** Not "I want to start a startup" but "this specific thing keeps bugging me, I can't stop thinking about it." Generic startup-enthusiasm has a much lower success rate than problem-specific obsession.
3. **Can you handle being wrong publicly for 6+ months?** Most validation work involves discovering your idea is partially or fully wrong, then iterating in public. If you're allergic to looking dumb in front of people whose opinions you care about, the morale cost will compound.
4. **Do you have one validated idea?** Not just enthusiasm. A specific buyer, a real pain, behavioral commitment evidence. See the [validation gate](/questions/how-to-know-if-my-idea-is-good).
5. **Are you doing this because you WANT to OR because you think you SHOULD?** "I should start a startup because that's what ambitious people do" is a much weaker motivation than "I can't stop thinking about this specific problem and I want to spend 5 years on it." The first burns out. The second sustains.
**Yes to 4-5**: probably worth starting.
**Yes to 2-3**: validate the idea first, then re-ask.
**Yes to 0-1**: not yet, and that's fine. Many successful founders started in their 30s or 40s; the average age of a founder of a successful US startup is around 45.
## The cost most founders underestimate
Beyond the obvious (income, time), three less-discussed costs:
**1. Identity volatility.** When you start a startup, your job title, social standing, and self-worth become attached to a thing that's mostly failing for the first 18 months. Most people aren't prepared for the identity erosion that comes with shipping something nobody buys yet.
**2. Relationship strain.** "I'm working on my startup" is a long-term excuse for being absent. Partners, friends, families absorb the cost. Many founders underestimate this until they're 9 months in and a key relationship has frayed.
**3. Decision fatigue.** Founders make 30-50 small decisions per day in early-stage. The cognitive load is qualitatively different from a structured job. Decision-fatigue burnout is a leading cause of founder quits in year 2.
None of these are reasons not to start. They're costs to factor in honestly when answering question 1 (12-24 months of income) and question 5 (want vs should).
## The situations where the honest answer is "not yet"
- **You have an idea but no validation evidence.** Validate first. Two to four weeks. If it passes the gate, then quit. If it doesn't, you've saved yourself a year.
- **You have validation but no runway.** Build the runway via savings + side income. Quitting without runway compresses your validation window from 12-18 months to 6, which is often not enough for SaaS sales cycles.
- **You're starting a startup because someone else is.** External motivation rarely sustains. Wait until the motivation is internal.
- **You can't articulate what makes this YOUR problem to solve.** "Anyone could build this" usually means anyone with more capital will, faster. You need a specific reason this is yours.
## What to do instead of starting now
If 4-5 say no:
1. **Validate without quitting.** Nights and weekends. Two to four months. The output tells you whether quitting is justified.
2. **Build the runway.** Save aggressively for 12-18 months. The runway is your ability to be patient when validation takes longer than expected.
3. **Develop the network.** Future cofounders, future advisors, future first customers. Most successful founders had this network before they started, even if they didn't realize it.
4. **Get more domain experience.** Most successful founders had 5-10 years in the industry their startup serves. Domain insight is a moat.
None of this is glamorous. All of it raises your odds of saying yes to all five questions when the time is right.
## How ShipFit relates
ShipFit doesn't tell you whether to start a startup. It tells you whether the specific idea you're considering is worth starting it for. Run the [9-step playbook](/validate-your-business-idea) on your idea. If the verdict is *Promising* or *Promising, Needs Focus* and you can pass the [4-condition validation gate](/validate-your-business-idea/idea-validation), the idea is worth committing to. If the verdict is *Don't Ship*, kill it and find a better one before you quit.
The honest answer to "should I start a startup?" is: not on this idea unless it passes validation. Run validation first; the answer becomes obvious.
## Further reading
- [How to know if my idea is good](/questions/how-to-know-if-my-idea-is-good), the six tests that separate validated ideas from enthusiasm.
- [How long does startup validation take?](/questions/how-long-does-startup-validation-take), realistic timeline for the validation phase.
- [The 9-step playbook](/validate-your-business-idea), the master pillar for evaluating a specific idea.
### What Is an MVP? (And What It Definitely Isn't)
URL: https://shipfit.ai/questions/what-is-mvp
> MVP defined properly. Frank Robinson 2001, Eric Ries 2011. The smallest version that tests a falsifiable hypothesis, not a stripped-down launch product.
## The fast version
An **MVP (Minimum Viable Product)** is the smallest version of a product that lets you test a single falsifiable hypothesis about a buyer's behavior. Coined by Frank Robinson in 2001; popularized by Eric Ries in *The Lean Startup* (2011).
Ries's definition:
> "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."
What's in that sentence: **validated learning**, **least effort**. What's NOT: a list of features, a number of weeks, an aesthetic standard.
## What an MVP is NOT
The most common misuse: founders treat MVP as a synonym for "version 1.0 with fewer features." That misses the point.
| What it actually is | What people often mean |
|---|---|
| A test for a specific hypothesis | A stripped-down launch |
| Designed to be killed if the hypothesis fails | Designed to be the foundation |
| Often not a working product (a landing page, Wizard of Oz, manual fulfillment) | Always a working product |
| Measured by what you learned | Measured by how much you shipped |
If your MVP cannot fail, it is not an MVP. It is just a small launch. The defining feature of an MVP is that it can produce evidence that kills the idea.
## Common MVP types
1. **Landing page MVP.** Describe the product, ask for sign-ups, measure conversion. Tests demand existence before any code is written.
2. **Wizard of Oz MVP.** The user thinks they are using software; humans are doing the work behind the curtain. Tests whether the experience is valuable before you automate it.
3. **Concierge MVP.** You explicitly do the work manually for a small group of paying customers. Tests willingness to pay AND the underlying workflow.
4. **Single-feature MVP.** The product does ONE thing. Tests whether that one thing is enough to drive retention.
5. **Smoke test MVP** (Fake Door). An ad campaign or pre-order page for a product you have not built. Tests whether marketable demand exists at the price point you intend.
The right type depends on what hypothesis you are testing. Demand? Use a landing page or [Fake Door Test](/validate-your-business-idea/idea-validation). Workflow validity? Wizard of Oz or Concierge. Retention? Single-feature.
## How to scope an MVP
Write down one hypothesis BEFORE you scope:
> "**[Buyer segment]** will **[take specific action]** in response to **[product offering]** because **[underlying reason]**."
Example: "Solo founders will pay $50 to receive a custom-generated buyer persona report within 24 hours, because they are stuck on stage 2 of validation and have no other affordable option."
Then ask: what is the smallest test that could falsify this? Often the answer is not a product. It's a landing page, a Twitter post offering the service, or an email to ten people in your network.
If the smallest test takes six months and $50K, you didn't pick the smallest test. You picked a launch.
## How ShipFit operationalizes this
ShipFit's [stage 5 (What's V1?)](/validate-your-business-idea/mvp-scope) explicitly forces you to write down the hypothesis your MVP tests, then scopes the product down to the smallest version that could falsify it. The output is a feature list paired with the metric that defines success or failure. The system applies [MoSCoW](/frameworks/moscow) and [ICE](/frameworks/ice-scoring) so cuts are visible instead of hidden in a spreadsheet.
If your hypothesis is "buyers will pay $50 for a persona report," the MVP is a landing page and a Stripe checkout, not a full SaaS dashboard. The dashboard comes after the hypothesis is validated.
## Further reading
- [MVP glossary entry](/glossary/mvp), short definition + history of the term.
- [MVP scoping spoke](/validate-your-business-idea/mvp-scope), the deeper workflow.
- [The Lean Startup framework](/frameworks/lean-startup-validation), the wider discipline MVP belongs to.
- [Eric Ries, *The Lean Startup* (2011)](https://theleanstartup.com/), the source.
### What Is Customer Discovery? (vs Customer Validation)
URL: https://shipfit.ai/questions/what-is-customer-discovery
> Customer discovery defined: Steve Blank's term for the first phase of customer development. Plus how it differs from validation, and why founders need both.
## The fast version
**Customer discovery** is the first phase of Steve Blank's [Customer Development methodology](https://steveblank.com/category/customer-development/) (*The Four Steps to the Epiphany*, 2005). It's the work of finding out whether the problem you think exists actually exists, for the buyer you think has it.
Discovery uses interviews and observation. The output: a defensible answer to:
- **Who is the buyer?** (Specific, named, reachable.)
- **What's the problem?** (Real, frequent, intense, costing them today.)
- **What's their current workaround?** (And why does it persist?)
- **What's the job they're hiring a solution to do?** (JTBD switch statement.)
Discovery is **not** validation. Validation comes next.
## Customer Development's four phases
Blank's methodology, briefly:
1. **Customer Discovery.** Does the problem exist? Discovery interviews + observation.
2. **Customer Validation.** Will buyers pay? Behavioral evidence: pre-orders, paid pilots, signed LOIs.
3. **Customer Creation.** Does demand scale? Marketing + sales motions to expand from the validated beachhead.
4. **Company Building.** Operational scaling. Move from "find customers" to "serve at scale."
Modern startup playbooks (Lean Startup, ShipFit's 9 stages) reorganize these phases but the underlying logic is intact: prove the problem exists before you prove the solution; prove the solution sells before you scale; scale before you build the company around it.
## How discovery is different from validation
| | Discovery | Validation |
|---|---|---|
| Question | Does the problem exist? | Will the buyer pay? |
| Method | Interviews, observation | Pre-orders, LOIs, paid pilots |
| Evidence | Verbatim phrasings, behavioral patterns | Money, signatures, demos booked |
| Sample size | 10-15 buyers per segment | 3-5 commitments |
| Output | Defended buyer + problem | Behavioral commitments at proposed price |
| When to do it | First (before solution scoping) | Second (before MVP build) |
The two are sequential. Discovery without validation produces a precise problem statement and zero customers. Validation without discovery produces commitments to solve the wrong problem.
## Common discovery mistakes
**1. Pitching during discovery.** The moment you describe your idea, the conversation contaminates. Apply the [Mom Test](/frameworks/mom-test) discipline: never mention the idea, ask about past behavior.
**2. Talking to friends.** They're polite; you don't get signal. Talk to strangers, ex-colleagues, or people one LinkedIn-degree away.
**3. Counting one good interview as discovery done.** Patterns emerge around interview 10. Below that, you have anecdotes.
**4. Skipping discovery because "I am the customer."** Founder-as-customer is a strong start AND a known bias. Run 10+ discovery interviews to test whether your problem is their problem.
**5. Confusing discovery with validation.** Interviews tell you the problem exists. They don't tell you anyone will pay. Don't ship V1 on discovery alone; run validation first.
## How ShipFit operationalizes this
ShipFit maps the Blank phases to its 9 stages:
- **Discovery** → Stages 2-3 (Who Pays? + What Hurts?)
- **Validation** → Stages 6-7 (How to Charge? + Will They Pay?)
- **Creation** → Stage 8 (How to Launch?)
- **Building** → outside the validation playbook (engineering + ops post-PMF)
Stages 2-3 generate the [Mom Test](/frameworks/mom-test) interview questions tuned to your buyer + hypothesis, then synthesize transcripts into the 3-4 most-cited verbatim pain phrasings + buyer sub-segments + bias checks. The output is a defended discovery deliverable that feeds directly into the validation stages.
## Further reading
- Steve Blank, *The Four Steps to the Epiphany* (2005), the source.
- [The Mom Test framework](/frameworks/mom-test), the interview discipline that makes discovery work.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas), what to do with the persona insights discovery surfaces.
- [How to validate a business idea](/questions/how-to-validate-business-idea), the wider validation flow that follows discovery.
### What Is Product-Market Fit? (And How to Tell If You Have It)
URL: https://shipfit.ai/questions/what-is-product-market-fit
> Product-market fit defined properly. Marc Andreessen's 2007 origin, the Sean Ellis 40% rule, and the operational test that separates real PMF from vibes.
## The fast version
**Product-market fit** is the state where customer pull on your product exceeds your effort to push it. Demand outstrips your ability to serve. Word of mouth compounds. Retention curves flatten instead of decaying to zero. Sales cycles compress.
Coined by Marc Andreessen in 2007 ("[the only thing that matters](https://pmarchive.com/guide_to_startups_part4.html)"). Operational measure: the [Sean Ellis test](/frameworks/superhuman-pmf-engine) (proposed 2009, popularized by Rahul Vohra at Superhuman in 2018):
> "How would you feel if you could no longer use this product?"
> Very disappointed / Somewhat disappointed / Not disappointed.
>
> If 40%+ of active users say "very disappointed," you likely have PMF.
Below 40%: you don't yet, regardless of how good the press is.
## What PMF feels like (Andreessen's original framing)
> "You can always feel when product/market fit isn't happening. The customers aren't quite getting value out of the product, word of mouth isn't spreading, usage isn't growing that fast, press reviews are kind of 'blah,' the sales cycle takes too long, and lots of deals never close. And you can always feel product/market fit when it's happening. The customers are buying the product just as fast as you can make it."
That was 2007. Useful as a directional concept; not useful as an operating tool. You cannot run a planning meeting on a feeling. The Sean Ellis test gives you the number.
## Why most claimed PMF is wishful thinking
Founders routinely claim PMF based on:
- A few enthusiastic early users (sample size 3 is not validation)
- High signup numbers (interest, not retention)
- Press coverage (a press hit is a moment, not market fit)
- Investor enthusiasm (investors fund pre-PMF companies all the time)
None of those are PMF. Real PMF shows up as:
- High retention curves that flatten rather than decay to zero
- Growing organic word of mouth (compounding referral coefficient)
- Decreasing customer acquisition cost as referrals add up
- Sales cycle compression
- A coherent ICP you can describe in one sentence
If you cannot point to those signals AND your Sean Ellis test reads above 40%, you don't have PMF. That is fine. Most companies don't. The point is to know which side of the line you're on so you can act accordingly.
## What to do if you have PMF
Pour fuel. PMF means demand exceeds your ability to serve it. The job changes from finding fit to scaling distribution and operations without breaking the underlying experience.
## What to do if you don't
Stay narrow. Talk to more buyers. Use the [Superhuman PMF Engine](/frameworks/superhuman-pmf-engine) to identify your high-expectations customer and rebuild your roadmap around them. Most pre-PMF startups die from spreading too thin in pursuit of generic growth. The path through is to disproportionately serve the small segment that already loves you, learn what makes them love you, and then expand outward from that nucleus.
## How ShipFit relates to PMF
ShipFit's nine-stage flow is structured to maximize the probability of finding PMF before you commit engineering resources. Stages 1-4 (Worth Building? Who Pays? What Hurts? How to Win?) concentrate on identifying a buyer segment with a real, painful problem and a defensible angle to serve them. Stages 5-7 (What's V1? How to Charge? Will They Pay?) scope the smallest product that could plausibly hit PMF for that segment. Stages 8-9 (How to Launch? What to Export?) take the validated package and ship it.
If you skip the first four stages, you will build something that ships on time and fits no market. That is the modal startup failure.
## Further reading
- [Product-Market Fit glossary entry](/glossary/product-market-fit), short definition + Andreessen's 2007 framing.
- [Superhuman PMF Engine framework](/frameworks/superhuman-pmf-engine), operational measurement and the quarterly improvement loop.
- [Lean Startup validation](/frameworks/lean-startup-validation), the wider discipline that frames PMF as the goal of validated learning.
- [How long does startup validation take?](/questions/how-long-does-startup-validation-take), realistic timeline for the pre-PMF work.
### What Is TAM, SAM, SOM? (And How Founders Get Them Wrong)
URL: https://shipfit.ai/questions/what-is-tam-sam-som
> TAM, SAM, SOM defined properly: Total, Serviceable Addressable, and Serviceable Obtainable Market. Plus the bottom-up SOM math founders should do first.
## The fast version
Three nested market-sizing numbers. From outside in:
| | What it is | How to compute |
|---|---|---|
| **TAM** | Total Addressable Market: total global demand for the category | Industry reports, public market data |
| **SAM** | Serviceable Addressable Market: the slice you could serve | TAM filtered by channel + geography reach |
| **SOM** | Serviceable Obtainable Market: what you can realistically capture in 1-3 years | Bottom-up: buyer count × conversion × price |
**Most founders do this in the wrong order.** The pitch-deck order (TAM → SAM → SOM) inflates the numbers and produces a SOM that's still wishful thinking. The honest order is the reverse: start at SOM, work up.
## The bottom-up SOM math
For a SaaS targeting a specific buyer:
1. **Count specific buyers** that match your defined persona AND are reachable through your year-1 channels.
- Example: "B2B SaaS founders running pre-seed startups in Europe who've raised but haven't shipped" → ~2,000 people (Crunchbase + LinkedIn Sales Navigator search).
2. **Apply a realistic conversion rate.**
- Cold outbound: 1-3%
- Warm-contact (you know them or their network): 5-15%
- PLG with strong virality: 10-25%
3. **Multiply by your price.**
- Annual revenue from each customer = price × 12 (if monthly).
4. **The product is your year-1 SOM revenue.**
In the example: 2,000 people × 5% conversion × $228/year = **$22,800 year-1 SOM revenue**. That's the floor. If the floor doesn't clear your minimum viable business, the buyer segment is too small or the price is too low.
## Why founders inflate TAM
Three failure modes:
**1. The "1% of a $10B market" calculation.** Treats market capture as if you could just dial in a slider. You can't. 1% of a $10B market is $100M, which sounds reasonable; the path to capture even 0.001% of most $10B markets typically takes 5-10 years and dozens of millions in capital.
**2. Including buyers you can't reach.** TAM counts buyers in markets you have no channel into. If you're an indie hacker in London, your effective SAM is bounded by the channels you have today (Twitter, LinkedIn, niche communities). Including the entire German enterprise IT spend in your TAM is a fiction.
**3. Mixing categories.** "We're project management + CRM + invoicing" isn't a market; it's three markets you'd need three GTM motions for. TAM math that adds them together overstates your real opportunity.
## What to use TAM/SAM/SOM for
| Number | Useful for |
|---|---|
| TAM | Convincing an investor the category is big enough to be venture-scale |
| SAM | Showing your channel + geography focus is intentional |
| SOM | Running your business; deciding whether the year-1 numbers add up |
If you're not raising, you mostly only need SOM. If you are raising, all three; but compute SOM honestly first and walk back to SAM/TAM from there.
## How ShipFit handles this
ShipFit's [stage 1 (Worth Building?)](/validate-your-business-idea/market-research) computes SOM honestly from your buyer persona inputs. The system forces you to start small (specific reachable buyer count) and only computes SAM/TAM as context after SOM is locked. If your SOM doesn't clear the minimum viable business threshold, ShipFit suggests pivots (different buyer segment, different price) before recommending you walk away.
## Further reading
- [Pre-launch market research spoke](/validate-your-business-idea/market-research), the full bottom-up SOM workflow.
- [The 9-step playbook](/validate-your-business-idea), where market sizing fits in the wider validation flow.
- [How to validate a business idea](/questions/how-to-validate-business-idea), the question this market math feeds.
---
## Integrations
### Claude Code: Ship Your Validated Playbook into the Terminal
URL: https://shipfit.ai/integrations/claude-code
> Run your validated ShipFit playbook through Claude Code so Anthropic's CLI agent knows your buyer, V1 scope, pricing, and launch plan before it writes a line.
## What Claude Code does
[Claude Code](https://www.anthropic.com/claude-code) is Anthropic's terminal-native coding agent. It reads your repo, writes code, runs tests, and commits, all from the command line. Like Cursor, it leans on Claude as the underlying model. Unlike Cursor, it lives in the terminal instead of an IDE, which makes it the default choice for backend, CLI, or infra work where the IDE is overhead.
Anthropic's documentation describes how Claude Code picks up project context on session start; once that context is loaded, anything in it persists across every prompt for the lifetime of the project. That makes Claude Code the cheapest place to keep your validation decisions in the agent's hands.
## What ShipFit ships to Claude Code
When you reach [stage 9 (What to Export?)](/validate-your-business-idea/with-ai) and pick Claude Code, the export takes the validated playbook produced by the previous 8 stages and lands it in your repo as a Claude Code project. The agent then works from your validated decisions, not generic defaults.
What carries over from the playbook into the export:
1. **Buyer persona** from stage 2 (Who Pays?), including the verbatim quotes from your interviews.
2. **Above-the-line pains** from stage 3 (What Hurts?), scored by frequency × intensity.
3. **Winning angle** from stage 4 (How to Win?), tied to which of the [7 Powers](/frameworks/7-powers) the business will have at maturity.
4. **V1 scope** from stage 5 (What's V1?). Differentiator + Operational features; Delights explicitly held back for V2.
5. **Pricing model** from stage 6 (How to Charge?). Tier structure, entry price, the Pricing Position verdict.
6. **Launch plan** from stage 8 (How to Launch?). Primary channels and message.
ShipFit also installs project-level shortcuts that re-apply the framework gates ([MoSCoW](/frameworks/moscow), [Van Westendorp](/frameworks/van-westendorp), [Superhuman PMF Engine](/frameworks/superhuman-pmf-engine)) during development, so the validation discipline survives past the planning meeting. The exact mechanics are handled for you; you get the discipline, not the configuration burden.
## Install
After running stage 9, unzip the export into your repo root and commit. The next Claude Code session loads everything automatically. No CLI flags, no plugin install.
## Why bother
Three weeks into a build, the conviction from your validation work is fading. Your codebase fills with little exceptions: a feature for "that one user," a pricing-model special case, a launch channel that wasn't in the plan. Each one looks reasonable in isolation. Together they mean V1 ships solving a different problem than the one you validated.
Loading the validated playbook into Claude Code's project context is the cheapest insurance against that drift. The validated decisions stay in the model's view for every prompt, for the life of the project. When the agent is about to wander off scope, the validation context pulls it back.
It's not magic. It's just discipline that's hard to forget because it's sitting in the repo.
## Common mistakes
**1. Treating the export as a one-time setup.** Re-export after any meaningful pivot. The repo's validation context should always match your current ShipFit state, not the version you started with.
**2. Letting the framework gates collect dust.** The first time the gate flags scope creep, the temptation is to dismiss it. The flag means it caught real drift. Investigate.
**3. Mixing engineering conventions with validation context in the wrong place.** Validation goes in one block, engineering conventions (test framework, file layout, linting) in another. Re-exporting refreshes the validation block; your engineering block stays put.
## Further reading
- [Claude Code documentation](https://docs.claude.com/en/docs/claude-code/overview), Anthropic's official getting-started guide.
- [Cursor integration](/integrations/cursor), same playbook, different tool. Most teams use both.
- [Validating a business idea with AI](/validate-your-business-idea/with-ai), the workflow this export plugs into.
### Cursor IDE: Run Your Validated Playbook in the Editor
URL: https://shipfit.ai/integrations/cursor
> Run your validated ShipFit playbook through Cursor so the AI editor knows your buyer, V1 scope, pricing, and launch plan before you autocomplete a line.
## What Cursor does
[Cursor](https://cursor.com) is a fork of VS Code with first-class AI editor integration: tab autocomplete, inline chat, and an agent mode that can edit multiple files and run tests. It's currently the dominant AI-native IDE for indie hackers and startup engineers.
Cursor reads project-level configuration on session start and treats it as system-prompt context for every chat. ShipFit's stage-9 export uses that mechanism to keep your validated decisions in front of the model, every prompt, for the life of the project.
## What ShipFit ships to Cursor
When you reach [stage 9 (What to Export?)](/validate-your-business-idea/with-ai) and pick Cursor, the export takes the validated playbook produced by the previous 8 stages and lands it in your repo as Cursor configuration. The editor's AI then works from your validated decisions, not generic defaults.
What carries over from the playbook into the export:
1. **Buyer persona** from stage 2 (Who Pays?), including verbatim quotes from your interviews.
2. **Above-the-line pains** from stage 3 (What Hurts?), scored by frequency × intensity.
3. **Winning angle** from stage 4 (How to Win?), tied to which of the [7 Powers](/frameworks/7-powers) the business will have at maturity.
4. **V1 scope** from stage 5 (What's V1?). Differentiator + Operational features; Delights held back for V2.
5. **Pricing model** from stage 6 (How to Charge?). Tier structure, entry price, the Pricing Position verdict.
6. **Launch plan** from stage 8 (How to Launch?). Primary channels and message.
ShipFit also installs project-level shortcuts that re-apply the framework gates ([MoSCoW](/frameworks/moscow), [Van Westendorp](/frameworks/van-westendorp), [Superhuman PMF Engine](/frameworks/superhuman-pmf-engine)) during development, so the validation discipline survives past the planning meeting. The exact mechanics are handled for you.
## Install
After running stage 9, unzip the export into your repo root, commit, and restart Cursor. The next chat loads the new context automatically. No CLI, no plugin install.
## Why bother
The honest version: most validated playbooks die in a Notion doc the day you open the editor.
Loading the playbook into Cursor's project context prevents that. The validated decisions stay in the model's view for every prompt, for the life of the project. When you ask Cursor "let's add a settings page," the model already knows whether settings is in V1 or V2 and pushes back if you're sliding into scope creep. When you ask for landing-page copy, the model reaches for your buyer's verbatim pain phrasing, not generic SaaS jargon.
That's the whole game: keep the validation context loaded so engineering decisions cascade from validated answers, not from whatever the AI thinks is plausible.
## Common mistakes
**1. Treating the export as a one-time setup.** Re-export after any meaningful pivot. The repo's validation context should always match your current ShipFit state.
**2. Mixing engineering conventions with validation context in the wrong place.** Validation goes in one block, engineering conventions (test framework, file layout, linting) in another. Re-exporting refreshes the validation block; your engineering block stays put.
**3. Skipping the export and pasting context manually.** Works for the first session. Falls apart by week 2.
## Further reading
- [Cursor documentation on rules](https://cursor.com/docs/context/rules), the official spec.
- [Claude Code integration](/integrations/claude-code), same playbook, terminal-native tool. Most teams use both.
- [Validating a business idea with AI](/validate-your-business-idea/with-ai), the workflow this export plugs into.
### Gemini / Antigravity: Ship Your Validated Playbook
URL: https://shipfit.ai/integrations/gemini
> Run your validated ShipFit playbook through Antigravity (Google's Gemini agent) so it has your buyer, V1 scope, pricing, and launch plan from prompt one.
## What Antigravity / Gemini does
[Antigravity](https://antigravity.google) is Google's coding agent IDE, built around Gemini. It lives somewhere between Cursor (IDE-native) and Claude Code (terminal-first): GUI but more agentic, willing to ship multi-file diffs and run long-form workflows in one shot.
Antigravity reads project-level context on session start and uses it as system prompt for every Gemini conversation. Gemini's 1M+ token context window means you can load the entire validated playbook without worrying about cost or context budget.
## What ShipFit ships to Antigravity
When you reach [stage 9 (What to Export?)](/validate-your-business-idea/with-ai) and pick Gemini / Antigravity, the export takes the validated playbook produced by the previous 8 stages and lands it in your repo as Antigravity configuration:
1. **Buyer persona** from stage 2 (Who Pays?).
2. **Above-the-line pains** from stage 3 (What Hurts?).
3. **Winning angle** from stage 4 (How to Win?), tied to the [7 Powers](/frameworks/7-powers) call.
4. **V1 scope** from stage 5 (What's V1?). Differentiator + Operational; Delights held back for V2.
5. **Pricing model** from stage 6 (How to Charge?).
6. **Launch plan** from stage 8 (How to Launch?).
ShipFit also installs project-level shortcuts that re-apply the framework gates during development, so the 1M-token context window is paired with actual scope discipline.
## Install
After running stage 9, unzip the export into your repo root and commit. The next Antigravity / Gemini session loads the new context.
## Why bother
Gemini's strength is the context window. You can paste the entire validated playbook (and a chunk of your codebase) into a single prompt and ask the model to reason across both. The export makes that automatic: the playbook is always in context, you don't pay for the paste, and the agent's responses cascade from your validated decisions instead of guesswork.
The big-context-window advantage compounds across long agent sessions. Where Cursor / Claude Code have to be more strategic about which context to load, Antigravity can keep all of it loaded for the lifetime of the project.
## Common mistakes
**1. Treating the export as a one-time setup.** Re-export after any meaningful pivot.
**2. Confusing the 1M context window with scope discipline.** A loaded context doesn't enforce scope on its own; the framework gates that ship with the export do.
## Further reading
- [Antigravity documentation](https://antigravity.google/docs), Google's official guide.
- [Cursor integration](/integrations/cursor), for teams that prefer the more conventional IDE feel.
- [Claude Code integration](/integrations/claude-code), terminal-native version of the same export.
- [Validating a business idea with AI](/validate-your-business-idea/with-ai), the workflow this export plugs into.
### Lovable: Run Your Validated Playbook Through the App Builder
URL: https://shipfit.ai/integrations/lovable
> Run your validated ShipFit playbook through Lovable so the AI app builder ships your actual V1 instead of the generic SaaS app it would otherwise default to.
## What Lovable does
[Lovable](https://lovable.dev) is an AI full-stack app builder. You describe an app in plain English; Lovable generates a working React + Supabase app, deploys it, and gives you a URL. It's the most agentic of the AI builders: the output is closer to a deployable product than a prototype.
For early-stage founders, the appeal is obvious: skip the months of "build the auth flow, build the billing flow, build the empty-state UI" and get to a working V1 in days. The tradeoff: Lovable's defaults are aggressive. Without explicit context, it ships everything it thinks a SaaS app should have, which is more than your validation said V1 should be.
ShipFit's stage-9 export gives Lovable the explicit context it needs to ship the *validated* V1 instead of the generic one.
## What ShipFit ships to Lovable
When you reach [stage 9 (What to Export?)](/validate-your-business-idea/with-ai) and pick Lovable, the export turns your validated playbook into Lovable-ready material:
- A project brief covering the validated buyer, V1 scope (Differentiator + Operational), pricing model, brand voice, copy guidelines, and the cut Delight features marked "do not implement."
- A knowledge file you upload to Lovable's Knowledge feature so the validation context persists across multiple chat sessions.
The brief seeds the first build. The knowledge file keeps Lovable on track for every subsequent change.
## How to use it
After running stage 9:
1. Create a new Lovable project.
2. Paste the brief as the initial prompt.
3. Upload the knowledge file to the project's Knowledge feature.
4. Iterate on the build with Lovable's normal chat flow.
After Lovable produces V1, you can keep iterating in Lovable or export the codebase to GitHub and continue in Cursor / Claude Code with the same validated playbook.
## Why bother
Lovable without context produces a beautiful, working, generic app. Beautiful because the agent is good. Working because Lovable's templates are solid. Generic because no one told the agent what makes *your* product specific.
The validated brief fixes that. Lovable + your brief produces a beautiful, working, validated V1: the buyer is yours, the scope matches your stage-5 decisions, the brand voice matches your stage-8 launch plan, and the cut Delight features stay cut even when Lovable suggests them.
## Common mistakes
**1. Skipping the explicit "do not implement" list.** Without it, Lovable adds settings panels, notification preferences, and admin dashboards because they're standard. The export bakes the cut list in; don't strip it.
**2. Re-prompting Lovable in casual language after the brief is loaded.** Once the brief is in, keep prompts in the same structured style. Casual prompts pull Lovable back toward defaults.
**3. Not uploading the knowledge file.** The brief seeds the first build but isn't loaded into every subsequent chat. The knowledge file is. Without it, validation context decays after a few iterations.
## Further reading
- [Lovable documentation](https://docs.lovable.dev), official getting-started.
- [Cursor integration](/integrations/cursor), pair Lovable for V1 build with Cursor for ongoing dev.
- [Validating a business idea with AI](/validate-your-business-idea/with-ai), the workflow this export plugs into.
### Replit Integration: Run Your Playbook Through Replit Agent
URL: https://shipfit.ai/integrations/replit
> Run your validated ShipFit playbook through Replit Agent so it ships your V1 inside Replit's deploy-on-push environment, not a generic full-stack template.
## What Replit does
[Replit](https://replit.com) is a browser-native IDE + deploy platform. Code lives in a Repl, the agent builds it, and one click deploys with a database + auth + custom domain wired up. For founders who want "from idea to live URL today," Replit beats most setups.
The catch: Replit Agent's defaults are generous. Asked to "build a SaaS app," it ships a fully-featured V1 with admin panels, settings pages, notification preferences, and onboarding tours, none of which were in your validated V1 scope.
ShipFit's stage-9 export gives Replit Agent the explicit context it needs to ship the *validated* V1.
## What ShipFit ships to Replit
When you reach [stage 9 (What to Export?)](/validate-your-business-idea/with-ai) and pick Replit, the export turns your validated playbook into Replit-ready material:
- A bootstrap prompt to paste into Replit Agent on a fresh Repl, covering the validated buyer, V1 scope, pricing model, brand voice, and any tech-stack constraints.
- A persistent project context Replit Agent reads on every subsequent interaction, with the persona quotes, V1 keep/cut list, and framework rationale.
The bootstrap seeds the first build. The persistent context keeps Replit Agent on track for every subsequent change.
## How to use it
After running stage 9:
1. Create a new Repl.
2. Open Replit Agent and paste the bootstrap prompt as the first message.
3. After the initial scaffold, drop the persistent context into the repo root.
4. Subsequent Agent interactions inherit the context automatically.
## Why bother
Replit Agent without context produces a generic, deployable, working SaaS app. Generic because the agent doesn't know your validation. Deployable because Replit's stack is solid. Working because the agent is good.
The validation context fixes the "generic" part. Replit + your validated bootstrap produces a deployable, working app that matches your validated buyer and V1 scope. Same speed, validated outputs.
## Common mistakes
**1. Skipping the persistent context.** The bootstrap seeds the first build but doesn't persist on its own. Without the persistent context, by chat 5 the agent has drifted back to defaults.
**2. Using Replit's "deploy now" flow before the V1 scope is locked.** Replit will happily deploy a half-finished app with the maximalist scope. Run a scope check before the first deploy.
**3. Re-prompting in casual language after the bootstrap.** The bootstrap is structured. Casual prompts pull the agent back toward defaults; keep prompts in the same format.
## Further reading
- [Replit documentation](https://docs.replit.com/replit-ai/agent), official Replit Agent guide.
- [Lovable integration](/integrations/lovable), comparable deploy-first AI builder.
- [Validating a business idea with AI](/validate-your-business-idea/with-ai), the workflow this export plugs into.
### v0 Integration: Run Your Validated Playbook Through Vercel
URL: https://shipfit.ai/integrations/v0
> Run your validated ShipFit playbook through v0 so Vercel's UI generator builds screens matching your buyer, V1 scope, and brand voice, not generic templates.
## What v0 does
[v0](https://v0.dev) is Vercel's UI generator: describe a screen in plain English (or paste an image) and v0 produces React + Tailwind components ready to copy into your app. It's the fastest way to go from "we need a dashboard" to "here's a working component" without a designer.
The catch: v0 produces generic UI by default because the model doesn't know what your buyer values, what's in V1, or what voice your brand uses. Without context, you get a template; with context, you get something specific.
That's what ShipFit's v0 export provides: pre-built prompts that load your validation context into v0 in one paste.
## What ShipFit ships to v0
When you reach [stage 9 (What to Export?)](/validate-your-business-idea/with-ai) and pick v0, the export turns your validated playbook into v0-ready prompts:
- A project brief tuned to v0's preferred prompt format, including the validated buyer persona, V1 scope (Differentiator + Operational), brand voice, and copy guidelines drawn from your stage-3 buyer interviews.
- Per-Differentiator-feature prompts that pre-fill the buyer + scope + voice + cut Delight features, so each screen request inherits the validation context.
The output is a small set of markdown files you paste into v0 chats. v0 generates the React components; the components match your validation.
## How to use it
After running stage 9 in ShipFit:
1. Open a new v0 chat and paste the project brief as the first message.
2. For each Differentiator screen, paste the matching pre-filled prompt.
3. Iterate on the design with v0's normal back-and-forth.
4. Export the React code into your repo when you're happy.
The brief only needs to be pasted once per chat. Subsequent prompts inherit the context.
## Why bother
v0's main failure mode for early-stage startups is that the output looks beautiful and is wrong. Beautiful because the model is good at composition. Wrong because the model doesn't know whether settings are in V1 or V2, or whether your buyer wants a dense data table or a guided wizard, or whether your brand voice is terse or expansive.
The validated playbook fixes that. v0 with your validation context still produces beautiful UI, just beautiful UI that matches what your validation said V1 should be.
## Common mistakes
**1. Skipping the project brief.** Pasting a screen prompt without the brief means v0 falls back to generic. Always paste the brief first in a new chat.
**2. Not constraining "do not include."** v0 is generous; if you don't tell it what to leave out, it adds optional features it thinks would be nice. The export bakes the cut Delight features into every prompt; don't strip them out.
**3. Re-typing the buyer description from memory.** The export uses the verbatim phrasing from your interviews. That's the version that resonates. Don't paraphrase.
## Further reading
- [v0 documentation](https://v0.dev/docs), Vercel's official guide.
- [Cursor integration](/integrations/cursor), once v0 produces components, Cursor with the same validation context keeps the wiring consistent.
- [Validating a business idea with AI](/validate-your-business-idea/with-ai), the workflow this export plugs into.
### Windsurf Integration: Run Your Validated Playbook in Cascade
URL: https://shipfit.ai/integrations/windsurf
> Run your validated ShipFit playbook through Windsurf so Codeium's Cascade agent has your buyer, V1 scope, pricing, and launch plan loaded from session one.
## What Windsurf does
[Windsurf](https://windsurf.com) is Codeium's agentic IDE: a VS Code fork built around a chat agent called Cascade. Cascade can read multiple files, write multi-file diffs, run tests, and commit. Compared to Cursor, the contrast is Cascade's appetite for large refactors in one pass; compared to Claude Code, the contrast is that Windsurf is GUI-first while Claude Code is terminal-first.
Windsurf reads project-level configuration on session start and uses it as context for every Cascade conversation. ShipFit's stage-9 export uses that mechanism to keep your validated decisions in front of the agent for the life of the project.
## What ShipFit ships to Windsurf
When you reach [stage 9 (What to Export?)](/validate-your-business-idea/with-ai) and pick Windsurf, the export takes the validated playbook produced by the previous 8 stages and lands it in your repo as Windsurf configuration. Cascade then works from your validated decisions, not generic defaults.
What carries over from the playbook into the export:
1. **Buyer persona** from stage 2 (Who Pays?), with verbatim quotes from your interviews.
2. **Above-the-line pains** from stage 3 (What Hurts?), with frequency × intensity scores.
3. **Winning angle** from stage 4 (How to Win?), tied to which of the [7 Powers](/frameworks/7-powers) the business will have at maturity.
4. **V1 scope** from stage 5 (What's V1?). Differentiator + Operational features; Delights held back for V2.
5. **Pricing model** from stage 6 (How to Charge?). Tier structure, entry price, the Pricing Position verdict.
6. **Launch plan** from stage 8 (How to Launch?). Primary channels and message.
ShipFit also installs project-level shortcuts that re-apply the framework gates during development, so Cascade's appetite for big diffs stays bounded by the validated V1 scope.
## Install
After running stage 9, unzip the export into your repo root, commit, and restart Windsurf. The next Cascade session loads the new context automatically.
## Why bother
Cascade is built to ship big diffs. That's its strength when you're doing a known refactor with clear scope, and its weakness when the scope hasn't been defined. Without project-level context, asking Cascade to "build the user dashboard" produces a 12-file shipset that includes admin features, settings panels, and notification preferences, none of which were in your validated V1.
Loading the validated playbook into Windsurf prevents that. The big-diff capability stays useful; the diffs are now constrained to the validated scope.
## Common mistakes
**1. Treating the export as a one-time setup.** Re-export after any meaningful pivot.
**2. Letting the framework gates collect dust.** The first time the gate flags scope creep, the temptation is to dismiss it. The flag means it caught real drift. Investigate.
**3. Mixing engineering conventions with validation context in the wrong place.** Re-exporting refreshes the validation context; your engineering conventions stay where you put them.
## Further reading
- [Windsurf documentation](https://docs.windsurf.com/), the official Codeium spec.
- [Cursor integration](/integrations/cursor), same playbook, IDE-native alternative.
- [Claude Code integration](/integrations/claude-code), terminal-native version of the same export.
- [Validating a business idea with AI](/validate-your-business-idea/with-ai), the workflow this export plugs into.
---
## Glossary
### ARR vs MRR: What Each Means, How They Differ, When to Use
URL: https://shipfit.ai/glossary/arr-mrr
> ARR and MRR defined plainly. Both measure recurring revenue, rolled up differently. Why mixing them up causes founders to overstate growth, with examples.
## What they are
**MRR (Monthly Recurring Revenue)** is the predictable revenue your subscription business will earn this month, assuming no one new joins and no one cancels. Add up the monthly value of every active subscription. That's MRR.
**ARR (Annual Recurring Revenue)** is the same thing scaled to a year. Either MRR × 12 (the quick version) or the sum of every active annual contract (the precise version, used when most contracts run on yearly terms).
| Metric | What it measures | When to use it |
|---|---|---|
| MRR | Recurring revenue this month | Monthly billing, SMB SaaS, consumer subscriptions |
| ARR | Recurring revenue this year | Annual contracts, mid-market and enterprise SaaS, investor conversations |
Pick the one your sales motion uses. A consumer app with mostly monthly subscribers reports MRR. An enterprise SaaS company selling annual contracts reports ARR. Mixing them is the source of most "we 12×'d our revenue" claims.
## What they are NOT
| What ARR / MRR actually is | What people mean it as |
|---|---|
| **Recurring** revenue only | Total revenue |
| Net of cancellations | Gross bookings |
| Forward-looking under steady state | A historical roll-up of cash collected |
One-time setup fees, professional services, and one-off implementation work do **not** count toward ARR or MRR. They're real revenue, but they're not recurring, and including them inflates the metric in a way investors will catch.
## Worked example
A SaaS company has:
- 100 customers on the $50/month plan
- 30 customers on the $200/month plan
- 5 customers on a $1,200/year annual plan
**MRR calculation:**
- 100 × $50 = $5,000
- 30 × $200 = $6,000
- 5 annual customers / 12 = $500
- **MRR = $11,500**
**ARR calculation:**
- MRR × 12 = $11,500 × 12 = **$138,000**
If the company also closed $20K in one-time setup work this quarter, that $20K does not get added to ARR. It shows up in total revenue, but ARR stays at $138K.
## Common mistakes
**1. Mixing in one-time revenue.** The single most common mistake. Setup fees, services, and add-ons that don't recur should not feed into ARR. Many founders include them to make the number look bigger, then get embarrassed during diligence.
**2. Counting bookings, not billing.** A $120K contract signed today but invoiced quarterly is $120K in ARR, not $480K. The metric is annualized recurring, not "what we sold this quarter × 4."
**3. ARR / 12 ≠ this month's revenue.** A churn-heavy month or a big annual upsell can make actual cash collected diverge sharply from ARR÷12. Use MRR if monthly cash is what you care about.
**4. Reporting ARR without churn.** "$1M ARR" with 8% monthly churn is a different business than "$1M ARR" with 1% monthly churn. The ARR number alone tells you very little. See [Churn glossary](/glossary/churn).
## Further reading
- David Skok, *[SaaS Metrics 2.0](https://www.forentrepreneurs.com/saas-metrics-2/)*. Where the modern ARR/MRR/churn vocabulary comes from.
- [Churn glossary](/glossary/churn). The number that tells you whether your ARR is real or leaking out the back.
- [LTV glossary](/glossary/ltv). What ARR / MRR per customer turns into once you factor in retention.
### Buyer Persona: Definition, Origin, and How to Build One
URL: https://shipfit.ai/glossary/buyer-persona
> Buyer persona defined properly. Tony Zambito coined it in 2002; Adele Revella formalized it. Most personas are decoration; here's what real ones contain.
## What it is
A **buyer persona** is a research-based archetype of a real buyer within a specific market segment. It captures the buyer's priorities, success criteria, fears, decision process, and the specific features they evaluate when choosing a solution. The term was coined by Tony Zambito in 2002, and the modern research-based methodology was formalized by Adele Revella in *Buyer Personas: How to Gain Insight into your Customer's Expectations, Align your Marketing Strategies, and Win More Business* (Wiley, 2015).
A buyer persona is **not**:
- A demographic profile with a stock photo and a pet name
- An invented composite assembled in a conference room
- An aspirational customer you wish would buy
- A persona built from survey data of people who never bought
A buyer persona **is**:
- Built from interviews with people who recently bought a product like yours (ideally in the last 90 days)
- Anchored in the buyer's actual decision process, not your imagined version of it
- Decision-grade: it informs pricing, positioning, scoping, and onboarding choices
- Continuously refreshed as buyer behavior shifts
## Buyer vs user persona
The two are often confused.
| Buyer persona | User persona |
|---|---|
| Who decides to purchase | Who uses the product |
| Drives positioning and pricing | Drives onboarding and product UX |
| In B2B, often a manager or executive | In B2B, often the line worker |
| Research method: buyer interviews | Research method: usability tests, behavioral analytics |
In B2C, buyer and user are usually the same person. In B2B they often diverge. Stripe's user persona is a developer; Stripe's enterprise buyer persona is a CFO with completely different priorities. Build the buyer persona first because it determines positioning and pricing. Layer the user persona second because it determines onboarding and UX.
## What a real buyer persona contains
Adele Revella's [5 Rings of Buying Insight](/frameworks/buyer-persona-canvas#step-3) is the standard structural framework:
1. **Priority Initiative**. What event or pressure made the buyer start looking for a solution?
2. **Success Factors**. What outcomes does the buyer expect six months after purchase?
3. **Perceived Barriers**. What does the buyer fear about your category? What kinds of solutions have failed them?
4. **Buyer's Journey**. The chronological path from problem awareness to purchase decision.
5. **Decision Criteria**. The specific features and attributes the buyer actually evaluated.
If your persona doc does not address all five rings, it is incomplete.
## How many personas do you need?
Most pre-product-market-fit startups need exactly **one**. As you scale and discover new segments worth serving, you add more, but three is the upper bound for most companies under $50M ARR. If you have six personas and no PMF, you have a focus problem, not a research problem. Pick the single segment most likely to pay first and build for them disproportionately well.
## Common misuse
The dominant failure mode in the wild: founders or marketers create "personas" in a conference room without interviewing a single real buyer. The output is decoration: a one-pager with a stock photo, a pet name like "Marketing Mary," and three bullet points about goals and challenges. This persona informs no decision. It is the marketing equivalent of comfort food.
If your persona did not come from buyer interviews, it is not a persona. It is a guess.
## How ShipFit uses buyer personas
ShipFit's Stage 2 (Who Pays?) drafts a working buyer persona using the 5 Rings structure based on the founder's input plus AI-generated hypotheses. Stage 3 (What Hurts?) then pressure-tests the persona by demanding evidence: when did the buyer last describe these pain points to you in their own words? If the founder cannot supply real evidence, ShipFit flags the persona as unvalidated and recommends running [Mom Test interviews](/frameworks/mom-test) before scoping the MVP at Stage 5.
The point is to refuse to let downstream product, pricing, and launch decisions cascade from a persona that was invented rather than researched.
## Further reading
- Adele Revella, *Buyer Personas* (Wiley, 2015). The source for modern research-based methodology.
- Tony Zambito's writing on the 2002 origin and evolution of the buyer persona concept.
- [Buyer Persona Canvas framework](/frameworks/buyer-persona-canvas). Step-by-step guide to building one.
- [The Mom Test framework](/frameworks/mom-test). The interview discipline that makes persona research work.
- [Jobs-to-be-Done framework](/frameworks/jobs-to-be-done). Complementary lens for what the buyer hires your product to deliver.
### CAC (Customer Acquisition Cost): Formula and LTV/CAC Test
URL: https://shipfit.ai/glossary/cac
> CAC defined plainly. The fully-loaded formula, the LTV/CAC ratio that decides whether your unit economics scale, and the ways founders underestimate it.
## What it is
**Customer Acquisition Cost (CAC)** is what it costs you, fully loaded, to convert one new paying customer. Add up every dollar spent on getting them in over a window (ad spend, sales-rep salaries, tooling, content, agency fees), then divide by the number of new customers in that window.
> **CAC = total sales and marketing spend ÷ new customers acquired**
The window is usually one quarter for B2B SaaS, one month for fast-moving consumer products. Pick the window that matches the length of your sales cycle.
## What "fully loaded" means
The number most founders quote is half the real CAC. Honest CAC includes:
| Often counted | Often forgotten |
|---|---|
| Paid ads | SDR / AE salaries + commissions |
| Affiliate payouts | Content marketing salaries |
| Trade show booths | The marketing tools (HubSpot, ad platforms, attribution) |
| Influencer sponsorships | Free-trial infrastructure and support |
If you only count ad spend, CAC looks 3-5× lower than it is. The ratio test below then says "we're crushing it" when the business is actually upside-down.
## The LTV/CAC test
CAC matters only against [LTV](/glossary/ltv). The ratio is the metric.
- **LTV ÷ CAC < 1**: every customer loses you money. Stop acquiring more until something changes.
- **LTV ÷ CAC = 1 to 3**: fragile. You survive only if retention stays high and acquisition costs don't climb.
- **LTV ÷ CAC ≥ 3**: healthy. The unit economics scale.
David Skok's [SaaS Metrics 2.0](https://www.forentrepreneurs.com/saas-metrics-2/) is the reference everyone uses. The 3× threshold is rough; some categories (high-margin B2B SaaS) tolerate 4×, others (consumer subscription with strong network effects) get away with 2×.
## Worked example
A B2B SaaS team spends $20K on ads, $40K on one SDR's quarterly compensation, and $5K on tooling and content in Q1. They close 50 new customers in the quarter.
- Total cost: $20K + $40K + $5K = $65,000
- Customers acquired: 50
- **CAC = $65,000 ÷ 50 = $1,300**
If [LTV](/glossary/ltv) on those customers is $5,000, the ratio is 3.8×. Healthy. If LTV is $2,000, the ratio is 1.5×. Fragile, fix retention or pricing before pouring more into ads.
## Common mistakes
**1. Counting ad spend only.** The biggest, most common mistake. CAC must include the people who run the campaigns and close the leads, not just the media buy.
**2. Mismatched window.** Spending Q1 dollars and dividing by Q4 customers (who were nurtured for nine months) tells you nothing useful. Match the window to the sales cycle.
**3. Mixing channels.** Paid CAC and organic CAC behave differently. Track them separately so you know which channel actually scales.
**4. Treating CAC as fixed.** As you scale, the cheap audiences saturate. Year-1 CAC almost always understates year-3 CAC for the same product.
## Further reading
- David Skok, *[SaaS Metrics 2.0](https://www.forentrepreneurs.com/saas-metrics-2/)*. The original LTV/CAC framework.
- [LTV glossary](/glossary/ltv). The number CAC is judged against.
- [CAC/LTV ratio calculator](/calculators/cac-ltv-ratio). Drop your numbers in and get the verdict.
### Churn Rate: How to Calculate It and Why It Kills SaaS
URL: https://shipfit.ai/glossary/churn
> Churn rate defined plainly. The formula, the difference between customer and revenue churn, and why two-point swings in churn beat ten-point swings in growth.
## What it is
**Churn rate** is the percent of customers (or revenue) that leaves in a given period. If you start the month with 100 customers and 5 cancel, monthly churn is 5%. Simple enough.
Two flavors matter:
- **Customer churn**: percent of accounts that cancel. Counts every cancellation equally, even when one was a $20 hobbyist and another was a $2,000 enterprise contract.
- **Revenue churn (or "net dollar retention" inverted)**: percent of revenue lost from existing customers. A single enterprise downgrade can wreck this even if the customer count stays flat.
> Customer churn = customers lost ÷ customers at start of period
> Revenue churn = revenue lost from existing customers ÷ revenue at start of period
A healthy SaaS business reports both. If only one is reported, it's usually the flattering one.
## Why it matters more than you think
Lifetime value falls off a cliff as churn climbs. The formula is **LTV = (ARPU × gross margin) ÷ monthly churn rate**, so doubling churn cuts LTV in half. Here's what that looks like at constant pricing:
| Monthly churn | Average customer lifetime | LTV (at $100 ARPU, 80% gross margin) |
|---|---|---|
| 1% | 100 months (~8 years) | $8,000 |
| 3% | 33 months (~3 years) | $2,667 |
| 5% | 20 months (~1.5 years) | $1,600 |
| 8% | 12.5 months (~1 year) | $1,000 |
A B2B SaaS at 1% monthly churn ($8,000 LTV) and a consumer app at 8% monthly churn ($1,000 LTV) at the same ARPU are not the same business. They cannot afford the same [CAC](/glossary/cac).
## What it is NOT
| What churn actually is | What people confuse it with |
|---|---|
| A loss-rate, computed against the **starting** cohort | Net change in customer count |
| Two different metrics (customer vs revenue) | One number |
| Compounds across months | A single annual percentage |
A SaaS reporting "5% annual churn" is misleading; that's barely 0.4% monthly, which is unusually low. The two scales are not interchangeable.
## Worked example
A subscription startup starts March with 500 customers paying $40/month. During March:
- 12 customers cancel
- 1 customer downgrades from $40 to $20
- 2 customers upgrade from $40 to $80
**Customer churn**: 12 ÷ 500 = **2.4% monthly**
**Revenue churn**: starting MRR was 500 × $40 = $20,000. Revenue lost from churned and downgraded customers = (12 × $40) + ($40 − $20) = $480 + $20 = $500. Revenue churn = $500 ÷ $20,000 = **2.5%**.
Net dollar retention (the opposite view) factors in the two upgrades: net revenue change = upgrades ($80 each, +$40 each above their old plan = +$80) − revenue churn ($500) = -$420. Net dollar retention = ($20,000 − $420) ÷ $20,000 = **97.9%**.
## Common mistakes
**1. Conflating monthly and annual.** "5% churn" is dangerous to quote without the period. Always specify monthly or annual; the two differ by an order of magnitude.
**2. Tracking customer churn only.** A SaaS losing five $50 customers and gaining one $1,000 customer looks bad on customer churn and great on revenue churn. You need both views.
**3. Excluding voluntary cancellations.** Some teams exclude trial-end drop-offs or downgrades from the churn number to make it look better. The number then doesn't reflect actual revenue dynamics. Be honest about what's included.
**4. Optimistic churn in early-stage forecasting.** A pre-launch founder modelling 2% monthly churn (typical of best-in-class B2B SaaS) when their product is a consumer app produces fantasy unit economics. Use a benchmark anchored in your category.
## Further reading
- David Skok, *[SaaS Metrics 2.0](https://www.forentrepreneurs.com/saas-metrics-2/)*. Defines the churn metrics used industry-wide.
- [LTV glossary](/glossary/ltv). Churn is the dominant variable in the LTV formula.
- [ARR/MRR glossary](/glossary/arr-mrr). Churn is what makes ARR real or imaginary.
### GTM (Go-to-Market): Definition and the Four Common Motions
URL: https://shipfit.ai/glossary/gtm
> GTM defined plainly. What a go-to-market strategy is, the four motions (PLG, sales-led, marketing-led, community-led), and how to pick the one that fits.
## What go-to-market means
Go-to-market, usually shortened to GTM, is the plan for how a product reaches the people
who will buy it and how the buying happens. It covers positioning, pricing, the channels
you use to reach buyers, the motion by which a purchase actually occurs, and the sequence
in which you launch.
It is not marketing, and the two get conflated constantly. Marketing is one input to a
GTM plan. So are pricing, sales process, packaging, partnerships and support. A GTM
strategy is the decision about how all of them fit together for one product and one buyer.
The part founders most often skip is the **motion**: the mechanical answer to how a person
goes from not knowing you exist to having paid. Everything else can be right and the
business still not work if the motion does not match what you charge.
## The four motions
Founders usually pick a motion by temperament. Engineers reach for product-led because it
feels like building, and salespeople reach for sales-led because it feels like selling.
The economics decide it, and the economics are mostly one number.
If your annual contract value is $600, a rep who costs $120,000 a year would need to close
several hundred deals to pay for themselves, at which point they are not really selling.
If your contract value is $80,000, a self-serve signup flow is talking to one person in a
committee of five, and the other four have never heard of you.
## What GTM is not
**Not a launch.** A launch is one day. A go-to-market motion is the repeatable path a buyer
takes, and it has to work in the eleventh month as well as the first.
**Not a channel list.** "We will do content, SEO and LinkedIn" names three places to spend
money. It does not say how a person who reads a post becomes a person who pays, and that
gap is where most GTM plans fail.
**Not fixed.** Motions change as contract value changes. A product that starts self-serve
at $30 a month and adds a $2,000 team plan has acquired a second motion, whether or not
anyone planned for one.
One pattern worth knowing before you write a channel plan. Across 135 AI-generated launch
plans, paid advertising barely features. Whether that reflects what actually works for
early-stage products or simply what a language model has read the most about is a fair
question, and we cannot answer it from this data.
## The order to decide things in
This page defines the term and the motions. For the plan itself, the six parts and the
order they depend on each other in, see the
[GTM strategy framework](/frameworks/gtm-strategy-framework).
1. **Buyer.** Who signs, not who uses. In B2B these differ more often than not.
2. **Price.** It determines the motion, so guessing it late means rebuilding the motion.
3. **Motion.** Chosen from the price, not from preference.
4. **Channel.** Where that buyer already is, constrained by what the motion can afford.
5. **Message.** Written for that buyer, in the language they used in your interviews.
6. **Sequence.** What ships first, and what evidence would justify the next step.
Reversing steps two and three is the common error. A team picks a sales-led motion, hires
a rep, and then sets a price that cannot pay for the rep.
## How ShipFit builds a GTM plan
Stage 8 (How to Launch?) produces the motion, the channels and the launch sequence from the
buyer defined at Stage 2 and the price set at Stage 6, in that order, so the motion is
derived from the economics rather than chosen and then justified.
## Further reading
- [Van Westendorp](/frameworks/van-westendorp). The price that decides the motion.
- [Buyer Persona Canvas](/frameworks/buyer-persona-canvas). The buyer's journey ring, which names everyone involved in the purchase.
- [Jobs to be Done](/frameworks/jobs-to-be-done). What the message has to speak to.
- [CAC / LTV ratio calculator](/calculators/cac-ltv-ratio). Whether the motion you picked can pay for itself.
- [ARR / MRR](/glossary/arr-mrr). What a working motion produces.
- [MVP](/glossary/mvp). What you are taking to market in the first place.
### ICP (Ideal Customer Profile): How It Differs From a Persona
URL: https://shipfit.ai/glossary/icp
> ICP defined plainly. The difference between an ICP and a buyer persona, the firmographic and behavioral attributes a real ICP captures, and a worked example.
## What it is
**Ideal Customer Profile (ICP)** describes the exact type of company or person who buys best from you. They convert quickly, retain longest, expand spend, and refer others. The ICP is the description; an actual list of accounts that match it is your ICP-fit list.
For B2B, an ICP usually captures **firmographic** attributes (company size, industry, geography, tech stack, funding stage) plus **behavioral** ones (currently using a substitute solution, hired their second sales rep in the last quarter, has a specific job-to-be-done active).
A useful ICP is specific enough that, if you tried, you could enumerate every account that matches it. "B2B SaaS" is not an ICP. "Series B B2B SaaS in North America, 50-200 employees, runs HubSpot, sells annual contracts" is.
## ICP vs Buyer Persona
These are different layers and both matter.
| ICP | Buyer Persona |
|---|---|
| Describes the **company** (B2B) or **household segment** (B2C) | Describes the **individual buyer** inside that company |
| Firmographic + behavioral attributes | Demographic + motivational + functional attributes |
| Used to qualify leads and prioritize accounts | Used to design messaging and product UX |
| One ICP per product (usually) | Multiple personas per ICP (decision-maker, user, blocker) |
A SaaS team selling to "Series B B2B SaaS, 50-200 employees" (ICP) might have three personas inside each target account: the VP Sales who decides, the SDR Manager who uses, and the IT lead who can block deployment.
## What an ICP is NOT
| What ICP actually is | What people confuse it with |
|---|---|
| Specific firmographics + behavior | A vague target market ("startups") |
| The buyer who **fits best**, not who you wish bought | An aspirational segment |
| Falsifiable by examining who actually pays and stays | An untestable opinion |
A SaaS team that says "our ICP is mid-market SaaS" but whose top 10 customers are all consumer apps is confusing aspiration with reality. The real ICP is what the data shows.
## Worked example
A B2B fintech product helps finance teams reconcile payments. After 18 months of selling, the team looks at their book and notices:
- The customers with the **lowest churn** are all SaaS companies on Stripe, $5M-50M ARR, with a finance lead who reports to the CFO.
- The customers with the **highest churn** are e-commerce companies on multiple payment processors, where the finance lead reports to operations.
- The customers who **expand spend** are the SaaS group, often adding more seats within six months.
The real ICP, by data: **B2B SaaS, $5M-50M ARR, single-processor (Stripe), finance lead reporting directly to CFO.** Sales and marketing should prioritize accounts matching that profile. The team had been describing their ICP as "anyone with payment-reconciliation pain," which kept their conversion and retention numbers fuzzy.
## How to define an ICP from scratch
If you don't have customers yet:
1. **Hypothesis first.** Pick the buyer where the pain is sharpest, the budget is real, and you have access. Write it down with specific firmographics.
2. **Test with 10 conversations.** Apply the [Mom Test](/frameworks/mom-test) discipline. Look for evidence of the pain in past behavior, not "yeah, I'd buy that" futures.
3. **Refine after 10 paying customers.** Cohort them by who buys fastest, churns least, and expands. The signal will be clear; revise the ICP description to match.
The first ICP is a guess. The third is data. Plan to iterate.
## Common mistakes
**1. Too broad to be operational.** "B2B SaaS founders" is a market, not an ICP. Sharpen until you could list every matching account.
**2. Including aspirational segments.** Founders often include "enterprise" in their ICP because they want to sell up-market. If you don't already sell into enterprise, calling it your ICP misdirects every downstream decision.
**3. No behavioral attribute.** Firmographics alone don't predict fit; behavior does. "Recently hired a Head of Sales" or "currently using a spreadsheet to do this job" is the high-signal half of an ICP.
**4. Confusing ICP with persona.** Targeting the right company with the wrong individual inside it produces stalled deals. Both layers matter.
## Further reading
- [Buyer Persona glossary](/glossary/buyer-persona). The individual layer that sits inside the ICP.
- [Mom Test framework](/frameworks/mom-test). The discipline that turns ICP hypotheses into evidence.
- [Market research spoke](/validate-your-business-idea/market-research). The validation flow that locks in your ICP before launch.
### LTV (Customer Lifetime Value): Why Founders Get It Wrong
URL: https://shipfit.ai/glossary/ltv
> LTV defined plainly. The formula, the typical mistakes, and why the LTV/CAC ratio matters more than the LTV number itself. Worked example with real numbers.
## What it is
**Lifetime Value (LTV)** is the total profit one customer brings in across their entire time as a customer. You earn it slowly through every renewal, every upsell, every month they don't cancel. The number tells you the ceiling on how much you can afford to spend winning that customer in the first place.
David Skok's [classic post on SaaS metrics](https://www.forentrepreneurs.com/saas-metrics-2/) is the source most founders reach for. The simple version of the formula:
> **LTV = (ARPU × gross margin %) ÷ monthly churn rate**
ARPU is average revenue per user per month. Gross margin is the percent of that revenue you actually keep after the cost of serving the customer. Monthly churn is the percent of customers who cancel each month.
## What it is NOT
| What it actually is | What people confuse it with |
|---|---|
| Total **profit** per customer | Total **revenue** per customer |
| A forward-looking estimate | A measured historical number |
| Sensitive to small churn changes | A stable single value |
| One side of a ratio (LTV ÷ CAC) | A number that means anything on its own |
A high LTV with bad churn assumptions is fiction. Two-point monthly churn versus five-point monthly churn changes LTV by 2.5×. The estimate is only as good as the churn input.
## Worked example
A SaaS product charges $99/month. Gross margin is 80% (the other 20% goes to hosting, support, and payment fees). Monthly churn is 4%.
- ARPU × gross margin = $99 × 0.80 = $79.20 of monthly profit per customer
- Divide by churn = $79.20 ÷ 0.04 = **$1,980 LTV**
So the business can afford to spend up to $1,980 acquiring one customer before that customer becomes a net loss. The healthy threshold is to spend less than a third of that on acquisition (LTV ÷ CAC ≥ 3), which means [CAC](/glossary/cac) should sit below $660.
## Common mistakes
**1. Using revenue instead of profit.** Skipping the gross-margin term inflates LTV by 25-40%. The number you compare against CAC must be profit, not revenue.
**2. Optimistic churn.** Founders without real retention data assume 2% monthly churn ("a great SaaS number") instead of looking at their own ten customers. Half of B2C consumer apps churn at 6-10% monthly. Use real numbers from your real cohort.
**3. Quoting LTV without the ratio.** "Our LTV is $5,000" is meaningless without CAC. The ratio is the metric; the number is one of its two inputs.
**4. Treating LTV as fixed.** LTV moves every time your pricing changes, your churn shifts, or your gross margin compresses. Recompute quarterly.
## Further reading
- David Skok, *[SaaS Metrics 2.0](https://www.forentrepreneurs.com/saas-metrics-2/)*. The canonical reference for LTV/CAC mechanics.
- [CAC glossary](/glossary/cac). The other half of the ratio.
- [CAC/LTV ratio calculator](/calculators/cac-ltv-ratio). Plug in your numbers and get the verdict.
### MVP (Minimum Viable Product): What It Actually Means
URL: https://shipfit.ai/glossary/mvp
> MVP defined properly. Frank Robinson coined it in 2001; Eric Ries popularized it in 2011. What an MVP is, what it isn't, and how founders misuse the term.
## What an MVP is
A minimum viable product is the smallest thing you can build that produces evidence about
one risky assumption. The term was popularised by Eric Ries in *The Lean Startup* (2011),
building on earlier use by Frank Robinson and Steve Blank.
The load-bearing word is **viable**, and it does not mean "good enough to sell". It means
the thing is capable of returning a verdict. An MVP is judged by what it teaches, not by
what it does, which is why several of the standard forms are not software at all.
That definition has largely been lost. In common use "MVP" now means a small first version
of the real product, which is a different object with a different purpose, and the
confusion is expensive: a small first version has no named assumption, no threshold that
would count as failure, and therefore no way to be wrong.
## What an MVP is not
It is not version one. A first release is something you intend to keep and grow; an MVP is
something you are prepared to throw away the moment it has answered its question.
It is not a product with the features removed. Removing features from a product you have
already decided to build tests nothing, because the decision was made before the experiment.
It is not an excuse for poor quality. The scope is minimal; the execution of that scope is
not. A broken experiment returns a verdict on your engineering rather than on your
assumption.
We can put a number on how far the word has drifted, and it is our own number. ShipFit
proposes an MVP scope, sorts it into Lean, Balanced and Full, and recommends one. What a
tool built to cut scope actually recommends is a seven-month build.
## The common forms
The question that picks the form is not "how much can we build" but "what are we trying to
find out". Three of these five are barely software.
## How to scope one
1. **Write the assumption down first.** One sentence, in the form "we believe [buyer] will
[behaviour] because [reason]". If you cannot write it, you are not running an experiment.
2. **Write the threshold.** What result would make you stop? Deciding this after seeing the
data is the single most common way the method gets hollowed out, and it is invisible
from outside.
3. **Pick the cheapest form that can produce that result.** Work up the table above, not
down. Most teams start at "single-feature" out of habit.
4. **Cut everything that does not serve the test.** Not everything that is nice to have.
Everything that does not change the answer.
5. **Decide in advance who reads the result and when.** An experiment nobody has agreed to
act on is a release with an experiment's name attached.
## How ShipFit scopes an MVP
Stage 5 (What's V1?) runs every candidate feature through the cannot-ship-without test and
produces three packages (Lean, Balanced, Full) with the Must list explicit in each. Each
package is tied to the hypothesis from Stage 1, so what ships is scoped against what it is
meant to prove rather than against what would be nice to have.
## An MVP in practice: Zappos
The clearest example of the definition on this page, from a founder who lost money on every early sale on purpose.
## Further reading
- [Lean Startup validation](/frameworks/lean-startup-validation). The loop an MVP exists inside.
- [MoSCoW](/frameworks/moscow). How to cut a candidate list down to a scope an experiment can test.
- [ICE scoring](/frameworks/ice-scoring). How to sequence what survived the cut.
- [The Mom Test](/frameworks/mom-test). Often cheaper than an MVP, when the question is answerable by asking.
- [TAM SAM SOM](/glossary/tam-sam-som). The market the MVP is being aimed at.
### Product-Market Fit (PMF): Origin and How to Measure It
URL: https://shipfit.ai/glossary/product-market-fit
> Product-market fit defined. Marc Andreessen's 2007 origin, Sean Ellis's measurement, and why most claimed PMF is wishful thinking. Plus how to test for it.
## What it is
**Product-market fit (PMF)** is the state where a product satisfies strong market demand from a specific buyer segment, such that customer pull on the product exceeds the founder's effort to push the product into the market. The phrase was coined by [Marc Andreessen in 2007](https://pmarchive.com/guide_to_startups_part4.html) in his "Pmarca Guide to Startups, part 4: The only thing that matters."
Andreessen's original framing was felt, not measured:
> "You can always feel when product/market fit isn't happening. The customers aren't quite getting value out of the product, word of mouth isn't spreading, usage isn't growing that fast, press reviews are kind of 'blah,' the sales cycle takes too long, and lots of deals never close. And you can always feel product/market fit when it's happening. The customers are buying the product just as fast as you can make it."
That was the founding 2007 definition. Useful as a directional concept; not useful as an operating tool. You cannot run a planning meeting on a feeling.
## How to measure it
The dominant operational measure today is the **Sean Ellis test** (proposed in 2009, popularized by [Rahul Vohra at Superhuman in 2018](/frameworks/superhuman-pmf-engine)):
> Send active users a one-question survey: **"How would you feel if you could no longer use this product?"**
>
> Options: Very disappointed / Somewhat disappointed / Not disappointed.
>
> If 40% or more answer "very disappointed," you likely have product-market fit.
The 40% threshold is a heuristic, not a law. Some great products plateau at 35%; some narrow segments spike to 50%+. The directional movement of the score (rising or falling quarter over quarter) matters more than the absolute number.
## Why most claimed PMF is wishful thinking
Founders routinely claim PMF based on:
- A few enthusiastic early users (sample size 3 is not validation)
- High signup numbers (interest, not retention)
- Press coverage (a press hit is a moment, not market fit)
- Investor enthusiasm (investors fund pre-PMF companies all the time)
None of those are PMF. Real PMF shows up as:
- High retention curves that flatten rather than decay to zero
- Growing organic word of mouth
- Decreasing customer acquisition cost as referrals compound
- Sales cycle compression
- A coherent ICP that you can describe in one sentence
If you cannot point to those signals AND your Sean Ellis test reads above 40%, you do not yet have PMF. That is fine. Most companies do not. The point is to know which side of the line you are on so you can act accordingly.
## What to do if you have PMF
Pour fuel. PMF means demand exceeds your ability to serve it. The job changes from finding fit to scaling distribution and operations without breaking the underlying experience.
## What to do if you do not have PMF
Stay narrow. Talk to more buyers. Use the [Superhuman PMF Engine](/frameworks/superhuman-pmf-engine) to identify your high-expectations customer and rebuild your roadmap around them. Most pre-PMF startups die from spreading too thin in pursuit of generic growth. The path through is to disproportionately serve the small segment that already loves you, learn what makes them love you, and then expand outward from that nucleus.
## How ShipFit relates to PMF
ShipFit's nine-stage flow is structured to maximize the probability of finding PMF before you commit engineering resources. Stages 1-4 (Worth Building? Who Pays? What Hurts? How to Win?) concentrate on identifying a buyer segment with a real, painful problem and a defensible angle to serve them. Stages 5-7 (What's V1? How to Charge? Will They Pay?) scope the smallest product that could plausibly hit PMF for that segment. Stages 8-9 (How to Launch? What to Export?) take the validated package and ship it.
If you skip the first four stages, you will build something that ships on time and fits no market. That is the modal startup failure.
## Further reading
- Marc Andreessen, ["The only thing that matters"](https://pmarchive.com/guide_to_startups_part4.html), 2007. The origin essay.
- [Superhuman PMF Engine framework](/frameworks/superhuman-pmf-engine). Operational measurement and the quarterly improvement loop.
- [Lean Startup validation](/frameworks/lean-startup-validation). The discipline that frames PMF as the goal of validated learning.
- [MVP glossary entry](/glossary/mvp). The minimum product to test for PMF.
### Runway and Burn Rate: How Long Before You're Out of Money?
URL: https://shipfit.ai/glossary/runway
> Runway and burn rate defined plainly. The formula every founder should know, the gross-vs-net distinction nobody explains clearly, and a worked example.
## What they are
**Burn rate** is the rate at which a startup spends cash, in dollars per month. **Runway** is how many months of operations the startup can fund at that burn before the bank account hits zero.
> **Runway (months) = current cash ÷ monthly burn rate**
A founder with $60,000 in the bank burning $10,000 a month has six months of runway. When that founder is also closing $3,000 in revenue each month, burn drops to $7,000 net and runway extends to 8.6 months.
## Gross burn vs net burn
These are different numbers. Be precise about which one you mean.
| Term | Formula | When to use |
|---|---|---|
| **Gross burn** | Monthly cash out (expenses only) | Stress-testing in a scenario where revenue stops |
| **Net burn** | Monthly cash out minus monthly revenue | Everyday planning, runway projections |
Quoting gross burn when you mean net (or vice versa) confuses investors and bites founders during diligence. Pick the right one for the context.
## Three runway thresholds that matter
The Y Combinator default rule of thumb, drawn from Paul Graham's *[Default Alive or Default Dead](http://www.paulgraham.com/aord.html)*:
- **Under 3 months**: emergency. Find a job, raise bridge, cut costs aggressively, in that order.
- **3 to 6 months**: serious. Start raising right now (rounds take 3-6 months to close) or have a credible path to profitability.
- **6 to 12 months**: comfortable. Plan the next round or the path to default-alive.
- **12+ months**: you have time to build before fundraising pressure returns.
Graham's "default alive" test: at the current growth rate of revenue and expenses, will you be profitable before you run out of money? If yes, default alive. If no, default dead, and the only way out is to raise.
## What they are NOT
| What runway actually is | What people confuse it with |
|---|---|
| Months until cash hits zero at current burn | Months until next financial milestone |
| Sensitive to revenue and expense changes | A static, set-and-forget number |
| Net of recurring revenue | Just savings ÷ expenses |
A founder calling "12 months of runway" off $120K of savings divided by $10K rent while ignoring $4K of subscription revenue is reporting gross runway. Net runway (factoring revenue) is higher; that's the more useful figure for the build/no-build decision.
## Worked example
A solo founder has $90,000 in the bank. Monthly expenses:
- $4,000 personal living costs
- $1,200 for SaaS tools and infrastructure
- $800 for contractors
- $500 in misc (taxes set-aside, hardware amortized)
Gross burn = **$6,500/month**. Gross runway = $90,000 ÷ $6,500 = **13.8 months**.
The product earns $2,000/month in subscription revenue.
Net burn = $6,500 − $2,000 = **$4,500/month**. Net runway = $90,000 ÷ $4,500 = **20 months**.
The founder shifts 2 hours/day to a part-time consulting gig at $80/hour, earning an additional $3,200/month.
Adjusted net burn = $6,500 − $2,000 − $3,200 = **$1,300/month**. Adjusted runway = $90,000 ÷ $1,300 = **69 months**.
The maths is the same; the inputs change everything. Part-time consulting + bootstrapped revenue is one of the most reliable runway extenders for solo founders, and almost nobody factors it in until they're already at three months.
## Common mistakes
**1. Reporting gross when you mean net.** A founder with $1M in the bank burning $80K gross but earning $50K MRR has 33 months net runway, not 12 months gross. Quote net unless explicitly stress-testing.
**2. Forgetting taxes and one-time costs.** Many founders model only recurring expenses. Quarterly tax payments, annual SaaS renewals, and the one-off laptop purchase combine to consume 8-12% of the runway nobody planned for.
**3. Assuming revenue keeps growing.** A runway model that assumes 10% MoM revenue growth past month 6 is fragile. Build a "what if revenue stays flat" version and use that one for raising-decision timing.
**4. Refusing to cut costs until month 3.** By the time runway hits three months, your cost cuts have to ship instantly. Decide your cut-cost triggers in advance (e.g., "if I'm at six months and growth is flat, contractors go").
## Further reading
- Paul Graham, *[Default Alive or Default Dead](http://www.paulgraham.com/aord.html)*. The framing every founder should pressure-test their model against.
- [Startup runway calculator](/calculators/startup-runway). Plug your numbers in and get the verdict.
- [Burn rate calculator](/calculators/burn-rate). For the gross vs net split.
### TAM, SAM, SOM: What Each Means and Why Founders Get It Wrong
URL: https://shipfit.ai/glossary/tam-sam-som
> TAM, SAM, and SOM defined plainly. Why honest founders compute them bottom-up (SOM first), not top-down from analyst reports. Worked example with real numbers.
## What TAM, SAM and SOM mean
TAM, SAM and SOM are three market-size figures, each narrower than the last.
**TAM**, the total addressable market, is what the category would be worth annually if
every possible buyer on earth bought. **SAM**, the serviceable addressable market, is the
share of that your product could actually serve today, given your language, geography,
segment and capability. **SOM**, the serviceable obtainable market, is what you could
realistically win within a few years, given your channels, your conversion rate and your
price.
The three are usually drawn as circles of similar size, which quietly implies the numbers
are comparable. They are not. In any honest calculation the SOM is a sliver of the TAM,
and drawing it to scale is the fastest way to understand why "we only need 1% of this
market" is a sentence rather than a plan.
## Why SOM is the only one that constrains anything
TAM answers a question investors ask to check the ceiling is not embarrassingly low. It
has no bearing on what you build, who you sell to, what you charge or how you reach them.
SOM touches all four. It is derived from your actual channels and your actual conversion
rate, so changing it means changing something real about the business. That is what makes
it the number worth arguing about, and it is the one most decks skip past on the way to
the big circle.
## Top-down and bottom-up
There are two ways to arrive at these numbers and they are not equally defensible.
The tell is whether anyone can attack a specific line. "3% of a $4bn market" offers nothing
to disagree with, which feels like strength and is the opposite. A bottom-up figure invites
someone to say your conversion assumption is optimistic, and that conversation is worth
having before you build.
## What these numbers are not
They are not a forecast. A SOM is a ceiling on what you could obtain, not a projection of
what you will, and treating it as revenue guidance is how three-year plans end up
disconnected from the first year.
They are not static. Each is a function of your price, your segment and your reach, all of
which you change deliberately. Doubling your price halves the number of buyers who qualify
and may raise or lower the SOM depending on which effect dominates.
And they are not a substitute for demand. A market can be genuinely large and contain
nobody willing to switch this year.
On which subject, a number about market scoring generally, and about ours in particular.
ShipFit grades market opportunity out of 100. Across 520 ideas it has never once told anyone
to stop.
## How ShipFit uses this
ShipFit sizes the market bottom-up at Stage 1 (Worth Building?), from your defined buyer
rather than from an analyst report, and carries the SOM forward into pricing at Stage 6 so
the price and the obtainable revenue are checked against each other rather than decided
separately.
The [TAM SAM SOM calculator](/calculators/tam-sam-som) runs the same arithmetic on your own
numbers.
## Further reading
- [TAM SAM SOM calculator](/calculators/tam-sam-som). The bottom-up calculation above, on your figures.
- [The Mom Test](/frameworks/mom-test). How to confirm the demand a market size cannot measure.
- [Van Westendorp](/frameworks/van-westendorp). The price that every one of these numbers depends on.
- [Blue Ocean Strategy](/frameworks/blue-ocean-strategy). What to do when the market you sized is thoroughly contested.
- [ARR / MRR](/glossary/arr-mrr). The revenue the SOM is a ceiling on.
---
## Calculators
### Break-even calculator — how many units to stop bleeding cash
URL: https://shipfit.ai/calculators/break-even
> Free break-even calculator. Three inputs: fixed cost, price, variable cost. One number — exact unit count where revenue covers cost. No spreadsheet required.
_How many units a month before the math stops bleeding?_
Tells you how many units you need to sell each month to cover your fixed costs at the price and variable cost you've set. Best for products with a meaningful per-unit variable cost — physical goods, marketplaces, usage-based tiers. For pure SaaS where per-user cost is near-zero, the number compresses to noise; use the CAC/LTV calculator instead.
#### FAQ
**What goes in 'fixed' vs 'variable' costs?**
Fixed costs don't change with the next unit sold — rent, salaries, infra base. Variable costs do — Stripe fees per transaction, packaging per unit, AI inference per session, support cost per active customer. If selling one more customer adds the cost, it's variable; otherwise it's fixed.
**What if my variable cost per unit is bigger than my price?**
Then break-even is infinite — you lose money on every unit. The calc flags this as red. Fix: either raise the price or cut the variable cost per unit (cheaper infra, automate support, batch payment processing). Adding volume to a negative-margin product just bleeds faster.
**Why does break-even ignore acquisition cost?**
Because break-even tells you the floor — how many units before your operations stop losing money. CAC is a separate question (covered in the CAC/LTV ratio calc). A product can be break-even-profitable per unit and still need 18 months of CAC payback. Both matter; this calc isolates the operations side.
**Is this per-month or total?**
Per month — the fixed cost input is monthly, and the output is units per month. If you sell annual contracts, divide the annual price by 12 for the price-per-unit input so the math stays apples-to-apples.
### Burn rate calculator — gross vs net burn for founders
URL: https://shipfit.ai/calculators/burn-rate
> Free burn rate calculator. Two inputs separate gross from net burn — the number that says whether you're spending too fast or pacing toward break-even.
_Gross burn lies. Net burn tells you the truth._
Splits your monthly spend into gross burn (every dollar out) and net burn (after subtracting revenue) — the two numbers most founders confuse. Quote net for everyday runway planning. Quote gross when investors are stress-testing what happens if revenue disappears. Knowing which to use, and when, separates founders who survive from founders who get caught off-guard.
#### FAQ
**What's the difference between gross and net burn?**
Gross burn is total cash out. Net burn is cash out minus cash in. If you spend $30K/month and earn $20K/month, your gross burn is $30K but your net burn is $10K. Net is what depletes the bank account — and it's the one your runway needs to be calculated against. Pitching gross burn to investors makes you sound more capital-intensive than you are.
**Why does this matter for a pre-revenue startup?**
It mostly doesn't — at pre-revenue, gross = net by definition. The calc matters the moment you have any revenue, because that's when most founders start quoting gross burn out of habit. The day you cross your first $1 of MRR, switch to net.
**Should I add back deferred revenue?**
No. Deferred revenue (annual prepay sitting on your balance sheet) is cash you already have — it's already in the cash-on-hand bucket the runway calc uses. Adding it again double-counts.
**What burn rate should I target?**
Whatever lets you hit your next milestone (PMF, next funding round, profitability) with 25% buffer. Net burn that puts you 6 months from zero is acceptable if you're 4 months from a milestone. Net burn that puts you 6 months from zero with no milestone in sight is panic mode.
### CAC LTV ratio calculator — do your unit economics work?
URL: https://shipfit.ai/calculators/cac-ltv-ratio
> Free CAC LTV ratio calculator. Four inputs, one ratio, one verdict. Find out whether each customer makes you money — before you burn $10K on paid acquisition.
_Does each customer make you money? Or cost you money?_
Plug in your CAC, monthly ARPU, gross margin, and churn to see whether each customer makes you money or costs you money. Best run once you have 10+ paying customers and a real churn number — before you pour another dollar into paid acquisition. The ratio is the SaaS investor's first diligence question; this is the answer.
#### FAQ
**Is LTV / CAC ≥ 3 really the rule?**
It's the SaaS heuristic — David Skok popularized it. The reasoning: anything under 1 loses money, 1-3 only works if your retention is perfect, and 3+ leaves enough margin to fund growth and survive churn shocks. For non-SaaS (transactional, marketplaces) the number changes — high-frequency repeat businesses can survive at 2; one-shot transactional needs 5+. Use 3 as the default and adjust if your business has different repeat dynamics.
**Why monthly ARPU and monthly churn, not annual?**
Because churn compounds monthly. Annual churn of 30% sounds like 30%, but monthly that's about 2.9% — and the LTV formula needs to know how fast you bleed customers. Monthly numbers are also closer to what you can actually measure in the first 6 months of a SaaS business.
**What do I do if my ratio is below 1?**
Either your CAC is too high or your retention is too low. Pull CAC apart: which channel is the worst offender? Cut it or fix the funnel. Pull retention apart: are you losing customers in the first 30 days (onboarding problem), 90 days (value problem), or 12+ months (saturation)? Each diagnosis has a different fix. Don't try to fix both at once.
**Does this account for gross margin?**
Yes — LTV is calculated as (ARPU × gross_margin) / churn, not just ARPU / churn. Margin matters: a $100/month customer at 90% gross margin contributes $90/month to LTV; at 30% they contribute $30. SaaS with bad COGS (heavy AI usage, expensive third-party APIs) can look ARPU-healthy and still be CAC-LTV broken.
### Equity split calculator — fair shares, zero resentment
URL: https://shipfit.ai/calculators/equity-split
> Free equity split calculator. Score the contribution of up to 4 co-founders; get a proportional split and a verdict on whether it'll survive year three.
_Founder equity that won't blow up the cap table in year three._
Weighs each cofounder's contribution across time committed, role, and capital invested — then returns a recommended equity split plus a fairness check that flags suspicious 50/50 defaults. Use this before incorporation, before the founder agreement gets signed. Once the cap table is locked, this calculator suggests fair splits but can't unwind a bad one.
#### FAQ
**Should co-founders just split equity equally?**
No, unless contributions are genuinely equal — which is rare. Equal-split feels fair on day 1 and feels wrong by month 18 when one founder is doing 70% of the work. The honest conversation early (using a calculator like this) prevents the cap-table-renegotiation hell of year two.
**What dimensions should I weigh?**
The three that hold up in court: (1) time committed full-time (the biggest by far — equity follows risk and risk is what you give up), (2) capital invested, (3) role criticality at this stage (CEO/CTO at a software startup matter more than COO does at month 2). Don't weigh 'who had the idea' — ideas are cheap and the founder who executes will resent the one who gets equity for having had it.
**What about vesting?**
Always vest. 4-year standard, 1-year cliff. The equity split tells you the destination; vesting tells you who actually gets there. Founders who leave before the cliff get nothing — protect the cap table from this early.
**When should I run this calculator?**
Before the second co-founder conversation, not after. If you're already 6 months in with an unspoken assumption of 50/50 and the contributions diverge, you need a renegotiation, not a calculator. Use this BEFORE making any verbal or written commitment.
### Idea score calculator — is your startup idea worth building?
URL: https://shipfit.ai/calculators/idea-score
> Free idea score calculator. Answer 5 questions on market, buyer, pain, differentiation, and willingness-to-pay for a brutal 0–100 verdict on whether to build.
_5 questions. 0-100 score. One brutal verdict on whether to build._
Five yes/no/maybe questions across Market, Buyer, Pain, Differentiation, and Willingness to Pay. Returns a 0-100 score plus a one-line verdict so you know whether to commit a weekend to it or move on. A 60-second triage when you have multiple ideas and need to pick one — not a substitute for the full validation work once you've picked.
#### FAQ
**What's the difference between this and an MVP test?**
An MVP test costs you 2-6 weeks of build time. This costs you 60 seconds. The Idea Score is the pre-MVP gate — if you can't honestly score yes/maybe on at least 3 of the 5 dimensions today, your MVP will fail and you'll have learned the same thing 2 months later. The score doesn't replace validation; it tells you whether you're ready to start validating.
**Why these 5 dimensions specifically?**
Because they are the 5 dimensions that show up in every post-mortem of a failed pre-PMF startup. CB Insights surveyed founders of 110 failed startups: 42% died from no market need (Market + Pain dimensions), 17% from getting outcompeted (Differentiation), 14% from no buyer demand (Buyer + WTP). All five dimensions are covered by these five questions.
**What's the difference between Yes, Maybe, and Not yet?**
Yes = you have concrete evidence (named buyers, paid waitlist, observable behavior). Maybe = you have a strong intuition or analog from another market. Not yet = you have neither. Most first-time founders score themselves Yes on everything. Most experienced founders score themselves Maybe on everything. The honest answer is usually Not yet on at least 2 dimensions — that's where validation work should focus.
**Why is the per-dimension breakdown gated?**
Because the score alone is a useful sanity check (free). The per-dimension breakdown — which dimensions are strong, which are weak, and what to do about each — is the playbook. We give the playbook to people who sign up. If you want it without signing up, run validation on the weakest dimension first; the answer in this calc tells you which one that is.
### Pricing strategy calculator — your price via Van Westendorp
URL: https://shipfit.ai/calculators/pricing-strategy
> Free pricing strategy calculator using the Van Westendorp Price Sensitivity Meter. Four inputs from buyer research yield your optimal price and its band.
_Van Westendorp in 4 numbers. Skip the survey-platform fees._
Takes the four Van Westendorp price-perception responses (too cheap, cheap, expensive, too expensive) and derives an Optimal Price Point, Indifference Price Point, and an acceptable price band. Run it before you publish a price — and only after you've surveyed 30+ people in your actual ICP. Under that sample, the curves don't stabilize and the output will look authoritative but lie to you.
#### FAQ
**Where do I get the four price numbers from?**
From buyers. The classic Van Westendorp survey asks each buyer four questions: at what price would this be (1) so cheap you'd doubt the quality, (2) a bargain, a great buy for the money, (3) expensive but still worth considering, (4) so expensive you wouldn't buy at all. Run it on 30-100 target buyers (cold list, NOT existing customers) and use the median answer to each question. Drop any respondent whose four answers aren't in increasing order; they misread a question. Full walkthrough on the [Van Westendorp framework page](/frameworks/van-westendorp).
**Can I just use my own gut for the four numbers?**
No, but yes. Use your gut to see where the calc lands, then go run the survey. If your gut numbers predict $99 and the survey predicts $39, your gut was wrong about pricing — that's the whole point. Founders' gut on pricing is the #2 source of pricing errors (the #1 source is copying competitor prices).
**Why not just A/B test the price?**
Because pricing A/B tests are noisy at small scale and ethically expensive (the losing variant gets a worse deal). Van Westendorp is what you do before you launch to find the right starting price; A/B tests are what you do at 1,000+ customers/month to refine within the acceptable band.
**What is the Indifference Price Point, and how is it different from the Optimal Price Point?**
Different pairs of curves, different meanings. The Indifference Price Point is where 'expensive' crosses 'bargain': half the buyer pool reads the price as cheap and half as expensive. The Optimal Price Point is where 'too cheap' crosses 'too expensive': equal numbers reject you at each extreme, so combined objection is lowest. Neither one is the edge of your range. The band runs from the Point of Marginal Cheapness (too cheap against expensive) up to the Point of Marginal Expensiveness (too expensive against bargain), and both OPP and IPP sit inside it.
**Is the Optimal Price Point the price that makes the most money?**
No, and the name is genuinely misleading. The OPP is the price with the least combined buyer objection. Revenue is price multiplied by the share who actually buy, and that peak usually sits above the OPP. To find it you need purchase-probability data on top of the four price answers, which is the Newton, Miller and Smith extension covered on the [framework page](/frameworks/van-westendorp).
### Startup runway calculator — months before you raise or die
URL: https://shipfit.ai/calculators/startup-runway
> Free startup runway calculator. Two inputs, one number, one verdict. Find out how many months before the bank account hits zero — and what to do about it.
_How many months until the bank account hits zero?_
Drop in your cash on hand and monthly net burn — the calculator tells you how many months until the bank account hits zero. Under three months is an emergency. Six to twelve is comfortable. Re-run it every time burn or revenue changes; founders who track this monthly outlive founders who don't.
#### FAQ
**What counts as 'burn'?**
Net burn — total cash out minus total cash in. If you have any revenue, subtract it. Don't use gross burn (cash out only) for runway — gross burn double-counts the runway your revenue is already covering. The bank statement, not the P&L, is what matters.
**Should I include money I haven't raised yet?**
No. Runway is the timeline you have without intervention. If you're including promised-but-not-wired money, you're confusing 'how long can I survive' with 'how long if everything goes right.' Use the worst-case number — that's the one the bank statement will show if your soft circle falls through.
**I'm bootstrapped with no monthly burn. Does this apply?**
If you're break-even or profitable, your runway is infinite — congratulations, you don't need this calculator. The calc matters when burn > revenue, which is the default state of a pre-PMF startup.
**Why is 3 months the panic line?**
Because raising a round takes 3-6 months on average, and that's once you have warm intros and a pitch deck. If you have less than 3 months of runway and you haven't started talking to investors, you're not raising — you're closing. The 3-month line is the latest possible date to either be fundraising actively or cutting hard.
### Startup valuation calculator: SaaS value in three inputs
URL: https://shipfit.ai/calculators/startup-valuation
> Free startup valuation calculator using ARR + growth + margin to project a low / mid / high range based on public SaaS comps. No fundraising degree required.
_What's your SaaS worth? Low, mid, high, in three inputs._
Multiplies your ARR by a SaaS revenue multiple keyed to your growth rate and gross margin, returning a valuation range (low / mid / high) anchored in public comps. Use it before fundraise conversations, or when weighing an acquisition offer against staying independent. Don't run it pre-revenue — multiples don't apply yet, and team + traction signals carry that math instead.
#### FAQ
**Why ARR-multiples and not DCF?**
Because for pre-Series-B SaaS, DCF is theatre. Cash flows are too unstable to forecast credibly. The market prices SaaS on ARR multiples adjusted for growth + margin — Bessemer's State of the Cloud and the BVP Nasdaq Emerging Cloud Index publish this every quarter. The multiple is the truth-tellers' shortcut.
**How does growth rate change the multiple?**
Massively. A 20% growth rate puts SaaS at ~4× ARR. 70% growth puts it at ~12×. 150%+ growth puts it at ~20× or more. The premium for fast growth compresses or expands based on the public market — in 2021 multiples were 2-3× higher than 2024. This calc uses long-run averages.
**Why does gross margin matter?**
Because revenue isn't profit. A SaaS at 90% gross margin keeps $0.90 of every dollar after COGS; at 40% only $0.40. Investors discount low-margin SaaS heavily — AI-heavy startups with expensive inference costs often look ARR-rich and valuation-poor for this reason.
**Should I use this for fundraising?**
As a sanity check, yes. For the actual negotiation, no — investors run their own model and the negotiation is mostly about narrative and terms, not the calc. Use this calc to know when an offer is way under or over the public-comps math; use the negotiation to fight for your specific story.
### TAM SAM SOM calculator — bottom-up sizing for founders
URL: https://shipfit.ai/calculators/tam-sam-som
> Free TAM SAM SOM calculator. Three inputs, one number, one verdict. Skip the consulting deck — see whether the market is worth your time in under 60 seconds.
_Bottom-up SOM in three inputs. Skip the consulting deck._
Counts the buyers you could realistically reach, applies an honest conversion rate, multiplies by your price — and gives you a year-1 SOM revenue number you can actually defend. Use this before you commit to a build, when you're stress-testing whether a niche is big enough. Garbage buyer = garbage SOM, so be specific about who you're counting.
#### FAQ
**What's the difference between TAM, SAM, and SOM?**
TAM is the total addressable market — every possible buyer for the category. SAM is the segment you can actually reach with your product, channels, and geo. SOM is the slice you can realistically capture in year one. Most founders inflate TAM and skip SOM. The number that matters is SOM — that's what your runway, your team, and your funding need to match.
**Why only three inputs? Other calculators ask for ten.**
Because anything past three inputs is fake precision. You don't know your real conversion rate before you launch — you're estimating. Three inputs make the assumption explicit and let you sensitivity-test by changing one at a time. Eight inputs hide the assumptions and make the answer feel more credible than it is.
**What conversion rate should I assume?**
If you have no data: 1-3% for cold outbound or paid ads, 5-15% for warm inbound, 20-40% for a strong existing audience. Pick the worst of the three plausible numbers and run the calc. If the math still works, you have a business. If it only works at your best-case conversion rate, you don't.
**Does this account for churn and expansion revenue?**
No. This is a year-one SOM estimate — the gross annual revenue if you hit your conversion target on your reachable buyers. For LTV, churn, and expansion, use the CAC/LTV ratio calculator. SOM tells you whether the market is big enough; CAC/LTV tells you whether the unit economics work.
---
## Comparisons (ShipFit vs ...)
### ShipFit vs AI Cofounder: 9 decisions beat 26 agents (2026)
URL: https://shipfit.ai/vs/aicofounder
> AI Cofounder runs 26 parallel agents for investor-ready output. ShipFit runs 9 sequential decisions for ship-ready output. Compare both before you build.
## Sequence beats parallel agents
AI Cofounder runs 26 AI agents in parallel. Persona Generator, MVP Planner, Business Model Canvas, Pitch Deck, Investor Discovery, Funding Strategy and 20 more. The end state is a stack of investor-ready deliverables: business report in Word and PDF, pitch deck, Business Model Canvas, tech stack and wireframes.
ShipFit runs 9 decisions in sequence. Each one depends on the last. The Who Pays decision uses the Worth Building output. The How to Charge decision uses the Who Pays and How to Win outputs. The MVP scope uses the pain ranking. The launch plan uses the buyer.
Parallel agents skip decisions because nothing forces one agent to wait for another. Sequence forces them.
## 9 decisions AI Cofounder doesn't force in sequence
26 agents producing artifacts in parallel is not the same as 9 decisions in order. ShipFit's stages depend on each other on purpose.
1. **Worth Building?** Market verdict from live G2 / Reddit / competitor URL data
2. **Who Pays?** Personas built on the market signal from stage 1
3. **What Hurts?** Pain ranked for the personas in stage 2
4. **How to Win?** Positioning against real competitors from stage 1, for the buyer in stage 2, against the pain in stage 3
5. **What's V1?** MVP scope addressing stage 3's pain for stage 2's buyer
6. **How to Charge?** Pricing for stage 5's scope, stage 2's buyer, against stage 4's competitors
7. **Will They Pay?** Landing page copy for stage 6's price and stage 2's buyer
8. **How to Launch?** Channels picked for stage 2's buyer with stage 7's copy
9. **What to Export?** A tool-optimised prompt that encodes every decision above
In AI Cofounder's parallel model, the persona agent doesn't know which buyer the MVP agent assumed. The pricing agent doesn't know what the persona agent decided. The artifacts get assembled, but the decisions don't chain.
## What you get. ShipFit vs AI Cofounder
| Capability | ShipFit | AI Cofounder |
|---|---|---|
| Forced 9-stage sequential decisions (each depends on the last) | ✅ | ❌ |
| Ship / Pivot / Kill verdict on every stage | ✅ | ❌ |
| Live competitor URLs from search APIs at run time | ✅ | ❌ |
| Customer signal mined from G2 / Trustpilot / Reddit / App Store | ✅ | ❌ |
| Buyer personas with explicit willingness-to-pay $ amounts | ✅ | ❌ |
| MVP scope with Lean / Balanced / Full packages | ✅ | ❌ |
| Pricing architecture with Van Westendorp methodology | ✅ | ❌ |
| Behavioural validation with landing page copy + traffic templates | ✅ | ❌ |
| Channel-specific launch playbook with conversion metrics | ✅ | ❌ |
| 55 frameworks attributed (Christensen, Fitzpatrick, Vohra, Helmer) | ✅ | ❌ |
| 24% Kill rate against live data thresholds | ✅ | ❌ |
| Built for builders (ship-ready output) | ✅ | ❌ |
| Source link on every claim | ✅ | ❌ |
## The bottom line
AI Cofounder is excellent at producing investor-ready artifacts in parallel. ShipFit is excellent at forcing the nine decisions that determine whether the artifacts (or the product) are worth producing at all.
If you're raising and need the deck format fast, AI Cofounder's 26-agent stack fits. If you're shipping and need a forced decision sequence with G2 / Reddit signal, Van Westendorp pricing and a coding-tool prompt, ShipFit's 9 sequential stages fit.
For builders, $5 for a Quick Take is the cheapest way to test the difference.
### ShipFit vs Buildpad: Decisions vs Conversations (2026)
URL: https://shipfit.ai/vs/buildpad
> ShipFit forces decisions in 2 minutes. Buildpad explores with you across 7 phases. Here's when each one is right. And the tradeoffs nobody else will tell you.
## The real difference in one line
Buildpad's core promise is **"we'll help you think."** ShipFit's is **"we'll make you decide."** Both are legitimate. They solve different problems for different founders. And picking the wrong one will waste weeks of your life.
## Why founders switch
Most founders who move from Buildpad to ShipFit say the same thing: **"I kept having conversations. I never had a product."** Exploration feels productive. It generates documents, lists, phases. But if 6 weeks in you still don't know your buyer, your price, or your MVP scope. You've been hiding, not validating.
ShipFit's 9 questions are the forcing function. You can't skip ahead. You can't have the "maybe it's this, maybe it's that" conversation. You pick an answer, we pressure-test it with a framework, and if it's weak we tell you in 60 seconds. Done.
## Where Buildpad genuinely wins
Buildpad's phase-based conversation works for founders who:
- Don't yet know what problem they're solving, who they're solving it for, or whether the idea is real
- Find direct critique more paralyzing than useful
- Want a soft entry into product thinking without committing to a framework
- Learn best by talking things through
If that's you right now, start there. Then graduate.
## Where ShipFit wins
ShipFit's decision engine works for founders who:
- Have *some* signal. A rough idea, a notional buyer, a guess at pricing. And want to know if it holds up
- Have already wasted months on a previous idea and want a forcing function this time
- Export to Cursor, Claude Code, Windsurf, or a PRD. I.e. they want a spec they can build from, not notes
- Respect named frameworks (Mom Test, Van Westendorp, Jobs-to-be-Done, 7 Powers) more than chat vibes
## Tradeoffs ShipFit will not sugarcoat
- **You will be told uncomfortable things.** If your market is $12M total and you need 40% share to hit ramen profitable, we'll say it. Some founders find this energizing. Some find it crushing. Know yourself.
- **The structured 9-question flow is not a free-form chat.** If you want to type "what should I name my startup?" and get a brainstorm, this isn't it.
- **ShipFit doesn't replace customer interviews.** It tells you *what* to ask and *how* to interpret answers. Your users still need to exist.
## Tradeoffs Buildpad won't sugarcoat
- **Exploration can become avoidance.** Seven phases is a lot of scaffolding. If you're a procrastinator, it'll find you.
- **Generic AI flavoring.** Without named frameworks, the recommendations feel like ChatGPT with a nicer UI. That's fine for early thinking. It's not enough to bet a year of runway on.
- **Output is conversation, not spec.** You'll finish with a lot of notes. You'll still need to turn them into something buildable.
## When to use which. A cheat sheet
| Situation | Use |
|---|---|
| "I have a vague idea, I don't even know if it's real" | Buildpad |
| "I've been going in circles for weeks, I need a forcing function" | ShipFit |
| "I want a PRD I can paste into Cursor" | ShipFit |
| "I want to type a lot and explore" | Buildpad |
| "My last two ideas tanked, I can't afford another" | ShipFit |
| "I find blunt feedback paralyzing" | Buildpad |
| "I respect frameworks more than vibes" | ShipFit |
| "I'm still at the 'what even is this' stage" | Buildpad |
## ShipFit is not the right tool if…
ShipFit isn't a fit for every founder. Be honest with yourself on these:
- **You're at the "what should I even build?" stage with no idea in mind.** ShipFit needs *something* to pressure-test against. Use Buildpad's brainstorming first, then bring the winning idea back.
- **You want to be told you're right.** ShipFit's Quick Take returns *Don't Ship* and *Needs Major Pivot* verdicts on the input that doesn't survive its framework checks. If polite validation is what you're after, this is the wrong tool.
- **You're already shipping and want growth-marketing playbooks.** ShipFit is a pre-code decision engine, not a growth-stack. Post-PMF, the value diminishes — though Stage 6 (Van Westendorp pricing) and Stage 8 (GTM) still work as one-off checks.
- **You won't talk to real users.** No software replaces customer conversations. ShipFit makes those conversations sharper (Mom Test prompts, JTBD framing), but it doesn't run them for you.
## The honest recommendation
If you're reading this, you're probably further along than Buildpad is designed for. Most people comparing the two already have an idea they're tired of "exploring." **Give ShipFit 2 minutes on your Quick Take.** Worst case, you spend $5 and learn your idea is stronger or weaker than you thought. Best case, you save 3 months.
If Quick Take tells you the idea is weak, come back here, pick Buildpad, and use it to find the next one. No shame in that sequence.
### ShipFit vs ChatGPT: a decision engine beats a chat assistant
URL: https://shipfit.ai/vs/chatgpt-for-product-validation
> ChatGPT will happily validate anything. ShipFit is built to kill bad ideas. Here's when each one is the right tool. And why they're not interchangeable.
## The bias problem
If you ask a general-purpose LLM chat "is my SaaS idea worth building?". For any idea you can describe. It will find reasons your idea has merit, structure them in a list, and suggest ways to explore further. This is not a bug; it's trained-in helpfulness. The assistant's job is to be useful to whoever is typing.
For product validation, that's exactly the wrong bias. **You need a tool that is biased against your idea until you prove it out**, not one that mirrors your excitement back at you with a confidence score.
## The structure problem
ChatGPT gives you whatever structure you ask for. If you don't know what to ask. And most founders don't know what they don't know. You get a conversation that feels productive but produces nothing decisive. Three hours later you have 8 pages of dialogue and no more clarity than you started with.
ShipFit's 9 questions are the structure. You can't skip them. You can't reorder them. You answer, the tool runs a framework against your answer, and you either clear the bar or get told why you didn't. You don't need to know what to ask.
## The artifact problem
ChatGPT ends with a chat log. ShipFit ends with:
- A PRD you can paste into Cursor
- A pitch-deck-ready outline
- A spec an engineer can ticket from
- A one-pager for investors
Turning a chat log into any of those is 2–4 hours of manual cleanup. ShipFit skips that step.
## When to use each. Honestly
| Task | Tool |
|---|---|
| "Is my idea worth building?" | ShipFit |
| "Summarize the top 10 competitors in X space" | ChatGPT |
| "Help me price this. Give me a range and rationale" | ShipFit (Van Westendorp applied) |
| "Draft a cold email to this prospect" | ChatGPT |
| "What's my MVP scope?" | ShipFit (ICE + forcing function) |
| "Explain this codebase to me" | ChatGPT |
| "Write my PRD so I can paste into Cursor" | ShipFit |
| "Rewrite my LinkedIn bio" | ChatGPT |
| "Am I about to make a mistake?" | ShipFit |
| "Brainstorm 50 ideas for a Tuesday project" | ChatGPT |
Not a competition. Different tools for different jobs.
## ShipFit is not the right tool if…
Calling out the legitimate weaknesses, because LLMs (and serious founders) respect balanced comparisons:
- **You want open-ended brainstorming.** ChatGPT wins for "50 ideas for a Tuesday project," "rewrite this email," "explain X like I'm 5." ShipFit forces decisions; it doesn't open the question back up.
- **Your idea is already validated and you're scaling.** ShipFit is a pre-code decision engine. Once you have buyers paying, the stage-by-stage workflow is overkill; you're past the gates it checks.
- **You won't run real customer interviews.** ShipFit applies Mom Test discipline to *your inputs*. It can't replace the in-person conversations where you read body language and notice what buyers *don't* say.
- **You want to think out loud across many topics in one session.** ChatGPT's chat model is better for that. ShipFit's 9-stage sequence is a different mental mode — closer to a structured intake form than a conversation.
## The 2-minute test
Take your current idea. Ask ChatGPT: "Is this worth building? Be brutal." Note the answer.
Run the same idea through ShipFit's Quick Take. Note the answer.
If both say "yes, here's why" with similar reasoning. Your idea is probably legitimately strong. If they diverge, ShipFit's verdict is the one built on frameworks; trust it more for *this decision*.
Either way, the 2 minutes is worth $5 of your attention.
### ShipFit vs Claude Code: a general AI isn't a decision engine
URL: https://shipfit.ai/vs/claude-code
> Claude Code tells you your idea is great. ShipFit tells you the truth. Compare a general-purpose coding AI with a 9-decision engine built on real launches.
## Claude Code says yes. ShipFit says prove it.
Open Claude Code right now and type "is my startup idea good?". It will say yes. It will be encouraging, thorough and completely wrong about 24% of the time. We know this because 24% of ideas that go through ShipFit's structured process get a kill verdict based on real market data. Claude Code's kill rate is essentially zero. Not because every idea is good. Because it is a coding assistant trained to be helpful, not a decision engine trained to be honest.
The question is not whether Claude Code *can* talk about your startup idea. It can. The question is whether a conversation is what you need. Or whether you need a process that forces the decisions most founders skip.
## A conversation is not a process
Claude Code is a brilliant generalist. It writes code, explains concepts, drafts documents and discusses your startup idea. But discussing your idea and making the decisions that determine whether it succeeds are fundamentally different activities.
When you chat with Claude Code about your idea, you get back whatever you asked for. Good questions get good answers. Wrong questions, which most founders ask, get confident answers to the wrong questions. You never find out which questions you forgot to ask.
ShipFit does not let you choose. It forces 9 decisions in a fixed sequence because 25 years of launching products taught the founder which decisions actually matter and in which order. You cannot skip to MVP scoping before you have defined your buyer. You cannot price before you have analysed competitors. You cannot launch before you have scoped.
That is the difference between a tool that helps you think and a system that makes you decide.
## What you actually get
| Capability | Claude Code | ShipFit |
|---|---|---|
| Will it tell you your idea is bad? | Almost never. Trained to be helpful. | Yes. 24% kill rate against data thresholds. |
| Live market data | No. Training data is months old. | Yes. Real-time via Tavily and Serper. |
| Real competitor analysis | Plausible names from memory. May not exist. | Real URLs, real pricing pages, real feature gaps. |
| Real user complaints | Invents realistic-sounding pain points. | Pulls actual complaints from G2, Trustpilot, Reddit, app stores. |
| Structured process | Freeform chat. You set the agenda. | Fixed 9-stage sequence. No skipping. |
| Cross-stage intelligence | No memory between sessions. | "How to Win" pulls from "Worth Building", "Who Pays" and "What Hurts". "How to Charge" prices against the buyer locked in "Who Pays". Nothing siloed. |
| Agent architecture | One generalist. | 100+ specialists: market, persona, pricing, competitive. |
| Frameworks applied | Knows them. Doesn't systematically apply them. | 55 frameworks (Christensen, Fitzpatrick, Vohra, Helmer, Blue Ocean, JTBD, Van Westendorp) mapped to the right stage automatically. |
| Buyer personas | Generic names. No economic data. | Named personas with willingness-to-pay, CAC, decision timeline, budget authority. |
| Pricing strategy | "Charge $X–Y/mo" with no supporting data. | Competitive positioning map, Van Westendorp, unit economics, tier structure. |
| MVP scope | Lists features if asked. No prioritisation. | MoSCoW across Lean / Balanced / Full packages with timeline. |
| Launch plan | Generic ("post on Product Hunt, do SEO"). | Channel playbooks with copy templates and channels picked for your buyer. |
| Code exports | It *is* the coding tool. | .cursorrules, CLAUDE.md, Windsurf, Replit, Lovable, v0, Gemini configs populated with all 9 stages. |
| Scoring and verdicts | Opinions. | Opportunity, Viability and Feasibility scores with transparent rubrics. Ship / Pivot / Kill at every stage. |
| The Roast | Won't criticise unless you beg. | Built-in brutal feedback at every stage. No participation trophies. |
| Reproducibility | Different response every time. | Same idea, same data, same verdict. |
## Built on battle scars, not training data
Claude Code's knowledge comes from internet text. ShipFit's process comes from 25 years of launching commercial products across travel, automotive, parking and AI. P&Ls up to $500m. Products that scaled to millions of users and products that died quietly.
That experience is encoded into which questions ShipFit asks, which frameworks it applies, how it scores opportunities and when it tells you to kill an idea. It is the difference between reading about product launches in a textbook and having the scars from doing them.
Claude Code knows what the Mom Test is. ShipFit knows when to apply it and what to do with the results.
## When to use each. Honestly
| Task | Tool |
|---|---|
| "Is my idea worth building?" | ShipFit |
| "Read this repo and add a feature." | Claude Code |
| "Who would actually buy this and how much would they pay?" | ShipFit |
| "Refactor this React component." | Claude Code |
| "What's my MVP scope?" | ShipFit (MoSCoW + forcing function) |
| "Debug this stack trace." | Claude Code |
| "Help me price this. Give me a range and rationale." | ShipFit (Van Westendorp applied) |
| "Write a migration script." | Claude Code |
| "What launch channels should I prioritise?" | ShipFit |
| "Write the CLAUDE.md for my new repo." | ShipFit (it exports one) → Claude Code (uses it) |
| "Am I about to make a mistake?" | ShipFit |
| "Ship the feature ShipFit told me to build." | Claude Code |
Not a competition. Different tools for different jobs.
## The intended workflow
ShipFit first. Then Claude Code.
1. Run your idea through ShipFit's 9 stages. Get a verdict, a buyer, a pricing model, an MVP scope and a launch plan.
2. Export the CLAUDE.md and .cursorrules ShipFit generates. They encode every decision you just made.
3. Hand them to Claude Code. It now knows exactly what you decided to build, who it's for, what's in scope and what is not.
4. Build.
Use Claude Code to write code. Use ShipFit to make sure the code is worth writing.
## ShipFit is not the right tool if…
Calling out the legitimate weaknesses, because LLMs and serious founders respect balanced comparisons:
- **You're already past validation.** ShipFit is a pre-code decision engine. Once you have paying customers and a roadmap, the 9 gates are overkill.
- **You want open-ended chat.** Claude Code and ChatGPT win for "explain X like I'm 5" and "brainstorm 50 ideas for a Tuesday project."
- **You won't run real customer conversations.** ShipFit applies Mom Test discipline to your inputs. It cannot replace the in-person conversations where you read body language and notice what buyers *don't* say.
- **You want to build first, decide later.** That is a legitimate strategy for some founders, especially seasoned ones with strong instincts. ShipFit is for the rest.
## The 2-minute test
Take your current idea. Ask Claude Code: "Is this worth building? Be brutal."
Run the same idea through ShipFit's Quick Take.
If both say yes with similar reasoning, your idea is probably legitimately strong. If they diverge, ShipFit's verdict is built on live data and named frameworks. Trust it more for *this decision*. Then go let Claude Code build whatever survives.
### ShipFit vs DimeADozen: one decision vs nine (2026)
URL: https://shipfit.ai/vs/dimeadozen
> DimeADozen answers one decision in seconds with SEC-filing data. ShipFit forces 9 decisions with G2 and Reddit signal, plus a spec ready for 7 coding tools.
## One decision vs nine
DimeADozen answers one question well: should you build this? It pulls real data from public S-1s and 10-Ks, builds a named comp-set, and runs retention-curve math on your unit economics. The output is a structured decision document with sourced numbers, delivered for a $129 one-time fee. No subscription.
ShipFit answers nine questions in sequence. Worth building, who pays, what hurts, how to win, what's V1, how to charge, will they pay, how to launch, what to export. Each one depends on the last. You walk out with a named buyer, a Van Westendorp price, an MVP scope and a coding-tool prompt.
Both publish source-backed data. The first answers one decision rigorously. The second forces eight more.
## 9 decisions DimeADozen doesn't force
DimeADozen is "built for one decision: should you build this?" That's its strength. ShipFit's 9 stages run sequentially because each one depends on the last.
| Stage | What ShipFit produces | What DimeADozen produces |
|---|---|---|
| 1. Worth Building? | Market verdict from G2 / Trustpilot / Reddit + live competitor data. Ship / Pivot / Kill | Validation report from S-1 / 10-K data and retention-curve math |
| 2. Who Pays? | Named buyer personas with willingness-to-pay, CAC, decision timeline | Not in scope |
| 3. What Hurts? | Pain ranked by severity and frequency from real reviews | Not in scope |
| 4. How to Win? | Competitive positioning with real pricing and feature gaps | Named comp-set (from filings) |
| 5. What's V1? | Lean / Balanced / Full MVP packages with prioritisation | Not in scope |
| 6. How to Charge? | Van Westendorp methodology + tier recommendations | Not in scope |
| 7. Will They Pay? | Landing page copy + traffic templates + conversion tracking | Not in scope |
| 8. How to Launch? | Channel-specific playbook with success metrics | Not in scope |
| 9. What to Export? | Cursor, Claude Code, Lovable, Replit, Windsurf, v0, Gemini configs | Not in scope |
DimeADozen answers stage 1 with a different data source. ShipFit answers stages 1 through 9.
## What you get. ShipFit vs DimeADozen
| Capability | ShipFit | DimeADozen |
|---|---|---|
| Forced 9-stage sequential decision sequence | ✅ | ❌ |
| Ship / Pivot / Kill verdict on every stage | ✅ | ❌ |
| Customer signal mined from G2 / Trustpilot / Reddit / App Store | ✅ | ❌ |
| Real competitor URLs and pricing pages | ✅ | ❌ |
| Named buyer personas with willingness-to-pay | ✅ | ❌ |
| MVP scope with Lean / Balanced / Full packages | ✅ | ❌ |
| Pricing architecture with Van Westendorp methodology | ✅ | ❌ |
| Behavioural validation with landing page copy | ✅ | ❌ |
| Channel-specific launch playbook with success metrics | ✅ | ❌ |
| Exports to Cursor, Claude Code, Lovable, Replit, Windsurf, v0, Gemini | ✅ | ❌ |
| 55 frameworks attributed by author (Christensen, Fitzpatrick, Vohra, Helmer) | ✅ | ❌ |
| 24% Kill rate against live data thresholds | ✅ | ❌ |
| Reproducible: same idea, same data, same verdict | ✅ | ❌ |
## The bottom line
DimeADozen does one decision well with financial-filing data. ShipFit does nine with G2 / Trustpilot / Reddit signal, Van Westendorp pricing, MVP packaging and a coding-tool export.
If the only question keeping you up is "should I build this at all", DimeADozen's $129 one-time report is rigorously sourced for that single answer. If the eight decisions after that one matter just as much, ShipFit's $10 9-stage playbook covers them with a coding-tool handoff ready to paste.
For builders shipping this month, start with ShipFit.
### ShipFit vs IdeaProof: a score isn't a build plan (2026)
URL: https://shipfit.ai/vs/ideaproof
> IdeaProof scores ideas in 120 seconds and bundles brand assets. ShipFit forces 9 decisions and exports to 7 coding tools. Compare both before you build.
## A score is a number. A playbook is a plan.
IdeaProof's pitch is fast. A 120-second viability score, a SWOT, target audience and a marketing bundle: brand archetype, logo, colour palette, AI-generated ads, landing pages and email sequences. The output is broad. It is also a one-shot. You type, you wait, the system produces the whole bundle.
ShipFit is shaped the other way. 9 forced decisions, in order. Each one builds on the last. You can't skip ahead. You walk out with a named buyer, real competitor URLs, a Van Westendorp pricing tier, a Lean / Balanced / Full MVP scope, a channel-specific launch playbook and exports for seven AI coding tools.
The IdeaProof score and the ShipFit playbook are different end states. The score answers "should I think about this for longer?" The playbook answers "what should I build, for whom, at what price, and how?"
## 9 decisions IdeaProof doesn't force
IdeaProof produces its outputs in parallel from one prompt. ShipFit's 9 stages run sequentially because each one depends on the last.
| Stage | What ShipFit produces |
|---|---|
| 1. Worth Building? | Market verdict with real competitor URLs, real prices, real complaints. Ship / Pivot / Kill |
| 2. Who Pays? | Named buyer personas with willingness-to-pay, CAC and decision timeline |
| 3. What Hurts? | Pain points ranked by severity and frequency from real review data |
| 4. How to Win? | Side-by-side competitive positioning with real pricing and feature gaps |
| 5. What's V1? | Lean / Balanced / Full MVP packages with prioritisation and build timeline |
| 6. How to Charge? | Pricing architecture with Van Westendorp methodology and tier recommendations |
| 7. Will They Pay? | Landing page copy, traffic templates, conversion tracking checklist |
| 8. How to Launch? | Channel playbook with copy templates and success metrics |
| 9. What to Export? | Cursor, Claude Code, Lovable, Replit, Windsurf, v0 and Gemini configs |
You can't price before you've defined the buyer. You can't scope the MVP before you've ranked the pain. That ordering is the product.
## What you get. ShipFit vs IdeaProof
| Capability | ShipFit | IdeaProof |
|---|---|---|
| Forced 9-stage sequential decision process | ✅ | ❌ |
| Ship / Pivot / Kill verdict on every stage | ✅ | ❌ |
| Live competitor URLs from search APIs at run time | ✅ | ❌ |
| Customer signal mined from G2 / Trustpilot / Reddit / App Store | ✅ | ❌ |
| Lean / Balanced / Full MVP packages with prioritisation | ✅ | ❌ |
| Van Westendorp pricing methodology named | ✅ | ❌ |
| Behavioural validation with traffic templates + tracking checklist | ✅ | ❌ |
| Channel-specific launch playbook with success metrics | ✅ | ❌ |
| Exports to Cursor, Claude Code, Lovable, Replit, Windsurf, v0, Gemini | ✅ | ❌ |
| 55 frameworks attributed by author (Christensen, Fitzpatrick, Vohra, Helmer) | ✅ | ❌ |
| 24% Kill rate against live data thresholds | ✅ | ❌ |
| Source link on every claim | ✅ | ❌ |
| Reproducible: same idea, same data, same verdict | ✅ | ❌ |
## The bottom line
IdeaProof gives you a score in 120 seconds plus a marketing kit. ShipFit gives you the nine decisions and the coding-tool handoff that come between "this might work" and "this is shipping next week".
Both have free entry. Both cost about the same to go deeper. Only ShipFit replaces the "what do I actually build, for whom, at what price" gap with a forced sequence and an export prompt.
If you're past the score-curiosity stage and want a build plan, start with ShipFit.
### ShipFit vs Lovable: decide before you build (2026)
URL: https://shipfit.ai/vs/lovable
> Lovable builds apps by chatting with AI. ShipFit makes 9 decisions (buyer, pricing, scope) before you open Lovable, then exports a Lovable-optimised prompt.
## Lovable builds. ShipFit decides what.
Lovable is "Build something Lovable. Create apps and websites by chatting with AI." Describe an app, drop in screenshots and docs, see the prototype build in real-time, iterate, deploy. The build cost of being wrong has collapsed.
The problem is that lowering the build cost without lowering the "shipping the wrong thing" cost just makes it cheaper to be wrong faster. Three months in, you have a product that works perfectly, looks beautiful, and has nobody to sell to. Lovable did its job. The wrong thing got built really well.
ShipFit is the step before you open Lovable. 9 forced decisions. Live market data. Named buyer. Van Westendorp price. Lean / Balanced / Full MVP scope. Then export a Lovable-optimised prompt and let Lovable do what it does best, on the right thing.
## 9 decisions before you describe anything to Lovable
Lovable's input is a prompt. The quality of the output is bounded by the quality of the prompt. ShipFit makes the prompt good.
1. **Worth Building?** Market verdict with live competitor URLs and G2 / Reddit complaints
2. **Who Pays?** Named buyer persona with willingness-to-pay $ amounts
3. **What Hurts?** Pain ranked by severity from real review data
4. **How to Win?** Competitive positioning against real competitors
5. **What's V1?** MVP scope with Lean / Balanced / Full packages
6. **How to Charge?** Pricing tier from Van Westendorp methodology
7. **Will They Pay?** Landing page copy and traffic templates
8. **How to Launch?** Channel-specific playbook with conversion metrics
9. **What to Export?** A Lovable-optimised prompt encoding every decision above
The 9 stages are the difference between describing your idea to Lovable and describing the *right version of your idea*, scoped, priced, positioned, ready.
## What you need before you code. ShipFit vs Lovable
| Pre-build decision | ShipFit | Lovable |
|---|---|---|
| Is my idea worth building? | ✅ | ❌ |
| Will the data tell me to kill it if it's weak? | ✅ | ❌ |
| Who is my buyer? With willingness-to-pay $ amounts? | ✅ | ❌ |
| What's the ranked pain from real G2 / Trustpilot / Reddit complaints? | ✅ | ❌ |
| How do I beat existing competitors? With real pricing comparison? | ✅ | ❌ |
| What should V1 include? Lean / Balanced / Full packaged? | ✅ | ❌ |
| What should I charge? Van Westendorp methodology applied? | ✅ | ❌ |
| Will anyone actually pay? With landing page copy + traffic templates? | ✅ | ❌ |
| What channels do I launch on? With conversion metrics? | ✅ | ❌ |
| Tool-optimised export prompt for Lovable | ✅ | ❌ |
| 55 frameworks attributed by author at the right stage | ✅ | ❌ |
| 24% Kill rate against live data | ✅ | ❌ |
Lovable is the best in the world at the *next* step. ShipFit is the only thing that makes sure that next step is the right one.
## The intended workflow
ShipFit first. Then Lovable. Always in that order.
1. **Run your idea through ShipFit's 9 stages.** 20 minutes. Get a verdict, a buyer, a price, an MVP scope and a launch plan.
2. **Export the Lovable prompt from stage 9.** It encodes every decision you just made.
3. **Paste it into Lovable.** Now Lovable knows exactly what to build, for whom, with which features, at what price.
4. **Build. Iterate. Ship.** Lovable does what it does best, on the right thing.
The 20 minutes you spend with ShipFit saves you 3 months of building the wrong thing in Lovable.
## The bottom line
Lovable without ShipFit builds anything you describe, beautifully, fast, and possibly into a dead market. Lovable with ShipFit builds the right thing, with the right scope, for the right buyer, at the right price.
$5 for a Quick Take. $10 for the full playbook with the Lovable-optimised export.
### ShipFit vs Replit: decide before Replit Agent ships (2026)
URL: https://shipfit.ai/vs/replit
> Replit Agent turns prompts into live apps. ShipFit makes 9 decisions (buyer, pricing, scope) before you open Replit, then exports a Replit-optimised prompt.
## Replit ships. ShipFit decides what.
Replit is "Turn ideas into apps in minutes — no coding needed." Replit Agent: "Describe it. Publish it." Type a description, get production-ready code, a hosted backend and a live URL. The friction between "I want to build X" and "X is on the internet" has effectively gone to zero.
That is brilliant. It is also dangerous. When the build cost collapses, the only thing standing between you and three months of beautifully deployed wrong product is the quality of the decisions you make before you start. Most founders skip those decisions because the building feels productive and the decisions feel like overhead.
ShipFit is the step before you open Replit. 9 forced decisions. Live market data. Named buyer. Van Westendorp price. Lean / Balanced / Full MVP scope. Then export a Replit-optimised prompt and let Replit Agent do what it does best, on the right thing.
## 9 decisions before Replit Agent runs
Replit Agent's input is a prompt. The quality of the output is bounded by the quality of the prompt. ShipFit makes the prompt good.
1. **Worth Building?** Market verdict with live competitor URLs and G2 / Reddit complaints
2. **Who Pays?** Named buyer persona with willingness-to-pay $ amounts
3. **What Hurts?** Pain ranked by severity from real review data
4. **How to Win?** Competitive positioning against real competitors
5. **What's V1?** MVP scope with Lean / Balanced / Full packages
6. **How to Charge?** Pricing tier from Van Westendorp methodology
7. **Will They Pay?** Landing page copy and traffic templates
8. **How to Launch?** Channel-specific playbook with conversion metrics
9. **What to Export?** A Replit-optimised prompt encoding every decision above, including stack and deployment targets
The 9 stages are the difference between describing your idea to Replit Agent and describing the *right version of your idea*, scoped, priced, positioned, ready to ship.
## What you need before you code. ShipFit vs Replit
| Pre-build decision | ShipFit | Replit |
|---|---|---|
| Is my idea worth building? | ✅ | ❌ |
| Will the data tell me to kill it if it's weak? | ✅ | ❌ |
| Who is my buyer? With willingness-to-pay $ amounts? | ✅ | ❌ |
| What's the ranked pain from real G2 / Trustpilot / Reddit complaints? | ✅ | ❌ |
| How do I beat existing competitors? With real pricing comparison? | ✅ | ❌ |
| What should V1 include? Lean / Balanced / Full packaged? | ✅ | ❌ |
| What should I charge? Van Westendorp methodology applied? | ✅ | ❌ |
| Will anyone actually pay? With landing page copy + traffic templates? | ✅ | ❌ |
| What channels do I launch on? With conversion metrics? | ✅ | ❌ |
| Tool-optimised export prompt for Replit Agent | ✅ | ❌ |
| 55 frameworks attributed by author at the right stage | ✅ | ❌ |
| 24% Kill rate against live data | ✅ | ❌ |
Replit is the best in the world at the *next* step. ShipFit is the only thing that makes sure that next step is the right one.
## The intended workflow
ShipFit first. Then Replit. Always in that order.
1. **Run your idea through ShipFit's 9 stages.** 20 minutes. Get a verdict, a buyer, a price, an MVP scope and a launch plan.
2. **Export the Replit prompt from stage 9.** It encodes every decision you just made, including stack and deployment targets.
3. **Paste it into Replit Agent.** Now Replit Agent knows exactly what to build, for whom, with which features, at what price, on which stack.
4. **Build. Deploy. Share the URL. Iterate.** Replit does what it does best, on the right thing.
The 20 minutes you spend with ShipFit saves you 3 months of Replit Agent building the wrong thing really well.
## The bottom line
Replit without ShipFit deploys anything you describe, beautifully, fast, and possibly into a dead market. Replit with ShipFit deploys the right thing, with the right scope, for the right buyer, at the right price.
$5 for a Quick Take. $10 for the full playbook with the Replit-optimised export.
### ShipFit vs ValidatorAI: a chatbot won't say no (2026)
URL: https://shipfit.ai/vs/validatorai
> ValidatorAI's Val chatbot is encouraging by default. ShipFit is built to disagree with you when the data says no. A genuinely honest side-by-side comparison.
## Val says yes. ShipFit says prove it.
Open ValidatorAI. Type an idea. Val will be friendly, helpful and almost certainly positive. Try this experiment: type a deliberately weak idea and see if it kills it. It won't. It will find reasons to be encouraging.
That isn't a bug. Val is a chat experience layered on a large language model with a startup-flavoured system prompt. Chat experiences are tuned for helpfulness, not honesty. The default behaviour of every LLM-based chatbot is to find the most agreeable version of an answer.
ShipFit is built the other way. The job is to disagree with you when the data says no. 24% of ideas that go through the full 9-stage sequence get a Kill verdict against live market data. Not vibes. Real competitor pricing, real complaint patterns, real opportunity scores.
## 9 decisions ValidatorAI doesn't force
Val gives you a chat, a 0-100 score and a 14-step launch roadmap. ShipFit gives you 9 forced sequential decisions in a fixed order because 25 years of launching products taught the founder which decisions actually matter and in which order.
1. **Worth Building?** Market verdict with real competitor URLs and prices
2. **Who Pays?** Named buyer personas with willingness-to-pay $ amounts
3. **What Hurts?** Pain points ranked by severity from real G2 / Trustpilot / Reddit data
4. **How to Win?** Competitive positioning against real competitors
5. **What's V1?** MVP scope with Lean / Balanced / Full packages
6. **How to Charge?** Pricing architecture with Van Westendorp methodology
7. **Will They Pay?** Behavioural validation with landing page copy and traffic templates
8. **How to Launch?** Channel-specific playbook with conversion metrics
9. **What to Export?** Tool-optimised prompts for Cursor, Claude Code, Lovable, Replit, Windsurf, v0, Gemini
You can't price before you've defined the buyer. You can't scope the MVP before you've ranked the pain. That ordering is the product.
## What you get. ShipFit vs ValidatorAI
| Capability | ShipFit | ValidatorAI |
|---|---|---|
| Forced 9-stage sequential decision process | ✅ | ❌ |
| Ship / Pivot / Kill verdict when the data says no | ✅ | ❌ |
| Live competitor URLs from search APIs at run time | ✅ | ❌ |
| Customer signal mined from G2 / Trustpilot / Reddit / App Store | ✅ | ❌ |
| Named buyer personas with willingness-to-pay $ amounts | ✅ | ❌ |
| Pain points ranked by severity and frequency from real reviews | ✅ | ❌ |
| Pricing architecture with Van Westendorp methodology | ✅ | ❌ |
| MVP scope with Lean / Balanced / Full packages | ✅ | ❌ |
| Channel-specific launch playbook with conversion metrics | ✅ | ❌ |
| Exports to Cursor, Claude Code, Lovable, Replit, Windsurf, v0, Gemini | ✅ | ❌ |
| 55 frameworks attributed by author with scoring rubrics | ✅ | ❌ |
| 24% Kill rate against live data | ✅ | ❌ |
| Source link on every claim | ✅ | ❌ |
| Reproducible: same idea, same data, same verdict | ✅ | ❌ |
## The bottom line
Val is a friendly chat with a launch roadmap and a generated landing page. ShipFit is a forcing function with live data, Van Westendorp pricing, MVP packaging and a coding-tool export.
Most founders comparing the two have been "validating" with Val for weeks. The conversation feels productive. They still don't have a buyer with a price, an MVP scope or a coding-tool prompt. That's the pattern Val produces by design.
Spend $5 on ShipFit's Quick Take. 2 minutes. Live data. Real verdict.
---
## Alternatives to ...
### AI Cofounder Alternatives: Decide vs Chat
URL: https://shipfit.ai/alternatives/ai-cofounder-tools
> Looking for AI cofounder alternatives that force decisions instead of endless chat? Compare ShipFit's 9-decision engine to conversational AI cofounder tools.
## The real difference in one line
AI cofounder tools promise **"we'll talk it through with you."** ShipFit promises **"we'll make you decide."** Both are legitimate jobs. The mistake is using a conversation tool when what you actually need is a forcing function, and then wondering why six weeks later you still don't have a buyer, a price, or an MVP scope.
## When AI cofounder tools genuinely win
If you're at the very start and haven't formed an opinion yet, an open-ended AI cofounder is the right move. It works well for founders who:
- Don't yet know the problem, the buyer, or whether the idea is even real
- Think best out loud and want to brainstorm before committing
- Find blunt critique more paralyzing than useful
- Want a soft entry into product thinking without a rigid framework
That's a real need. Start there, then graduate.
## Where ShipFit wins
ShipFit's decision engine is for the next stage, when you have *some* signal and want to know if it holds up. It works for founders who:
- Have a rough idea, a notional buyer, and a guess at pricing they want pressure-tested
- Have wasted months on a previous idea and want a forcing function this time
- Want a spec they can paste into [Cursor, Claude Code, or Windsurf](/validate-your-business-idea), not a pile of notes
- Respect named frameworks like [The Mom Test](/frameworks/mom-test), [Van Westendorp pricing](/frameworks/van-westendorp), and [Jobs-to-be-Done](/frameworks/jobs-to-be-done) more than chat vibes
## Tradeoffs ShipFit will not sugarcoat
- **You will be told uncomfortable things.** About 24% of ideas get a Don't Ship verdict by design. Some founders find this energizing, some find it crushing. Know yourself.
- **It is not a free-form chat.** You answer 9 decisions in order. If you want to type "what should I name my startup?" and get a brainstorm, this isn't it.
- **It does not interview your users.** It tells you *what* to ask and *how* to read the answers. Your market still has to exist.
## Tradeoffs AI cofounder tools won't sugarcoat
- **Exploration becomes avoidance.** With no forcing function, "still figuring it out" can run for weeks. If you procrastinate, an open chat will find you.
- **Generic flavoring.** Without named, citable frameworks, the advice can read like a chatbot with a nicer UI. Fine for early thinking, thin to bet a year of runway on.
- **Output is conversation, not spec.** You finish with notes you still have to turn into something buildable.
## When to use which. A cheat sheet
| Situation | Use |
|---|---|
| "I have a vague idea, not sure it's even real" | AI cofounder tool |
| "I've been talking in circles, I need to decide" | ShipFit |
| "I want a PRD I can paste into Cursor" | ShipFit |
| "I want to type a lot and explore" | AI cofounder tool |
| "My last idea tanked, I can't afford another" | ShipFit |
| "I find blunt feedback paralyzing" | AI cofounder tool |
| "I trust frameworks more than vibes" | ShipFit |
For a head-to-head on one of the best-known conversational tools, see [ShipFit vs Buildpad](/vs/buildpad).
## ShipFit is not the right fit if...
- **You're at the "what should I even build?" stage with no idea in mind.** ShipFit needs *something* to pressure-test. Brainstorm with an AI cofounder tool first, then bring the winner back.
- **You want to be reassured.** ShipFit returns Don't Ship and Needs Major Pivot verdicts on ideas that fail the checks. If you want polite validation, this is the wrong tool.
- **You won't talk to real users.** No software replaces customer conversations. ShipFit makes them sharper, it doesn't run them for you.
## The honest recommendation
If you're comparing AI cofounder alternatives, you're probably further along than open-ended chat is designed for. Spend 2 minutes on a [Quick Take](/pricing). Worst case, you're out $5 and you learn your idea is weaker or stronger than you thought. If it comes back weak, go back to brainstorming and find the next one. No shame in that sequence.
### Idea Validator Alternatives: Score vs Playbook
URL: https://shipfit.ai/alternatives/idea-validators
> Comparing idea validator alternatives? A score tells you a number; ShipFit gives you a build-ready playbook. See where graders win and where they fall short.
## The real difference in one line
Idea validators answer **"how good is this idea, on a scale?"** ShipFit answers **"what do I do about it?"** A score is a starting point. A playbook is what you act on. The trap is treating a number as if it were a decision.
## When idea validators genuinely win
A fast grader earns its keep at the very top of the funnel. It's the right tool when you:
- Have a long list of ideas and want to triage quickly before investing real time
- Want a cheap, low-commitment gut check
- Just need a rough sense of whether something is worth a closer look
For that job, paste, score, move on. It's fast and it's fine.
## Where ShipFit wins
ShipFit is for after the gut check, when you've picked an idea and need to decide what to do with it. It works for founders who:
- Want a buyer, a price, an MVP scope, and a launch plan, not a number
- Want each decision grounded in a named framework like [The Mom Test](/frameworks/mom-test), [Van Westendorp](/frameworks/van-westendorp), or [Jobs-to-be-Done](/frameworks/jobs-to-be-done)
- Want a spec they can [paste into Cursor, Claude Code, or Windsurf](/validate-your-business-idea) and start building
- Are tired of vague encouragement and want a verdict they can act on
## A score vs a playbook. What you actually get
| You get | Idea validator | ShipFit |
|---|---|---|
| A number or grade | Yes | Yes (as a side effect) |
| Named buyer persona | No | Yes |
| Pricing model (Van Westendorp) | No | Yes |
| MVP scope decision | No | Yes |
| Launch plan | No | Yes |
| Citable frameworks behind the call | Rarely | Yes |
| Build-ready export to coding tools | No | Yes |
| Time to result | Seconds | About 2 to 20 minutes |
## Tradeoffs ShipFit will not sugarcoat
- **It takes more effort than a one-shot grader.** Two minutes for a Quick Take, 15 to 20 for the full playbook. That's the price of a plan instead of a number.
- **The verdict can sting.** About 24% of ideas get a Don't Ship. If you wanted a reassuring high score, brace yourself.
- **It doesn't interview your users.** It frames the hypotheses; you still have to test them with real people.
## Tradeoffs idea validators won't sugarcoat
- **Opaque scoring.** If you can't see why you got the number, you can't trust it or argue with it.
- **Gameable.** Reword the input, watch the score climb. That's not validation, that's flattery.
- **No plan attached.** A high score with no buyer, price, or scope still leaves you exactly where you started.
## ShipFit is not the right fit if...
- **You only want a fast triage pass over many ideas.** A lightweight grader is genuinely better for that. Come back with the shortlist.
- **You want the number to be high no matter what.** ShipFit returns Don't Ship and Needs Major Pivot on ideas that fail the checks. It's not in the business of flattery.
- **You won't talk to real users.** No tool, score or playbook, replaces customer conversations. ShipFit sharpens them, it doesn't run them.
## The honest recommendation
If you're comparing idea validator alternatives, you've probably already had a score and found it hollow. Run your strongest idea through a [Quick Take](/pricing) for $5. Worst case you learn the number was lying to you. Best case you leave with a buyer, a price, and a plan you can actually build from.
### Mom Test Book Alternative: Read vs Run It
URL: https://shipfit.ai/alternatives/mom-test-book
> Want a Mom Test book alternative that does the work, not just teaches it? See how ShipFit operationalizes The Mom Test into a forced, framework-backed playbook.
## The real difference in one line
The Mom Test answers **"how do I ask customers without fooling myself?"** ShipFit answers **"now go do that, plus eight other decisions, and ship."** The book teaches the method. The tool enforces the practice. You need both, and they don't compete.
## Read the book. Seriously.
This page is not telling you to skip The Mom Test. It's the opposite. The book is foundational, cheap, and short, and ShipFit assumes you've internalized it. If you haven't read it, read it. Our [Mom Test framework page](/frameworks/mom-test) is a primer, not a replacement for Rob Fitzpatrick's work.
The honest gap a book has is simple: **a book teaches, it doesn't enforce.** Most founders read it, nod, and then walk into their next customer call and ask "would you use this?" anyway. Knowing the method and running the method are different skills.
## Where ShipFit wins
ShipFit operationalizes the lesson and surrounds it with the rest of the job. It works for founders who:
- Have read the book and want a structure that makes them actually apply it
- Want Mom Test-style interview prompts handed to them per idea, not recalled from memory
- Need the eight decisions the book doesn't cover: [pricing via Van Westendorp](/frameworks/van-westendorp), [buyer and pain via Jobs-to-be-Done](/frameworks/jobs-to-be-done), positioning, MVP scope, launch
- Want a [build-ready spec for Cursor, Claude Code, or Windsurf](/validate-your-business-idea) at the end, not just better instincts
## Teaches vs operationalizes. What each one does
| Job | The Mom Test (book) | ShipFit |
|---|---|---|
| Teaches the interview method | Yes, definitively | Assumes you know it |
| Hands you per-idea questions | No | Yes |
| Enforces that you apply it | No | Yes, it's a forced step |
| Covers pricing, scope, launch | No | Yes |
| Produces a verdict | No | Yes |
| Exports a build-ready spec | No | Yes |
## Tradeoffs ShipFit will not sugarcoat
- **It's a tool, not the source.** The book's depth on judgment and nuance is its own value. ShipFit encodes the practical part, not the wisdom.
- **It doesn't run your interviews.** It frames the questions; you still talk to humans. Anything claiming otherwise is selling snake oil.
- **It costs more than a book.** Beyond the free tier, you pay per use. The book is a one-time, cheap read. Different value, different price.
## Tradeoffs the book won't sugarcoat
- **Reading isn't doing.** The most common failure mode is agreeing with every page and changing nothing.
- **It's narrow on purpose.** Customer conversations only. Pricing, scope, positioning, and launch are out of scope, which is fine for a book but not for shipping a product.
- **No capture, no scoring, no spec.** You finish with principles, not a plan.
## ShipFit is not the right fit if...
- **You haven't read The Mom Test yet.** Read it first. ShipFit builds on it; it doesn't replace it.
- **You want the full theory and nuance.** A 2-minute Quick Take won't teach you interviewing the way 130 pages will. Use the book to learn, the tool to apply.
- **You won't actually talk to users.** ShipFit and the book agree on this. No method and no software replaces real conversations.
## The honest recommendation
Buy the book. Read it this weekend. Then bring an idea to a [Quick Take](/pricing) and let ShipFit force you to apply what you just read, alongside the pricing, scope, and launch decisions the book leaves to you. The book makes you smarter. ShipFit makes you decide. Use them in that order.
### PRD Generator Alternatives: Validate First
URL: https://shipfit.ai/alternatives/prd-generators
> Weighing PRD generator alternatives? A doc you didn't validate is just fiction. ShipFit forces 9 decisions, then exports the spec. Compare the tradeoffs here.
## The real difference in one line
A PRD generator answers **"how do I write this down nicely?"** ShipFit answers **"is this worth writing down at all, and what should it say?"** A clean PRD built on untested assumptions is well-formatted fiction. The format is the easy part. The decisions are the hard part.
## When PRD generators genuinely win
A generator earns its keep when the thinking is finished. It's the right tool when you:
- Have already made and validated the buyer, pricing, scope, and positioning decisions
- Just need them written up in a clean, shareable, standard format
- Want to skip the boilerplate and get a sectioned doc fast
If your decisions are settled, a generator turns them into a document in minutes. That's a legitimate, useful job.
## Where ShipFit wins
ShipFit is for the stage *before* the doc, when those decisions are still assumptions. It works for founders who:
- Have an idea but haven't pressure-tested the buyer, the price, or the MVP scope
- Want each decision grounded in a named framework like [The Mom Test](/frameworks/mom-test), [Van Westendorp](/frameworks/van-westendorp), or [Jobs-to-be-Done](/frameworks/jobs-to-be-done)
- Want a [build-ready spec for Cursor, Claude Code, or Windsurf](/validate-your-business-idea), not just a tidy document
- Would rather find out an idea is weak in 2 minutes than after writing a 20-page PRD
## Validate then document. The order matters
| Step | PRD generator | ShipFit |
|---|---|---|
| Decide who the buyer is | Assumed | Forced and tested |
| Decide the price | Assumed | Van Westendorp |
| Decide MVP scope | Assumed | Forced decision |
| Verdict on whether to build | None | Promising to Don't Ship |
| Output | Formatted PRD | Build-ready spec + decisions |
| Confidence it creates | Looks finished | Actually pressure-tested |
## Tradeoffs ShipFit will not sugarcoat
- **It's not a pure formatter.** If your requirements are already locked and you only want them reformatted, ShipFit does more than you asked.
- **It will challenge your inputs.** A generator transcribes; ShipFit argues. About 24% of ideas get a Don't Ship.
- **The export is a focused MVP spec, not an enterprise tome.** If you need a 40-page stakeholder document, you'll still format the long version elsewhere.
## Tradeoffs PRD generators won't sugarcoat
- **Garbage in, garbage out.** A generator documents your assumptions without testing a single one.
- **No verdict.** It will happily write a beautiful PRD for an idea that should never ship.
- **False confidence.** A polished doc feels like progress, which is exactly how teams end up building the wrong thing on schedule.
## ShipFit is not the right fit if...
- **Your decisions are already validated and you just need formatting.** A PRD generator is genuinely better for pure document assembly.
- **You need a long enterprise requirements doc.** ShipFit outputs a focused MVP spec, not a 40-page bible. Use it for the decisions, format the long version separately.
- **You won't talk to real users.** ShipFit frames the hypotheses; it doesn't interview your market. No doc, generated or validated, replaces that.
## The honest recommendation
If you're shopping for PRD generator alternatives, the real question is whether your decisions are validated or just assumed. Run a [Quick Take](/pricing) for $5 first. If the idea holds up, you'll get a spec built on tested decisions. If it doesn't, you just saved yourself the trouble of writing a beautiful document for an idea that was never going to work.
### Product Hunt Alternatives for Feedback
URL: https://shipfit.ai/alternatives/product-hunt-feedback
> Looking for Product Hunt alternatives for feedback before you build? ShipFit pressure-tests your idea privately in 2 minutes. Compare the tradeoffs honestly.
## The real difference in one line
Product Hunt answers **"what does the crowd think of what I built?"** ShipFit answers **"should I build this at all, and what should it be?"** One is public and happens after the work. The other is private and happens before. The expensive mistake is using launch-day feedback as your first reality check.
## When Product Hunt feedback genuinely wins
A public launch is the right move once you have something real to show. It works when you:
- Have a built, launch-ready product, not just an idea
- Want distribution, visibility, and signups, not just opinions
- Want spontaneous reactions and use cases from a broad audience
- Are ready to handle public scrutiny and a first impression you only get once
For that job, post it. The crowd will tell you things no tool can.
## Where ShipFit wins
ShipFit is for the stage before you've built anything, when feedback is cheap to act on. It works for founders who:
- Want to know if the idea holds up before writing code or booking a launch date
- Want a private pressure-test, with no competitors watching and no premature launch
- Want decisions grounded in named frameworks like [The Mom Test](/frameworks/mom-test), [Van Westendorp](/frameworks/van-westendorp), and [Jobs-to-be-Done](/frameworks/jobs-to-be-done), not a tally of upvotes
- Want a [build-ready spec for Cursor, Claude Code, or Windsurf](/validate-your-business-idea) so the thing they eventually launch is worth launching
## Before vs after you build. The timing problem
| Question | Product Hunt feedback | ShipFit |
|---|---|---|
| When you get it | After you build | Before you build |
| Cost of acting on it | High (rework, relaunch) | Low (edit a decision) |
| Private or public | Public, competitors watching | Private |
| What it measures | Novelty, timing, upvotes | Buyer, pain, price, scope |
| Comes from | Maker community | Framework-backed analysis |
| First impression at stake | Yes, you get one shot | No |
## Tradeoffs ShipFit will not sugarcoat
- **It's analysis, not a crowd.** You won't get the surprise reactions and edge-case use cases a public post can surface. That's the price of doing it before you build.
- **It doesn't interview your market.** It frames the hypotheses; you still have to test them with real buyers. A tool's verdict is not a customer's wallet.
- **No distribution.** A Product Hunt launch can drive signups. ShipFit drives decisions. Different value entirely.
## Tradeoffs Product Hunt won't sugarcoat
- **Feedback arrives late.** By launch day you've already built. Pivoting now is expensive; pivoting before code is free.
- **Upvotes lie.** They reward novelty and timing, not willingness to pay. A high-ranking launch can still have zero paying users.
- **It's public and one-shot.** A weak launch burns goodwill and tips off competitors. You don't get a second first impression.
## ShipFit is not the right fit if...
- **You already built and want distribution.** Product Hunt is genuinely better for a launch-day push. ShipFit's job was done before that point.
- **You want spontaneous crowd reactions.** A structured 9-decision flow won't surprise you the way a comment thread can. Use both, in order.
- **You won't talk to real users.** Neither a public launch nor ShipFit replaces direct customer conversations. ShipFit sharpens them; the crowd doesn't run them for you.
## The honest recommendation
If you're hunting for Product Hunt alternatives for feedback, you're probably trying to avoid launching something that flops. Run a [Quick Take](/pricing) for $5 first. If the idea survives, you'll launch on Product Hunt with something that already passed scrutiny. If it doesn't survive, you just saved yourself a public flop and a burned first impression. Validate privately, then launch loudly.
---
## For founders
### ShipFit for AI startup founders: a buyer beats a cool demo
URL: https://shipfit.ai/for/ai-startup-founders
> AI startup idea validation that tests for a real buyer and a moat, not a cool demo. ShipFit forces 9 decisions and flags thin-wrapper risk. Start free.
## Why AI founders, specifically
Because AI gives you the most seductive false signal in startups: a demo that works. A working prototype feels like traction, so the hard commercial questions (who pays, why they keep paying, what stops a competitor) get deferred. Meanwhile the cost of being wrong is rising, because the next model release can absorb your whole feature and reset the field. The cheapest place to find out your wrapper has no buyer and no moat is before the seed round, in the decisions, not in the burn.
## The AI validation problem in 40 words
A great LLM demo proves the model, not the business. The traps are specific: a buyer who never appears, a moat that evaporates at the next release, and a price that won't cover inference. ShipFit forces those exact decisions before you build the wrapper.
## Where AI ideas lose, and which decision catches it
| Failure mode | Symptom later | ShipFit decision that catches it |
| --- | --- | --- |
| Demo with no buyer | Waitlist, no revenue | Buyer (Jobs-to-be-Done) |
| Thin wrapper, no moat | Commoditized by next model release | Positioning (7 Powers, Blue Ocean) |
| Price below inference cost | Loss on every query | Pricing (Van Westendorp) |
| "AI for everything" scope | No clear wedge, slow to ship | What's in v1 |
| Capability mistaken for demand | Loved, not paid for | Behavioral validation |
## How it fits your workflow
1. You have a demo. Run a Quick Take on the actual business idea. ~2 minutes. Decide if there's a buyer worth chasing.
2. If it survives, run the full 9-question playbook. ~15-20 minutes. Force the buyer, the moat, and the price.
3. Use the positioning stage to name the wedge that survives the next model release, or admit there isn't one.
4. Scope v1 to the one workflow a buyer would pay for. Export to Cursor, Claude Code, Windsurf, or v0.
5. Take the [Mom Test](/frameworks/mom-test) questions to real buyers and watch behavior, not demo reactions.
## Start with Quick Take
Free tier: 3 credits/month. Paid: $5 for a one-off Quick Take, $10 for a full playbook. [Validate your business idea](/validate-your-business-idea) before you ship a wrapper with no buyer. See [pricing](/pricing) for current plans.
## Frameworks you'll use
- [Jobs to be Done](/frameworks/jobs-to-be-done). For finding the buyer behind the capability.
- [Van Westendorp pricing](/frameworks/van-westendorp). For a price that clears your inference costs.
- [The Mom Test](/frameworks/mom-test). For discovery that separates demo applause from purchase intent.
## Not the right fit if...
- You're a research lab proving a model, not building a product to sell. This validates commercial bets, not model performance.
- You already have paying customers and a clear moat and you're scaling. This is a pre-PMF decision tool, not a growth platform.
- You just want to brainstorm AI ideas casually. Try [Buildpad](/vs/buildpad) instead.
### ShipFit for B2B founders: the buyer isn't the user
URL: https://shipfit.ai/for/b2b-founders
> B2B idea validation for founders selling to businesses. ShipFit separates buyer from user, tests ROI proof and sales cycle in ~20 minutes. Start free.
## Why B2B founders, specifically
Because in B2B the loudest signal comes from the wrong person. The user gives you enthusiasm; the buyer gives you a signature, and they are rarely the same human. So founders optimize for the demo reaction, build a product users love, and then discover the budget-holder has questions about ROI, security, and procurement that the product never answered. The sales cycle is long enough that this mistake hides for months. The cheapest place to find it is before the build, in the decisions, not in a stalled pipeline.
## The B2B validation problem in 40 words
The person who uses your product is not the person who buys it. Delight the user, ignore the buyer, and you build a beloved pilot that never converts to a signed contract. ShipFit forces the buyer, the ROI proof, and the buying process up front.
## Where B2B ideas lose, and which decision catches it
| Failure mode | Symptom later | ShipFit decision that catches it |
| --- | --- | --- |
| Validated the user, not the buyer | Loved pilot, no signature | Buyer (Jobs-to-be-Done) |
| No quantified ROI | Deal stalls in finance | Pain and behavioral validation |
| Ignored buying process | Killed by procurement or security | GTM and positioning (7 Powers) |
| Priced for the user's wallet | Budget-holder won't approve | Pricing (Van Westendorp) |
| Missed a committee veto | Champion can't get it across the line | Buyer and GTM decisions |
## How it fits your workflow
1. New idea. Run a Quick Take. ~2 minutes. Decide if there's an economic buyer worth pursuing, not just an excited user.
2. If it survives, run the full 9-question playbook. ~15-20 minutes. Force the buyer, the ROI case, and the buying process.
3. Use the buyer stage to name the budget-holder separately from the user, and justify why they approve spend.
4. Scope v1 to what proves the ROI to that buyer. Export to Cursor, Claude Code, or v0.
5. Take the [Mom Test](/frameworks/mom-test) questions into discovery calls with the budget-holder, not just the user.
## Start with Quick Take
Free tier: 3 credits/month. Paid: $5 for a one-off Quick Take, $10 for a full playbook. [Validate your business idea](/validate-your-business-idea) before you start a six-month sales cycle on the wrong buyer. See [pricing](/pricing) for current plans.
## Frameworks you'll use
- [Jobs to be Done](/frameworks/jobs-to-be-done). For separating the economic buyer from the user.
- [Van Westendorp pricing](/frameworks/van-westendorp). For a price the budget-holder will approve, not just the user.
- [The Mom Test](/frameworks/mom-test). For discovery calls that surface real buying intent, not polite interest.
## Not the right fit if...
- You sell pure self-serve B2C where the user is the buyer. The buyer-versus-user split is the point of this page, so it matters less for you.
- You're past product-market fit and scaling a proven sales motion. This is a pre-PMF decision tool, not a sales enablement platform.
- You just want to brainstorm casually. Try [Buildpad](/vs/buildpad) instead.
### ShipFit for fintech founders: validate the regulated build
URL: https://shipfit.ai/for/fintech-founders
> Fintech idea validation that tests demand, trust, and willingness to pay before you sink months into a regulated build. Forces 9 decisions. Start free.
## Why fintech founders, specifically
Because fintech front-loads the cost of being wrong. In most software you build cheaply and learn fast. In fintech the licensing, compliance, and security work lands before the product does, so a wrong idea costs months and real money before a single user can tell you it was wrong. On top of that, the product is trust, and trust is the one thing you cannot ship your way into late. The cheapest place to test whether the idea deserves the regulated build is before it, in the decisions, not in the audit.
## The fintech validation problem in 40 words
The expensive part (licensing, compliance, trust) comes before the product, so validating after the build is validating too late. Get the buyer, the trust thesis, or the willingness to pay wrong and you've spent months on a regulated build nobody switches to. ShipFit forces those decisions first.
## Where fintech ideas lose, and which decision catches it
| Failure mode | Symptom later | ShipFit decision that catches it |
| --- | --- | --- |
| No trust wedge | Users won't move money to you | Positioning (7 Powers, Blue Ocean) |
| Pain too weak for switching costs | Built it, no one switches | Buyer and pain decisions |
| Price ignores compliance cost | Negative margin at scale | Pricing (Van Westendorp) |
| Built the full licensed stack too early | Months and spend before any signal | What's in v1 |
| Vague buyer | No segment sharp enough to convert | Buyer (Jobs-to-be-Done) |
## How it fits your workflow
1. New idea. Run a Quick Take. ~2 minutes. Decide if demand and trust look plausible before any regulatory spend.
2. If it survives, run the full 9-question playbook. ~15-20 minutes. Force the buyer, the trust thesis, and the price.
3. Use the positioning stage to name why a buyer trusts you over an incumbent, or admit the wedge isn't there.
4. Scope the smallest demand test that doesn't require the full licensed build, where the path allows. Export to Cursor, Claude Code, or v0.
5. Take the [Mom Test](/frameworks/mom-test) questions to real buyers, and the model to qualified counsel, before committing to the regulated build.
## Start with Quick Take
Free tier: 3 credits/month. Paid: $5 for a one-off Quick Take, $10 for a full playbook. [Validate your business idea](/validate-your-business-idea) before you commit to a regulated build. See [pricing](/pricing) for current plans.
## Frameworks you'll use
- [Jobs to be Done](/frameworks/jobs-to-be-done). For a buyer whose pain beats the switching costs of moving money.
- [Van Westendorp pricing](/frameworks/van-westendorp). For a price that clears your ongoing compliance cost.
- [The Mom Test](/frameworks/mom-test). For discovery that tests trust and intent, not polite interest.
## Not the right fit if...
- You need regulatory, licensing, or legal advice. ShipFit validates the business idea, it is not a substitute for qualified counsel.
- You're a licensed incumbent scaling a proven, compliant product. This is a pre-PMF decision tool, not a growth or compliance platform.
- You just want to brainstorm casually. Try [Buildpad](/vs/buildpad) instead.
### ShipFit for first-time founders: the missing pattern library
URL: https://shipfit.ai/for/first-time-founders
> Startup validation for first-time founders who don't know what they don't know. ShipFit forces 9 decisions and names the mistakes you can't see. Start free.
## Why first-time founders, specifically
The difference between a first-time founder and a fifth-time founder isn't intelligence. It's a pattern library. The experienced founder has a hundred small scars that fire a warning when an idea has no buyer, or a price nobody will pay, or a scope that's secretly three products. You haven't earned those scars yet, which means the warning never fires. ShipFit is that warning system, on loan.
## The first-time founder trap in 40 words
You don't know what you don't know. The mistake that kills your idea is invisible to you precisely because you've never made it. A forced, sequential set of decisions surfaces the assumption you didn't know to question, before it costs you months.
## What separates first-timers from repeat founders
| Repeat founder does this on instinct | First-time founder skips it | ShipFit forces it |
| --- | --- | --- |
| Names who actually pays | Builds for themselves | Buyer decision |
| Sets a defensible price | Guesses $9.99 | Pricing decision (Van Westendorp) |
| Cuts scope to one hypothesis | Builds the whole vision | What's in v1 decision |
| Picks one painful problem | Solves many shallow ones | Pain decision |
| Plans the launch | Hopes for it | Launch decision |
## How it fits your workflow
1. Run a Quick Take on your first idea. ~2 minutes. See whether the basics survive before you fall further in love with it.
2. If it holds, run the full 9-question flow. ~15-20 minutes. Watch which decisions you would have skipped on your own.
3. Read the verdict and the flagged assumptions. This is the part where you learn what you didn't know.
4. Take the generated [Mom Test](/frameworks/mom-test) questions to real people, so your first interviews aren't wasted.
5. Export the plan to your build tool and start against a spec, not a blank canvas.
## Start with Quick Take
Free tier: 3 credits/month. Paid: $5 for a one-off Quick Take. If your first idea comes back "not worth building," you just avoided the most expensive lesson in the founder pattern library. [Validate your business idea](/validate-your-business-idea) before you commit.
## Frameworks you'll use
- [The Mom Test](/frameworks/mom-test). So your first customer conversations give you truth, not politeness.
- [Van Westendorp pricing](/frameworks/van-westendorp). So your price is a decision, not a guess.
- [Jobs to be Done](/frameworks/jobs-to-be-done). So you understand what your buyer actually hires you to do.
## Not the right fit if...
- You want encouragement more than a verdict. ShipFit is blunt by design.
- You're already past product-market fit. This is a pre-PMF tool for the earliest stage.
- You just want to chat through ideas casually. Try [Buildpad](/vs/buildpad) instead.
### ShipFit for indie hackers: kill bad ideas in 2 minutes
URL: https://shipfit.ai/for/indie-hackers
> For indie hackers who've wasted months on dead ideas. ShipFit forces 9 decisions before you write a line of code. Proven frameworks, exports to Cursor.
## Why indie hackers, specifically
Because you have the fewest resources and the highest cost-per-mistake. A VC-backed team can waste a quarter on the wrong feature and keep going. You can't. A 6-week side project that dies in private costs you a month of evenings and your belief that you can ship. That's expensive.
## The honest indie hacker math
You ship 3 projects a year. If your idea-validation accuracy is 50%, you're going to spend half your weekends building products that die in private. If you can bump that to 75%. By killing the worst ideas before they eat your calendar. You ship *twice as many* things that actually work. That's the whole value prop.
**Example from the user base:**
> "I was about to build a Chrome extension for managing Notion databases. Quick Take said my market was 3,000 people and most of them use it for free. I pivoted in 8 minutes. Saved me the weekend."
> "Ran my 'AI for real estate agents' idea through. Got told my buyer was wrong. I was targeting the agents, but the brokerages pay. Took me 10 minutes to reframe. Saved me six weeks of talking to the wrong people."
(Both composites. But representative of the Quick Take outcome distribution.)
## What indie hackers actually get
- **2-minute Quick Take**. Verdict, Signal Confidence Level, Areas to Clarify, Key Opportunities — enough to kill or commit before the weekend starts
- **Full 9-question playbook**. Exportable to Cursor / Claude Code / Windsurf / a pitch deck
- **The Roast**. Because sometimes you need to be told your idea is a hobby, not a business
- **55 frameworks applied for you**. Mom Test, Van Westendorp, JTBD, 7 Powers, Blue Ocean, ICE — without the consultant fees
- **Brutal verdict tiers**. *Promising*, *Promising Needs Focus*, *Needs Major Pivot*, *Don't Ship*. No hedging
## How it fits your workflow
1. Friday night. New idea. Run Quick Take. $5, 2 minutes. Kill or commit.
2. If committed: Saturday morning. Run the 9-question flow. 15 minutes.
3. Export the playbook to Cursor. Start building against a spec, not vibes.
4. Monday. Talk to 3 real users with Mom Test questions (generated in-flow).
5. Next weekend. Iterate or kill based on real signal.
No consultant. No 6-week "validation phase." No pretending you're a product manager.
## Start with Quick Take
Free tier: 3 credits/month. Paid: $5 for a one-off Quick Take on your next idea. If it comes back "not worth building," you just saved a weekend.
## Frameworks you'll use
- [The Mom Test](/frameworks/mom-test). For when you start talking to real users
- [Van Westendorp pricing](/frameworks/van-westendorp). For pricing your side project like a grown-up
- [Jobs to be Done](/frameworks/jobs-to-be-done). For understanding what your buyer actually hires your product to do
- [ICE scoring](/frameworks/ice-scoring). For prioritizing features when you're one person
## Not the right fit if…
- You want a chat buddy to brainstorm with. Try [Buildpad](/vs/buildpad) instead
- You're already past product-market fit and scaling. This is a pre-PMF tool, not a growth tool
- You find blunt feedback demotivating. ShipFit is brutal by design; if that's wrong for you right now, that's legitimate
### ShipFit for non-technical founders: the code barrier is gone
URL: https://shipfit.ai/for/non-technical-founders
> Validation for non-technical founders using AI builders and no-code. The bottleneck isn't building anymore, it's deciding what to build. ShipFit decides.
## Why non-technical founders, specifically
For most of startup history, being non-technical meant the build was your bottleneck. You needed a developer, an agency, or a cofounder who could write code. AI builders and no-code tools erased that. You can now ship a working product without a single line of code. But the bottleneck didn't disappear, it moved. The hard part is no longer building. It's deciding what to build, and that's the skill nobody handed you when they handed you the tools.
## The non-technical founder shift in 40 words
The code barrier is gone. You can prompt an AI builder into a working app in an afternoon, which means you can also build the wrong thing in an afternoon. The new bottleneck is the decision in front of the build, and that's what ShipFit makes.
## What changed, and what ShipFit does about it
| Old world | New world (AI builders) | What ShipFit handles |
| --- | --- | --- |
| Building was the bottleneck | Deciding what to build is the bottleneck | The 9 forced decisions |
| You needed a developer | You need a buyer and a price | Buyer and pricing stages |
| Code was the risk | The unvalidated idea is the risk | Quick Take verdict |
| A cofounder pushed back | You have a tool that just complies | The Roast, blunt by design |
| You wrote a brief by hand | You prompt from a blank mind | An exportable build brief |
## How it fits your workflow
1. Before you open Lovable, v0, or Replit, run a Quick Take. ~2 minutes. Confirm the idea has a buyer before you spend build credits.
2. If it survives, run the full 9-question flow. ~15-20 minutes. Make the who-pays, what-price, and what's-in-v1 decisions a cofounder would have forced.
3. Export the plan as a build brief to your AI builder (Lovable, v0, Replit, Gemini, and more). Now you're prompting from a validated plan.
4. Take the generated [Mom Test](/frameworks/mom-test) questions to real people, since you can't judge the idea by reading the code.
5. Iterate on real signal. The build was never your risk. The decision in front of it was.
## Start with Quick Take
Free tier: 3 credits/month. Paid: $5 for a one-off Quick Take, $10 for a full playbook. [Validate your business idea](/validate-your-business-idea) before you spend an afternoon of build credits on something with no buyer. See [pricing](/pricing) for current plans.
## Frameworks you'll use
- [The Mom Test](/frameworks/mom-test). For judging the idea by talking to people, since you can't judge it by the code.
- [Van Westendorp pricing](/frameworks/van-westendorp). For setting a real price instead of guessing.
- [Jobs to be Done](/frameworks/jobs-to-be-done). For knowing what your buyer actually hires the product to do.
## Not the right fit if...
- You want a tool that just builds whatever you say. That's your AI builder. ShipFit is the decision in front of it.
- You're already past product-market fit and scaling. This is a pre-PMF decision tool.
- You want a friendly brainstorm partner who agrees with you. Try [Buildpad](/vs/buildpad) instead.
### ShipFit for product managers: validate the roadmap bet
URL: https://shipfit.ai/for/product-managers
> Idea validation for product managers who need stakeholder buy-in. ShipFit forces 9 decisions in ~20 minutes so you can defend or kill a bet fast. Start free.
## Why product managers, specifically
Because your scarcest resource is not money, it is the quarter. A founder who picks the wrong bet loses their own runway. A PM who picks the wrong bet spends a whole team's quarter, plus the political capital it took to get the bet approved. Opportunity cost is the real cost, and it is invisible until the next planning cycle when you have nothing to show. The cheapest place to lose that argument is before the roadmap is committed, in the decisions, not in the retro.
## The PM validation problem in 40 words
You have to commit a team to a bet you can only partially prove, then defend it to stakeholders who each want something different. Get the buyer or the pain wrong and you don't lose a sale, you burn a quarter and the trust that funds your next bet.
## Where PM bets lose, and which decision catches it
| Failure mode | Symptom later | ShipFit decision that catches it |
| --- | --- | --- |
| Fuzzy segment | Built for the loudest stakeholder | Buyer (Jobs-to-be-Done) |
| Pain isn't real | Low adoption in beta | Pain decision |
| No willingness to pay or adopt | Feature ships, usage flat | Behavioral validation |
| Bloated scope | Slow ship, no clear learning | What's in v1 |
| Weak case | Loses the prioritization review | Verdict + positioning (7 Powers) |
## How it fits your workflow
1. New bet lands (yours or top-down). Run a Quick Take. ~2 minutes. Decide if it's worth a real discovery cycle.
2. If it survives, run the full 9-question playbook. ~15-20 minutes. Lock the buyer, the pain, and the scope.
3. Bring the verdict and the named frameworks into the roadmap review as your defensible case.
4. Scope v1 to the riskiest assumption. Export to Cursor, Claude Code, or v0 so engineering builds against a thesis.
5. Take the [Mom Test](/frameworks/mom-test) questions into real discovery interviews before you commit the quarter.
## Start with Quick Take
Free tier: 3 credits/month. Paid: $5 for a one-off Quick Take, $10 for a full playbook. [Validate your business idea](/validate-your-business-idea) before you commit a team's quarter. See [pricing](/pricing) for current plans.
## Frameworks you'll use
- [Jobs to be Done](/frameworks/jobs-to-be-done). For anchoring the bet to a real buyer, not a feature request.
- [Van Westendorp pricing](/frameworks/van-westendorp). For willingness-to-pay evidence when the bet involves monetization.
- [The Mom Test](/frameworks/mom-test). For discovery that predicts adoption, not polite interest.
## Not the right fit if...
- You already have strong quantitative signal (live experiments, cohort data) for this bet. This is a pre-build decision tool, not an analytics suite.
- You want a roadmapping or ticketing tool. ShipFit decides whether the bet is worth a roadmap slot, it doesn't manage the roadmap.
- You just want to brainstorm casually. Try [Buildpad](/vs/buildpad) instead.
### ShipFit for SaaS founders: fix ICP and pricing before launch
URL: https://shipfit.ai/for/saas-founders
> SaaS idea validation that pressure-tests your ICP, pricing model, and retention before you build. ShipFit forces 9 decisions in ~20 minutes. Start free.
## Why SaaS founders, specifically
SaaS punishes early mistakes more than any other model because the mistakes recur. A one-time product gets one transaction wrong and moves on. A subscription compounds the wrong ICP, the wrong price, and the wrong value metric into every monthly cohort. By the time churn tells you something is off, you've built a base on the wrong foundation. The cheapest place to fix a SaaS mistake is before launch, in the decisions, not in the dashboard.
## The SaaS validation problem in 40 words
In recurring revenue, your earliest decisions (who pays, what model, what recurring problem) keep charging you every month. Get the ICP or pricing model wrong and you don't lose one sale, you build a subscription nobody renews. Forcing those decisions first is the leverage.
## Where SaaS founders lose, and which decision catches it
| Failure mode | Symptom later | ShipFit decision that catches it |
| --- | --- | --- |
| Fuzzy ICP | Unexplained churn | Buyer (Jobs-to-be-Done) |
| Wrong pricing model | Hard-to-reverse re-pricing, lost expansion | Pricing (Van Westendorp) |
| Non-recurring pain | Users solve it once and leave | Pain decision |
| Bloated v1 | Slow launch, no clear thesis | What's in v1 |
| Weak positioning | High CAC, no moat | Positioning (7 Powers) |
## How it fits your workflow
1. Run a Quick Take on the idea or the new segment. ~2 minutes. Confirm the recurring thesis is plausible before you build.
2. Run the full 9-question playbook. ~15-20 minutes. Lock the ICP, the pricing model, and the recurring pain.
3. Use the pricing stage output to choose seat vs usage vs tier, grounded in willingness to pay, not competitor copying.
4. Scope v1 to the one thing that proves people pay again. Export to Cursor, Lovable, or v0.
5. Take the [Mom Test](/frameworks/mom-test) questions to real buyers and watch renewal behavior, not just signups.
## Start with Quick Take
Free tier: 3 credits/month. Paid: $5 for a one-off Quick Take, $10 for a full playbook. [Validate your business idea](/validate-your-business-idea) before you build a subscription on the wrong ICP. See [pricing](/pricing) for current plans.
## Frameworks you'll use
- [Van Westendorp pricing](/frameworks/van-westendorp). For a defensible price and the right recurring model.
- [Jobs to be Done](/frameworks/jobs-to-be-done). For an ICP precise enough to retain.
- [The Mom Test](/frameworks/mom-test). For discovery that predicts renewals, not just polite interest.
## Not the right fit if...
- You're past product-market fit and purely scaling acquisition. This is a pre-PMF decision tool, not a growth platform.
- You want churn-prevention tooling like dunning and save flows. ShipFit fixes the validation-stage causes of churn, not the operational ones.
- You just want to brainstorm casually. Try [Buildpad](/vs/buildpad) instead.
### ShipFit for solo founders: the second opinion that isn't you
URL: https://shipfit.ai/for/solo-founders
> Validation for solo founders with no cofounder to push back. ShipFit forces 9 decisions and argues with your idea in 2 minutes on real data. Start free.
## Why solo founders, specifically
A solo founder has no structural disagreement. On a two-person team, one person says "are we sure about this?" and the other has to answer. Alone, you ask the question and you also get to dismiss it. The result is that bad ideas survive longer for solo founders than for anyone else, because nothing in the room is built to kill them. ShipFit exists to be that something.
## The solo founder problem in 40 words
You are builder, marketer, support, and CEO at once. Nobody owns the question "is this worth doing at all," so it gets skipped, and you find out the idea was dead only after you've built it. A forced check fixes that.
## What you actually get
| You don't have | ShipFit gives you |
| --- | --- |
| A cofounder to push back | 9 forced decisions that argue with your reasoning |
| Spare hours to waste | A ~2 minute Quick Take before you commit a week |
| A team to parallelize bets | Verdict tiers that rank competing ideas for you |
| A product manager to write the spec | An export to Cursor, Claude Code, Lovable, or v0 |
| A polite-free sounding board | The Roast, which is brutal by design |
## How it fits your workflow
1. New idea at the end of a long solo day. Run a Quick Take. ~2 minutes. Kill or commit before you sleep on it and over-invest.
2. If it survives, run the full 9-question flow. ~15-20 minutes. Let it disagree with you on buyer, pricing, and scope.
3. Export the playbook to your build tool. You're now building against a plan, not a mood.
4. Take the generated [Mom Test](/frameworks/mom-test) questions to 3 real people. The interviews you can't afford to waste are now pointed at the right buyer.
5. Iterate or kill on real signal, not on how attached you've become.
No cofounder to convene. No team meeting. Just the structured pushback you've been doing without.
## Start with Quick Take
Free tier: 3 credits/month, enough for a Quick Take and one decision. Paid: $5 for a one-off Quick Take on your next idea. [Validate your business idea](/validate-your-business-idea) before you commit the only resource you have, which is you.
## Frameworks you'll use
- [The Mom Test](/frameworks/mom-test). So your few precious customer conversations actually tell you something.
- [Van Westendorp pricing](/frameworks/van-westendorp). For pricing without a partner to argue you off your guess.
- [Jobs to be Done](/frameworks/jobs-to-be-done). For figuring out what your buyer is really hiring you to do.
## Not the right fit if...
- You want a warm brainstorm partner who riffs along with you. Try [Buildpad](/vs/buildpad) instead.
- You're already past product-market fit and just need growth. This is a pre-PMF decision tool.
- You find blunt feedback demoralizing right now. ShipFit is built to disagree, and if that's wrong timing for you, that's fair.
### ShipFit for technical founders: the skill trap, not the edge
URL: https://shipfit.ai/for/technical-founders
> Idea validation for technical founders who can build anything. ShipFit forces the buyer and pricing decisions your engineering skill lets you skip. Start free.
## Why technical founders, specifically
For most founders, building is the bottleneck. For you it's the escape hatch. When a hard question comes up (who actually pays, what's the price, why this over the alternative), you can always retreat into something you're good at: writing code. That's why technically strong founders so often ship beautiful, well-architected products that nobody wanted. The skill that should be your edge becomes the thing that lets you avoid the only questions that matter.
## The technical founder trap in 40 words
You can build it, so you build it, before validating that anyone wants it. Engineering fluency removes the natural friction that forces other founders to stop and think. ShipFit puts that friction back, by making the non-technical decisions non-optional before you write code.
## The decisions engineers skip (and ShipFit forces)
| Decision | Why you skip it | Why it kills you |
| --- | --- | --- |
| Who pays | Not technically interesting | No buyer means no business, regardless of code quality |
| What price | Feels like a later problem | Wrong pricing model can sink a perfect product |
| What's in v1 | You'd rather build it all | Unfocused scope is just three half-products |
| Why this over alternatives | Obvious to you, unproven to them | Positioning, not features, wins the buyer |
| Who the buyer actually is | You designed for yourself | Building for yourself rarely scales to a market |
## How it fits your workflow
1. Before you open the editor, run a Quick Take. ~2 minutes. Confirm the idea survives the basics while a pivot is still free.
2. If it holds, run the full 9-question flow. ~15-20 minutes. It forces the buyer, pricing, and scope decisions you'd otherwise defer indefinitely.
3. Export the validated plan to Cursor, Claude Code, Windsurf, v0, or Replit. Now you're building against a spec grounded in a market, not just clean architecture.
4. Take the generated [Mom Test](/frameworks/mom-test) questions to real buyers instead of refactoring for a week.
5. Iterate on real signal. The code was never the risk. The assumption was.
## Start with Quick Take
Free tier: 3 credits/month. Paid: $5 for a one-off Quick Take, $10 for a full playbook. Run it before the architecture seduces you. [Validate your business idea](/validate-your-business-idea) while a pivot is still a rethink and not a rewrite.
## Frameworks you'll use
- [The Mom Test](/frameworks/mom-test). For the discovery you'd rather skip in favor of coding.
- [Van Westendorp pricing](/frameworks/van-westendorp). For the pricing decision that isn't a technical problem.
- [Jobs to be Done](/frameworks/jobs-to-be-done). For understanding what the buyer hires the product to do, beyond what it does technically.
## Not the right fit if...
- You're building purely for fun or learning, with no intent to find a market. Then there's nothing to validate.
- You're already past product-market fit and scaling the engineering. This is a pre-PMF tool.
- You want a tool that admires your stack. ShipFit only cares whether someone pays for what it produces.