Mvp Architect

MVP Architect - Minimum Viable Product Scoping

Overview

Help indie founders scope the smallest possible product that validates their core hypothesis using Hexa's methodology. Get to market in 3 months or less.

Hexa's Core Principle: "Launch an MVP with key high-value features within 3 months. It's better to launch with clear, easily understood features, even if they aren't at full power yet."

When This Activates

• "What should my MVP include"
• "Help me scope my MVP"
• "What features do I need"
• "What to build first"
• "Been building for months, haven't launched"

Hexa's 7 Principles

1. Dig Beyond User Requests — Root needs, not surface wants 2. Combat Confirmation Bias — Challenge assumptions 3. Partner with Design Partners Early — Build with real users 4. Prioritize Adaptable Milestones — 6-month goals, 2-week sprints 5. Sketch Before Designing — Keep ugly until validated 6. Build Around Dry Elements — Only include stable features 7. Stress-Test Architecture — Database design affects everything

Quick Workflow

Step 1: Problem Clarity Check

• 10+ customer interviews?
• One-sentence problem?
• 3-5 design partners?

Step 2: Core Hypothesis

We believe that [customer] has a problem with [pain point].
We believe that [solution] will solve this.
We will know we're right when [success metric].

Step 3: Feature Prioritization

For each feature ask:

• Tests core hypothesis? → Keep
• Users explicitly asked? → Maybe
• Critical path? → Keep
• Can do manually? → Don't build

Target: 3-5 features maximum.

Step 4: Dry Elements Test

Only build features that remained stable through ALL design partner feedback.

Step 5: User Journey (3-4 Screens)

• How do users sign up?
• First action?
• Core value delivery?
• Success confirmation?

Anti-Scope Creep Checklist

Before adding ANY feature:

1. Does this test our core hypothesis? → If no, cut it 2. Have 3+ design partners asked? → If no, defer it 3. Can we launch without this? → If yes, defer it 4. Can we do this manually first? → If yes, don't build it 5. Will this delay launch by >3 days? → If yes, cut it

The "Launch in 2 Weeks" Test

If you HAD to launch in 2 weeks, what would you cut? Whatever you'd cut... cut it now. That's your real MVP.

Integration

• idea-validator - Validate before scoping
• startup-icp-definer - Define who you're building for
• fullstack-workspace-init - Set up codebase
• brand-architect - Name and position product

---

For complete hypothesis framework, feature prioritization matrix, dry elements identification, screen mapping, technical architecture checklist, timeline templates, and output format, see: references/full-guide.md

MVP Architect - Full Guide

Execution Workflow

Step 1: Problem Clarity Check

Before scoping features, validate the problem is clear.

Problem Clarity Assessment:

If any "No" above: Use idea-validator before continuing.

Step 2: Core Hypothesis Definition

Hypothesis Framework:

We believe that [target customer]
has a problem with [specific pain point].

We believe that [our solution]
will solve this because [mechanism].

We will know we're right when [success metric]
within [timeframe].

We will know we're wrong when [failure indicator].

Example:

We believe that B2B sales teams
have a problem with tracking follow-ups across channels.

We believe that a unified inbox with automated reminders
will solve this because it reduces context-switching.

We will know we're right when 50% of trial users
become paying customers within 2 weeks.

We will know we're wrong when users don't log in
more than twice in the first week.

Step 3: Feature Brainstorm (Then Cut)

Feature Capture Template:

Step 4: Feature Prioritization (The Ruthless Cut)

For each feature, ask:

Feature Prioritization Matrix:

Target: 3-5 features maximum for MVP.

Step 5: The "Dry Elements" Test

Dry Elements = Features that remained stable through all design partner feedback.

Dry Elements Identification:

Your MVP = Only Dry Elements.

Wet elements (features that keep changing) need more validation before building.

Step 6: MVP Scope Definition

MVP Scope Template:

┌─────────────────────────────────────────────────┐
│ MVP SCOPE: [Product Name]                       │
├─────────────────────────────────────────────────┤
│ Core Value Prop: [One sentence]                 │
│ Target User: [Specific persona]                 │
│ Primary Use Case: [Main job-to-be-done]         │
├─────────────────────────────────────────────────┤
│ IN SCOPE (3-5 Features):                        │
│ 1. [Feature] — [Why critical]                   │
│ 2. [Feature] — [Why critical]                   │
│ 3. [Feature] — [Why critical]                   │
├─────────────────────────────────────────────────┤
│ EXPLICITLY OUT (For Now):                       │
│ • [Feature] — [When we'll add it]               │
│ • [Feature] — [Why it can wait]                 │
│ • [Feature] — [Manual workaround instead]       │
├─────────────────────────────────────────────────┤
│ SUCCESS METRIC: [What proves MVP works]         │
│ TIMELINE: [X weeks to launch]                   │
└─────────────────────────────────────────────────┘

Step 7: User Journey Mapping (3-4 Screens)

Hexa targets 3-4 simple screens for an MVP.

Screen Map:

Screen 1: [Name]
Purpose: [What user does here]
Key Action: [Primary button/action]
     │
     ▼
Screen 2: [Name]
Purpose: [What user does here]
Key Action: [Primary button/action]
     │
     ▼
Screen 3: [Name]
Purpose: [What user does here]
Key Action: [Primary button/action]
     │
     ▼
Screen 4: [Name] (if needed)
Purpose: [What user does here]
Success State: [What success looks like]

Step 8: Technical Architecture Check

Architecture Review Checklist:

Hexa's Rule: Have 3-4 tech leaders review your architecture before building.

Step 9: Timeline & Milestones

Timeline Framework:

If you can't launch in 10 weeks, scope is too big.

Step 10: Manual vs. Automated Decision

Many MVP features can be manual first.

The "Wizard of Oz" MVP: Automate the frontend, do backend manually. Users don't know the difference.

Output Format Template

# MVP Scope: [Product Name]

## Executive Summary

**Product:** [One-line description]
**Target User:** [Specific persona]
**Core Hypothesis:** [What we're testing]
**Timeline:** [X weeks to launch]
**Success Metric:** [How we know it works]

## Problem Validation Status

| Check | Status | Notes |
|-------|--------|-------|
| 10+ customer interviews | [✓/✗] | [Details] |
| Problem clearly articulated | [✓/✗] | [Details] |
| 3-5 design partners committed | [✓/✗] | [Names] |
| PCV score | [X/24] | [Assessment] |

## Core Hypothesis

**We believe that:** [target customer]
**Has a problem with:** [specific pain point]
**Our solution:** [what we're building]
**Will work because:** [mechanism]
**We'll know we're right when:** [success metric]
**We'll know we're wrong when:** [failure indicator]

## Feature Scope

### IN SCOPE (MVP)

| # | Feature | Rationale | Dry Element? |
|---|---------|-----------|--------------|
| 1 | [Feature] | [Why it's essential] | [Yes/No] |
| 2 | [Feature] | [Why it's essential] | [Yes/No] |
| 3 | [Feature] | [Why it's essential] | [Yes/No] |

### EXPLICITLY OUT (V2+)

| Feature | Why Deferred | When to Add |
|---------|--------------|-------------|
| [Feature] | [Reason] | [Trigger for adding] |

### MANUAL FOR NOW

| Automated Feature | Manual Alternative | When to Automate |
|-------------------|-------------------|------------------|
| [Feature] | [How we'll do it manually] | [When to build] |

## User Journey (3-4 Screens)

### Screen 1: [Name]
**Purpose:** [What happens here]
**User Action:** [What they click/do]

### Screen 2: [Name]
**Purpose:** [What happens here]
**User Action:** [What they click/do]

### Screen 3: [Name]
**Purpose:** [What happens here]
**User Action:** [What they click/do]

## Technical Architecture

### Core Entities

| Entity | Key Fields | Relationships |
|--------|------------|---------------|
| [Entity] | [Fields] | [Relations] |

### Tech Stack

| Layer | Choice | Rationale |
|-------|--------|-----------|
| Frontend | [Tech] | [Why] |
| Backend | [Tech] | [Why] |
| Database | [Tech] | [Why] |
| Auth | [Tech] | [Why] |
| Hosting | [Tech] | [Why] |

## Timeline

| Week | Milestone | Deliverables |
|------|-----------|--------------|
| 1-2 | Foundation | [What's done] |
| 3-4 | Core Feature | [What's done] |
| 5-6 | Design Partner Testing | [Who tests] |
| 7-8 | Iteration | [What we'll fix] |
| 9-10 | Launch | [Public release] |

**Hard Deadline:** [Date]

## Success Metrics

### Week 4 (Internal)
- [Metric 1]
- [Metric 2]

### Week 8 (Design Partner)
- [Metric 1]
- [Metric 2]

### Week 12 (Public)
- [Metric 1]
- [Metric 2]

## Next Steps

### This Week
- [Action 1]
- [Action 2]
- [Action 3]

Common Mistakes to Avoid

1. Building before validating: No design partners = building in the dark 2. Too many features: If you have more than 5, you're over-scoped 3. Premature polish: Ugly but working > beautiful but unfinished 4. Fixed roadmaps: Plans change—stay adaptable 5. Building what you'd use: You're not the customer (usually) 6. Ignoring feedback: Design partners know better than your assumptions 7. Perfect architecture first: You'll rewrite it anyway—ship first 8. Underestimating manual options: Many features can be manual for months