---
title: "Product Stage — Minimum Lovable Product (MLP) & Solution Architecture"
description: "Architecting and delivering the smallest complete solution that delivers immediate customer delight and measurable value."
stage: "03-product"
version: "2.0.0"
updated_date: "2026-10-23"
changelog: "v2.0.0 (2026-10-23): Qualified MVP vs. MLP methodological framing, defined P0/P1 severities, clarified illustrative gate thresholds, and added SPEC/Test Matrix templates."
status: "active"
---

The **Product Stage** is the execution engine of the NBM4 framework. While Eric Ries originally defined a Minimum Viable Product (MVP) as the smallest experiment needed to achieve validated learning, in industry practice MVPs are frequently misapplied as broad, half-finished production releases that frustrate early adopters. As a **methodological position**, NBM4 separates **value-testing experiments (`E4` prototypes and HADI tests)** from the initial production release, which targets a **Minimum Lovable Product (MLP)** for a narrowly bounded workflow.

## Common Misapplied MVP vs. NBM4 Minimum Lovable Product (MLP)

| Characteristic | Common Misapplied MVP (Industry Practice) | NBM4 Minimum Lovable Product (MLP) |
| :--- | :--- | :--- |
| **Scope** | Broad, shallow feature coverage across many personas | Narrow, end-to-end mastery of one verified customer job |
| **User Experience** | Unfinished workflows pushed to production | Polished, reliable first-run experience for the core job |
| **Architecture** | Ad-hoc patches without explicit contract boundaries | Governed, modular contracts verified by CI guards |
| **Success Criterion** | "Did the feature ship on schedule?" | "Did the target cohort complete the core job and return?" |

## The Three Pillars of NBM4 Solution Architecture

1. **Theme, Epic & User Job Story (UJS) Hierarchy**:
   Break strategic product roadmaps into hierarchical, testable increments where every single engineering commit directly traces to a verified customer job.
2. **Defensive Governance & CI Gates**:
   Automate encoding, linting, architecture constraints, and regression testing at the commit boundary.
3. **Continuous Verification Protocol**:
   Ensure every shipped capability has automated integration suites and real-world scenario tests before customer release.

## Governed Artifacts in the Product Stage (`3_product`)

In the `ship-mlp-core` v3.7.0 governed artifact registry (`stage:nbm4:product@1.0.0`), the Product Stage consolidates Value Proposition, Value Testing, and Solution Architecture into **15 L4 artifact contracts** under `.0-mlp/3_product/`:

