Product & MVP Playbook

Core Rule

Ship fast. Learn fast. Kill features that don't serve the core job. The goal of an MVP is to learn, not to impress.

MVP Principles

1. An MVP is not a bad version of your product. It's the minimum needed to test your riskiest assumption.
2. Cut scope until it hurts, then cut more. If you're not embarrassed by your MVP, you launched too late. (Reid Hoffman)
3. Build for your first 10 customers, not your first 1,000.
4. Manual before automated. Do it yourself before building software to do it.
5. Feedback is the product. Your job is to collect it, not to ship features.

MVP Types (Pick the Right One)

No-Code MVP Options

You don't need to write code to validate most ideas:

Use no-code to validate. Rebuild in code only when no-code breaks (usually at 50-100 users or when you need custom logic).

When to Stop Building and Start Selling

Founders overbuild. Use this checklist:

Ship when:

• [ ] One person can complete the core workflow end-to-end
• [ ] The biggest pain point is addressed (even if imperfectly)
• [ ] You've cut every feature that isn't required for the first use
• [ ] A real user has tested it and found the core value

Do NOT wait for:

• Edge case handling
• Beautiful design
• Mobile responsive layout
• Multi-user support
• Settings and preferences
• Analytics dashboard
• Email notifications for everything

The test: Can a customer pay you money and get value? If yes, ship it.

Feature Prioritization (ICE Framework)

Score each feature 1-10 on:

• Impact — How much will this move the north star metric?
• Confidence — How sure are we this will work?
• Ease — How fast/cheap can we build it?

ICE Score = (Impact + Confidence + Ease) / 3

Build highest-scoring features first. Review and re-score weekly.

Alternative: RICE Framework (for larger teams)

• Reach — How many users does this affect per quarter?
• Impact — How much does it move the metric? (3=massive, 2=high, 1=medium, 0.5=low)
• Confidence — How sure are we? (100%, 80%, 50%)
• Effort — Person-weeks to build

RICE Score = (Reach × Impact × Confidence) / Effort

North Star Metric

Your north star metric is the one number that best captures value delivered to customers.

Choose one. Align the whole team to it. Review weekly.

Product Roadmap (Startup Format)

Don't build 12-month roadmaps. Build rolling 90-day plans.

NOW (this sprint):
- [Feature/fix 1]
- [Feature/fix 2]

NEXT (next 4 weeks):
- [Feature 3]
- [Feature 4]

LATER (90 days):
- [Big bet 1]
- [Big bet 2]

NOT DOING:
- [Thing people ask for but doesn't move NSM]

Review and update every 2 weeks. The "NOT DOING" list is as important as the "NOW" list.

User Story Format

As a [user type],
I want to [action],
So that I can [outcome/benefit].

Acceptance Criteria:
- [ ] Given [context], when [action], then [result]
- [ ] Edge case: [X]

Sprint Structure (2-Week Cycle)

Retro questions:

1. What went well?
2. What slowed us down?
3. What do we change next sprint?

Rule: Never extend a sprint. Cut scope instead. Shipping on time builds the muscle.

Product Metrics to Track Weekly

The most important metric pre-PMF is retention. If users aren't coming back, nothing else matters.

Common Product Mistakes

The "Should I Build This?" Test

Before building any feature, ask:

1. Does it serve the core job? If not, it waits.
2. Will 3+ current customers use it this week? If not, it's speculative.
3. Can we test the idea without building it? (Mock, prototype, manual)
4. What's the cost of NOT building it? (Churn? Lost deals? Nothing?)
5. Does it make the product simpler or more complex? Complexity is a tax.

If you can't answer #2 with specific customer names, don't build it.

Tools (Free / Low Cost Tier)

> Disclaimer: This playbook provides educational frameworks for product development. Tool recommendations are not endorsements. This is not professional business advice.