---
title: "Product Stage — Quantitative Value Testing, Evidence Ladder (E0–E6) & HADI Cycles"
description: "How to run quantitative value tests, grade claims on the E0–E6 Evidence Ladder, and record HADI cycle MutationEvents before building full product scope."
stage: "03-product"
version: "1.0.0"
updated_date: "2026-10-23"
changelog: "v1.0.0 (2026-10-23): Added Stage 03 specification for quantitative value testing, E0–E6 Evidence Ladder, HADI cycles, and MutationEvent/PositionClaim templates."
status: "active"
---

Before committing engineering capacity to build a full **Minimum Lovable Product (MLP)**, NBM4 requires teams to test whether the proposed value proposition actually changes customer behavior. Value testing bridges qualitative customer discovery (Stage 02) and production specification (`nbm4:spec@4.0.0`).

## 1. The NBM4 Evidence Ladder (`E0` to `E6`)

Every product claim and hypothesis in NBM4 is graded on a seven-level empirical scale. Assumptions start at `E0` and must climb the ladder through deliberate tests before unlocking larger resource commitments:

| Level | Evidence Tier | Definition & Qualifying Proof | Typical Stage |
| :--- | :--- | :--- | :--- |
| **`E0`** | **Founder / Team Belief** | Untested internal assertion, intuition, or stakeholder opinion (HiPPO). Carries zero empirical weight. | `01-idea` |
| **`E1`** | **Secondary / Desk Research** | Analyst reports, competitor pricing pages, public filings, or market benchmarks. | `01-idea` |
| **`E2`** | **Behavioral Discovery** | 5+ structured interviews focused strictly on *past behavior* and recent concrete episodes (The Mom Test). | `02-customer` |
| **`E3`** | **Quantified Friction & Workaround** | Documented time, budget, or error cost of the customer's existing workaround in real workflows. | `02-customer` |
| **`E4`** | **Behavioral Commitment / Value Test** | Smoke test, interactive prototype, Wizard-of-Oz trial, or letter of intent where prospects invest time, data, or deposit. | `03-product` |
| **`E5`** | **Pilot / First Lovable Delivery** | Target ICP cohort completes the core workflow end-to-end on the MLP with measurable task completion or initial paid conversion. | `03-product` |
| **`E6`** | **Repeatable Scale & Unit Economics** | Multi-cohort retention, positive contribution margin, and repeatable acquisition loops verified across multiple cycles. | `04-growth` |

## 2. Running HADI Learning Cycles (`Hypothesis → Action → Data → Insight`)

NBM4 operationalizes value testing through bounded **HADI cycles**:

1. **Hypothesis (`H`)**: State a falsifiable claim linking a specific target segment, an intervention, an expected behavioral metric, and an explicit falsification threshold.
2. **Action (`A`)**: Execute the smallest valid test (`E3`–`E5`) capable of disproving the hypothesis within a single strategy window (typically 1–2 weeks).
3. **Data (`D`)**: Collect observed behavioral telemetry (`do-data`), sample size `n`, and completion or conversion rates rather than stated opinions (`say-data`).
4. **Insight (`I`)**: Evaluate the data against the pre-committed threshold and record one of **six terminal decisions**:
   - **`confirm`**: Threshold met at the target evidence level; promote the hypothesis or expand scope.
   - **`refine`**: Direction supported but mechanism or segment boundary requires adjustment for the next cycle.
   - **`reject`**: Falsification condition triggered; discard the specific feature or mechanism.
   - **`pivot`**: Core customer problem is valid (`E2`/`E3`), but the solution architecture or channel must change.
   - **`pause`**: External dependency or sample constraint blocks conclusive measurement; freeze allocation.
   - **`kill`**: Problem or unit economics disproved; terminate the initiative and archive findings.

## 3. Governed Templates & Worked Examples

### Template A: `Product Hypothesis` (`nbm4:product-hypothesis@1.0.0`)

```yaml
---
artifact_uuid: 0192b8c0-4f10-7000-8000-000000000301
artifact_id: HYP-0014
type: product-hypothesis
artefact_type_id: NBM4-PRODUCT-HYPOTHESIS
schema_version: 1.0.0
version: 1
status: active
created_date: 2026-10-23 10:00 UTC+04:00
updated_date: 2026-10-23 10:00 UTC+04:00
authority_refs:
  - RES-0008
---

## Claim

For B2B SaaS Product Managers running bi-weekly refinement (ICP-0002), replacing freeform ticket descriptions with a mandatory 4-field UJS + falsification prompt will reduce refinement cycle time by at least 30% within two sprints.

## Test design

- Target evidence tier: E4 -> E5
- Cohort & sample size: n = 12 product teams across 2 consecutive sprints (24 refinement sessions)
- Measurement method: Automated session timer comparing baseline sprint refinement duration against treatment sprints

## Falsification signal

Reject this hypothesis if median refinement duration drops by less than 15% OR if more than 25% of participating PMs abandon the template after Sprint 2.
```

### Template B: `MutationEvent` Record (Emitted at HADI Cycle Close)

```json
{
  "event_type": "MutationEvent",
  "source_cycle": "CYC-0004",
  "target_artifact": "HYP-0014",
  "decision": "confirm",
  "reason": "Median refinement duration decreased by 34% across n=24 sessions with 92% template retention.",
  "evidence_level": "E5",
  "evidence_refs": ["VAL-0019", "RES-0012"],
  "confidence_change": "+0.25",
  "effective_release": "R-2026.11"
}
```

### Template C: `PositionClaim` Record

```yaml
position_claim_id: PCL-0003
target_icp: "ICP-0002 (Solo & seed-stage technical PMs)"
core_problem: "Unbounded AI-generated specs create unverified backlog sprawl."
promised_outcome: "Compile-time schema and test-matrix verification before sprint admission."
exclusions:
  - "Not an autonomous code-generation agent"
  - "Does not replace human customer interviews (E2)"
evidence_level: "E4"
falsification_condition: "Fails if setup overhead exceeds 20 minutes per release cycle."
```

## 4. Value Testing Checklist

- Every test specifies its target **Evidence Ladder tier (`E0`–`E6`)** before execution begins.
- Sample size (`n`), time window, and measurement instrument are declared in advance.
- Both a **success threshold** and an explicit **falsification condition** are written before collecting data.
- The cycle concludes with one of the six terminal decisions (`confirm`, `refine`, `reject`, `pivot`, `pause`, `kill`) and a recorded `MutationEvent`.