Product Stage — Minimum Lovable Product (MLP) & Solution Architecture

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)

---
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.