Mvp Validator

MVP Validator

Overview

This skill enables critical evaluation of Minimum Viable Products from an agile startup consultant perspective. It assesses whether an MVP is realistic, follows agile principles, and makes business sense by analyzing three key dimensions: the core business idea, the MVP requirements, and the implementation plan. The skill emphasizes identifying both strengths and pain points through objective analysis, providing constructive feedback that helps founders refine their approach.

When to Use This Skill

Activate this skill when users ask to:

• Review an MVP for realism and business viability
• Evaluate a startup idea and its implementation plan
• Validate if an MVP follows agile principles
• Provide feedback on MVP requirements and scope
• Assess the feasibility of a product vision
• Challenge assumptions in a startup plan

MVP Review Workflow

Phase 1: Idea Assessment

Examine the core business idea for:

• Problem Validity: Does a real problem exist? Is it significant enough to solve?
• Market Opportunity: Is the addressable market realistic? Who exactly is the target customer?
• Differentiation: What makes this approach unique or better than existing solutions?
• Founder-Market Fit: Do the founders have relevant expertise or insight into this problem?

Phase 2: Requirements Evaluation

Analyze the MVP requirements against agile principles:

• Scope Realism: Can these features realistically be built in the proposed timeline?
• MVP Definition: Are these truly minimal features for validating the core hypothesis, or is scope creep present?
• Dependency Analysis: Are there technical, regulatory, or market dependencies that could derail the plan?
• Priority Clarity: Which features are essential vs. nice-to-have? Are priorities defensible?

Phase 3: Plan Assessment

Evaluate the implementation plan:

• Timeline Realism: Are the estimates reasonable given team size and complexity?
• Resource Alignment: Does the plan account for all required skills and roles?
• Risk Awareness: Are major risks identified and mitigation strategies defined?
• Validation Strategy: How will the team measure if the MVP succeeds or fails?

Phase 4: Synthesis & Feedback

Deliver structured feedback covering:

• Strengths: What's compelling about this approach? What gives confidence it could work?
• Critical Concerns: What are the highest-risk assumptions or gaps?
• Specific Recommendations: Concrete, actionable suggestions to improve the MVP
• Overall Assessment: Is this MVP ready to move forward, needs refinement, or requires significant rethinking?

Analysis Principles

Critical but Constructive: Challenge assumptions and identify problems, but frame feedback as guidance toward a better outcome, not dismissal.

Objective vs. Opinionated: Ground analysis in evidence (market size claims, technical feasibility, timeline estimates) rather than personal preferences.

Agile Lens: Emphasize iterative validation, reducing scope to test core hypotheses, and building what customers actually need—not building "perfect" products.

Founder Perspective: Remember the founders are making real decisions with limited information. Help them make better decisions, not paralysis through over-analysis.

Example Review Prompt Format

When users provide an MVP for review, structure the analysis:

## The Idea
[2-3 sentence summary of what they're building and why]

## Strength: [Specific strength]
[Why this aspect is compelling]

## Concern: [Key risk or gap]
[Why this matters and what could derail it]

## Questions to Validate
- [Assumption that needs testing]
- [Assumption that needs testing]

## Recommendation
[Concrete, actionable next step]

Supporting Resources

Refer to references/mvp_evaluation_criteria.md for detailed evaluation frameworks and checklists to ensure comprehensive, consistent analysis across different MVP types and industries.

MVP Review Feedback Template

Use this template structure to provide comprehensive, actionable feedback on MVPs.

---

Executive Summary

Company/Product: [Name] Core Value Proposition: [One sentence] Overall Assessment: [Ready to Build | Needs Refinement | Requires Rethinking]

---

1. The Problem & Opportunity

Summary

[2-3 sentence overview of what the team is building and why]

Validation Status

• Evidence of Problem: [What customer evidence exists?]
• Market Size: [How realistic are the TAM/SAM estimates?]
• Target Customer: [How specific is the customer definition?]

---

2. Strengths

Strength #1: [Title]

Why it matters: [Why this aspect is compelling and gives confidence]

Evidence: [What specific aspect of the plan demonstrates this?]

Strength #2: [Title]

Why it matters: [Why this aspect is compelling and gives confidence]

Evidence: [What specific aspect of the plan demonstrates this?]

---

3. Critical Concerns

Concern #1: [Title]

Why it matters: [Why this is a potential blocker or high-risk item]

Impact if true: [What would happen if this assumption is wrong?]

Suggested approach: [How to test or mitigate this]

Concern #2: [Title]

Why it matters: [Why this is a potential blocker or high-risk item]

Impact if true: [What would happen if this assumption is wrong?]

Suggested approach: [How to test or mitigate this]

---

4. Scope & Requirements Assessment

MVP Definition: [Are the requirements truly minimal and focused?]

Scope Realism: [Can this realistically be built in the proposed timeline?]

Hidden Complexity: [Are there dependencies, technical challenges, or unknowns that might extend the timeline?]

Recommendations:

• [ ] Feature/requirement to potentially cut or defer
• [ ] Feature/requirement to potentially cut or defer
• [ ] Feature/requirement to add for validation

---

5. Implementation Plan Assessment

Timeline: [Is the proposed timeline realistic? What are the assumptions?]

Team & Resources: [Do they have the right skills? Any gaps?]

Risk Awareness: [Are major risks identified? How will they be mitigated?]

Validation Strategy: [How will they know if the MVP is working?]

---

6. Key Assumptions to Validate

• [ ] Assumption #1: [Key assumption about the business]
• How to test: [What evidence would validate or refute this?]

• [ ] Assumption #2: [Key assumption about the business]
• How to test: [What evidence would validate or refute this?]

• [ ] Assumption #3: [Key assumption about the business]
• How to test: [What evidence would validate or refute this?]

---

7. Specific Recommendations

Priority 1 (Before Building)

[Critical changes or validations needed before proceeding]

Priority 2 (During MVP Development)

[Important considerations for the build phase]

Priority 3 (After MVP Launch)

[Things to monitor or prepare for post-launch]

---

8. Overall Assessment

Readiness Level: [ ] Ready to Build | [ ] Needs Refinement | [ ] Requires Rethinking

Confidence: [Why do you feel this way about their likelihood of success?]

Next Steps: [What should the team do in the next 2-4 weeks?]

---

Notes

[Any additional context, questions, or follow-up items]

MVP Evaluation Criteria Framework

Core Evaluation Dimensions

1. Problem & Market

Problem Definition Quality

• Is the problem clearly articulated and specific?
• What evidence suggests this is a real problem (customer interviews, usage data, market research)?
• How widespread is the problem? Who experiences it most acutely?
• Is the problem urgent or a "nice-to-have"?

Target Customer Clarity

• Can you name a specific customer segment (not "everyone")?
• What is their current solution or workaround?
• Why would they switch to this new solution?
• What is the addressable market size realistically?

Differentiation & Competitive Landscape

• What direct or indirect competitors exist?
• How is this solution different or better?
• Is the differentiation defensible, or easily copied?
• What would competitors do in response?

---

2. MVP Requirements Assessment

Scope Reality Check

MVP Definition Validation

An MVP should:

• ✅ Test one or two core assumptions about the business
• ✅ Be buildable in the proposed timeline with available resources
• ✅ Provide enough value that early customers would use it
• ✅ Include only features necessary to validate the hypothesis

Red flags:

• ❌ "We need feature X, Y, Z, and A before any customer will use it"
• ❌ "We're rebuilding the feature for a third time because the MVP wasn't quite right"
• ❌ Months or years to first customer

Dependency Analysis

List all critical dependencies:

• External APIs/Services: What if they change pricing, availability, or terms?
• Data Dependencies: Can required data be obtained? What if a key data source isn't available?
• Team Skills: Are specialized skills (ML, complex infrastructure, regulatory expertise) required?
• Hardware/Manufacturing: For physical products, what is the supply chain risk?
• Market Conditions: Will this work if the market conditions change (recession, regulation, competitor moves)?

---

3. Implementation Plan Evaluation

Timeline Realism

General guidance (adjust based on team experience and complexity):

• Early-stage web/mobile product: 2-4 months for experienced team, 4-8 months for first-time founders
• Complex technical product: 4-8 months minimum
• Regulatory/compliance products: 6-12+ months
• Physical products: 6-18 months

Red flags:

• Timeline doesn't account for QA, deployment, unexpected bugs
• Estimates assume everything goes perfectly
• No buffer for unknowns
• Timeline was set arbitrarily rather than bottom-up estimated
• Same team simultaneously building platform AND finding customers

Resource Alignment

• Does the team have experience with similar projects?
• Are all required roles covered (engineering, product, design, ops)?
• Is someone explicitly responsible for customer discovery/validation?
• What is the realistic velocity given team size and experience?
• Are there skill gaps that need to be filled?

Risk Identification

Evaluate whether the plan identifies:

• Technical risks: Complex integrations, scaling challenges, unknown technologies
• Market risks: Will customers actually want this? How will we know?
• Operational risks: Can we deliver at the planned quality/timeline?
• Team risks: Do we have the skills? Will the team stay aligned?
• External risks: Regulatory changes, competitor moves, market conditions

Each major risk should have:

• Likelihood assessment (high/medium/low)
• Impact if it occurs
• Mitigation strategy or early signal

Validation Strategy

The plan should define how success/failure will be measured:

• Quantitative metrics (adoption, retention, revenue, etc.)
• Timeline for validation (when will you know if the MVP is working?)
• Pivot criteria (what would make you pivot or shutdown?)
• Learning approach (how will you talk to customers?)

---

4. Founder & Team Assessment

Market/Domain Expertise

• Do founders have relevant domain knowledge or unique insight?
• Have they talked to enough customers to validate the problem?
• Are they making this decision based on customer feedback or assumptions?

Execution Capability

• Have they built products before?
• Do they have relevant technical expertise, or will they need to hire?
• Track record of delivering on commitments?

Decision-Making Quality

• How did they arrive at these requirements/timeline?
• Are they open to feedback and iteration?
• Do they understand MVP philosophy or are they trying to build a "complete" product?

---

Industry-Specific Considerations

SaaS/Web Products

• User acquisition cost vs. lifetime value math (even rough estimates)
• Onboarding complexity and support burden
• Retention assumptions realistic?
• Pricing strategy validated with customers?

Marketplace

• Supply side (can you source enough sellers/providers?)
• Demand side (can you attract enough buyers?)
• Unit economics at small scale vs. plan to scale

Mobile Apps

• App store approval timeline (iOS especially)
• Performance/device compatibility assumptions
• Update/version management strategy

Physical Products

• Manufacturing/supply chain realities
• Unit economics at low volume
• Distribution strategy

AI/ML Products

• Data requirements (quality, quantity, licensing)
• Model accuracy assumptions
• Computational cost and latency
• Regulatory/ethical considerations

---

Feedback Patterns

Green Lights ✅

• Problem is clearly validated through customer conversations
• MVP scope is tightly focused on testing one key hypothesis
• Timeline is realistic with buffer
• Team has relevant experience
• Critical risks are identified and mitigated
• Clear success metrics defined

Yellow Lights 🟡

• Problem is assumed rather than validated
• Scope is reasonable but a few "must-haves" could potentially be cut
• Timeline is optimistic but not impossible
• Team is strong but lacks specific experience in this domain
• Some risks identified but not all
• Success metrics are defined but somewhat vague

Red Flags 🚩

• Problem statement is vague or unvalidated
• MVP scope includes too many features or unclear priorities
• Timeline seems impossible given team size/experience
• Team lacks relevant experience and no plan to fill gaps
• Critical risks not identified or acknowledged
• No clear way to measure success or validate assumptions
• Founders seem attached to a specific solution rather than validating the problem