| Artifact Title | Qualified ID & Schema | Typed ID (`artefact_type_id`) | Core Purpose & Role |
| :--- | :--- | :--- | :--- |
| **Product Vision** | `nbm4:product-vision@1.0.0` | `NBM4-PRODUCT-VISION` | Authoritative product direction (`Product direction`, `Target outcomes`, `Boundaries`) that grounds SPECs. |
| **Product Hypothesis** | `nbm4:product-hypothesis@1.0.0` | `NBM4-PRODUCT-HYPOTHESIS` | Falsifiable value and behavior claim (`Claim`, `Test design`, `Falsification signal`). |
| **Strategy Window** | `nbm4:strategy-window@2.0.0` | `NBM4-PRODUCT-STRATEGY-WINDOW` | Bounded strategic horizon and allocation window (`Window summary`). |
| **Release Requirements Document (RRD)** | `nbm4:release-requirements-document@1.0.0` | `NBM4-PRODUCT-RELEASE-REQUIREMENTS-DOCUMENT` | Release-scoped requirements and acceptance boundaries (succeeding legacy PRDs). |
| **Product Requirements Document (Legacy)** | `nbm4:product-requirements-document@1.0.0` | `NBM4-PRODUCT-REQUIREMENTS-DOCUMENT` | Legacy compatibility PRD contract (`Problem and audience`, `Requirements`). |
| **Product Document** | `nbm4:product-document@1.0.0` | `NBM4-PRODUCT-DOCUMENT` | General governed product narrative (`Document body`). |
| **Architecture Decision (ADR)** | `nbm4:architecture-decision@2.0.0` | `NBM4-PRODUCT-ARCHITECTURE-DECISION` | Versioned architectural trade-off and invariant record (`Decision`, `Consequences`). |
| **Architecture Review Record (ARV)** | `nbm4:architecture-review-record@1.0.0` | `NBM4-PRODUCT-ARCHITECTURE-REVIEW-RECORD` | Immutable review attestation binding an ADR or design package. |
| **SPEC** | `nbm4:spec@4.0.0` | `NBM4-PRODUCT-SPEC` | Executable specification with qualified Product Vision basis (`Summary`, Themes/Epics/UJS). |
| **SPEC Graph** | `nbm4:spec-graph@3.0.0` | `NBM4-PRODUCT-SPEC-GRAPH` | Machine-readable dependency and traceability graph across SPEC nodes. |
| **Test Matrix** | `nbm4:test-matrix@2.0.0` | `NBM4-PRODUCT-TEST-MATRIX` | Deterministic verification matrix mapping UJS requirements to executable tests. |
| **Request for Bug-fix (RFB)** | `nbm4:rfb@2.0.0` | `NBM4-PRODUCT-RFB` | Defect reproduction, root-cause analysis, and remediation contract. |
| **Change Package (CPK)** | `nbm4:change-package@2.0.0` | `NBM4-PRODUCT-CHANGE-PACKAGE` | Bounded implementation unit grouping code, spec, and verification changes. |
| **Validation Evidence** | `nbm4:validation-evidence@2.0.0` | `NBM4-PRODUCT-VALIDATION-EVIDENCE` | Generated proof receipt attesting that CI guards and tests passed. |
| **Pull Request Candidate** | `nbm4:pull-request-candidate@2.0.0` | `NBM4-PRODUCT-PULL-REQUEST-CANDIDATE` | Pre-merge dossier binding Change Packages, Test Matrices, and Validation Evidence. |

## Worked Template: `SPEC` (`nbm4:spec@4.0.0` with TEU / UJS Hierarchy)

```yaml
---
artifact_uuid: 0192b8c0-3300-7000-8000-000000000305
artifact_id: SPEC-0012
type: spec
artefact_type_id: NBM4-PRODUCT-SPEC
schema_version: 4.0.0
version: 1
status: active
created_date: 2026-10-23 11:00 UTC+04:00
updated_date: 2026-10-23 11:00 UTC+04:00
authority_refs:
  - VIS-0001
  - RRD-0003
---

## Summary

- Theme T-01: Governed Artifact Authoring
- Epic E-01.1: Stage Gate Validation
- User Job Story UJS-01.1.1: When a product manager commits a stage artifact, the CI Guard Office validates schema conformance and authority references so invalid specs cannot enter the release branch.
- Acceptance criteria & Test Matrix binding: Verified by TMX-0012 (cases TC-01 through TC-04).
```

## Promotion Gate: Transitioning to Stage 04 (Growth)

Each Product Cell defines quantitative graduation thresholds in its `Release Requirements Document (RRD)` before promoting an MLP to Stage 04 (Growth & Scale). An **illustrative promotion gate** for a B2B workflow MLP requires:

- **Core-Journey Completion (Illustrative Gate)**: At least `85–90%` unassisted task-completion rate across an initial pilot cohort (`n ≥ 20` target-ICP sessions measured via event telemetry from workflow start to verified outcome). Teams calibrate the exact percentage and sample size `n` to their domain risk and traffic volume.
- **Zero Open `P0` or `P1` Blockers**:
  - **`P0` (Critical Blocker)**: Any defect or vulnerability that completely prevents core workflow completion, corrupts data integrity, or violates security/compliance boundaries with no workaround.
  - **`P1` (Major Blocker)**: Any defect that severely degrades primary job completion or performance without an acceptable user workaround.
- **Repeat Usage Evidence (`E5`)**: Behavioral cohort telemetry confirming that pilot users return to execute the workflow repeatedly without manual concierge prompting.