Quick Value Release (QVR)

Cut a large scope down to the smallest release that moves a real signal.

1. Pick your role

2. Preview

This is the full SKILL.md for Product Owner / Product Manager: the base instructions plus your role lens.

---
name: quick-value-release
description: Design a Quick Value Release (QVR), the smallest delivery that moves a real business metric in 7-14 days. Use when a scope is too big, when slicing a roadmap item or epic, when someone says "MVP", when planning a sprint, or when you ask how to deliver value faster. Checks that an Impact Hypothesis exists, and produces a QVR card with signal, scope in/out, evidence route and a persevere / pivot / stop rule.
---

# Quick Value Release (QVR)

A QVR is a unit of delivery of 7 to 14 days, designed to test one specific business hypothesis against a real metric: the smallest delivery that moves it. It is not a smaller release, a faster sprint or an incomplete MVP. It is an explicit bet: if we build X, metric Y should move by Z, and we will know by a date we chose in advance. A QVR ends with evidence, not with features.

A QVR does not end when the feature ships. It ends when the hypothesis is answered.

This skill is part of the Value Design System™ (VDS™). It sits after the Value Architecture Canvas™ (which produces the Impact Hypothesis) and before ROI Sprint Planning™ (which ranks competing QVRs).

## Step 1 - Prerequisite check: is there a hypothesis?

A QVR is only as good as the hypothesis it tests. Before slicing anything, ask for the Impact Hypothesis in this form:

> We believe that by implementing [X], we will achieve [Y], which will move [Z metric] by [amount] in [time].

Three outcomes:

- **The user has one.** Restate it back in one sentence and continue.
- **The user has something close** (a goal, a request, a feature name). Help them sharpen it into the format above, then confirm it with them. The words and the numbers are theirs.
- **The user has none.** Do not invent one. Say so plainly, and offer two paths: build the Impact Hypothesis together now (a short set of questions: who is affected, what changes for them, which metric moves, by how much, by when), or point them to the `value-architecture-canvas` skill if the initiative needs the full structure conversation with stakeholders. Do not slice work that has no hypothesis behind it: you would be shrinking a feature, not designing a QVR.

If any number is a guess, label it as an assumption (E0) in the card. Never present a guess as a fact.

## Step 2 - Method

Work through these in order. Keep it a conversation: one or two questions at a time, then draft.

### 2.1 Identify the signal to move

Which single metric, if it moved, would tell us the hypothesis is right? Prefer a signal that:

- is a behavior or an outcome, not an activity (users completing a flow, minutes per process, errors per week, tickets per month, renewals), not "story points" or "features shipped"
- the team can read within the QVR window
- is tied to the primary value dimension of the initiative

Capture the **baseline** (where it is today, with the source) and the **target** (where it should be, by when). No baseline means the QVR cannot show movement: the first task becomes finding or capturing one.

If the value is intangible (trust, confidence, learning, capability), choose an observable signal instead of forcing a financial number. The rule: if it cannot be measured, it can be observed; if it cannot be observed, it is not yet value, it is hope.

### 2.2 Find the minimum that moves it

Ask: "What is the least we could build, change, remove or switch on that would plausibly move this signal?" Try these cuts, in this order:

1. **Remove a step** instead of adding a feature.
2. **One segment, one flow, one site, one report** instead of all of them.
3. **Manual or rules-based first**, automate after the signal moves.
4. **Configure or reuse** before building.
5. **Show it to real users in the real context**, not a demo.

The test for "enough": if this shipped alone, could someone see the signal move? If the honest answer is no, the slice is too thin: it is an MVP that moves nothing.

### 2.3 Decide what is OUT

Write the exclusions as explicitly as the inclusions. Every item left out is named, with where it goes (backlog, next QVR, expansion). A QVR without an out-of-scope list is a wish list. Scope creep during the window is a decision to renegotiate the card, not to quietly absorb.

### 2.4 Fit the window: 7-14 days

Estimate delivery plus the time to read the signal. If it does not fit 14 days, cut again by repeating 2.2. If the signal needs longer than the window to move (for example a monthly metric), choose a leading indicator that moves sooner and say which one it is. A QVR that cannot be read inside its window is a project in disguise.

### 2.5 Design the evidence route before building

Decide now, not afterwards:

- **How** the signal will be read (an event, a report, a query, a survey question, a structured observation).
- **When** it will be read, and by whom.
- **What evidence level** the QVR can reach, using the Evidence Ladder:

| Level | Meaning | Example |
|---|---|---|
| E0 | Assumption, a belief without evidence | "Users will want this" |
| E1 | Qualitative signal: feedback, observation | 3 users say why they would use it |
| E2 | Observed behavior: someone did something | 5 users completed the flow unaided |
| E3 | Proxy metric moving | % of searches resolved in under a minute |
| E4 | Business metric moving | Revenue, cost, retention |

State the target level honestly. Do not present E0 as E2. Intangible value can legitimately stop at E1-E3. If the QVR has no evidence route, even E1, it is not ready to build.

### 2.6 Success and failure criteria, decided up front

Write the decision rule before any code exists, so the result cannot be bent afterwards:

- **Persevere** if the signal reaches [threshold].
- **Pivot** if the signal moves but less than [threshold], or moves a different metric: change the approach or the segment.
- **Stop** if the signal does not move beyond [noise level] by [date].

Stopping is a valid, valuable outcome: it is learning bought cheaply.

### 2.7 Risks and dependencies

List what could stop the window being met: people, approvals, data access, environments, other teams, vendor lead times, decisions pending. For each, name an owner and a mitigation or an early check. Anything with a lead time longer than the window either moves out of the QVR or becomes the first task.

## The anti-pattern: the MVP that moves nothing

Watch for these and name them kindly when you see them:

- The slice is "the first screen" or "the backend", valuable only when everything else exists.
- The signal is delivery progress ("done by Friday"), not business movement.
- There is no baseline, so no movement can be shown.
- The evidence route is "we will check later".
- The thresholds are decided after the data arrives.
- The out-of-scope list is empty.
- It is a large feature with a short deadline (a sprint, not a QVR).

The correction is always the same: return to 2.1 and 2.2. Which signal, and what is the least that moves it?

## Output: the QVR card

Produce the card in this format, adapted by the role's lens (the lens says which sections to stress, and in which artifact it lives). Keep it to one page.

```
## QVR Card: [short name]

Linked hypothesis   : We believe that by [X], we will achieve [Y], which will move [Z] by [amount] in [time].
Owner               : [name or role]          Validation window: [start] to [end] (7-14 days)

Target metric       : [the one signal]
Baseline            : [value, source, date]   (or "unknown - first task: capture it")
Target              : [value by date]         Evidence level aimed at: E[0-4]

Minimum scope (IN)  : [the smallest delivery that can move the metric, in a few lines]
Scope OUT           : [what is explicitly not delivered, and where it goes]

Evidence to collect : [what data will prove success or failure] / [when] / [who reads it]
Effort              : [days or 1-10 score, with the main assumption behind it]
Risk reduced        : [the key risk this QVR retires]
Risks / dependencies: [item - owner - mitigation]
Assumptions (E0)    : [guesses stated as guesses]

Decision rule (set before building):
  Persevere if ...
  Pivot if ...
  Stop if ...
```

## After the card

Close with three short lines: the one thing that most threatens the card, the first action in the next 24 hours, and the next step in the sequence. If there are two or more candidate QVRs competing for attention, the next step is ROI Sprint Planning™ (the `roi-sprint-planning` skill). When the QVR has been delivered and read, the next step is the Value Dashboard™ and the Software Expansion Loop™.

## Working rules

- The user decides. You provide structure, questions and a draft. Offer a recommendation and one alternative, with the trade-off.
- Tie every answer back to a business signal. If a request cannot be traced to one, say so and ask what it is for.
- Be honest about uncertainty. Label guesses as E0. Never invent baselines, benchmarks, statistics or customer examples.
- Keep process proportional. For a small change, a three-line card is enough: signal, minimum, decision rule.

## Role lens

The user's role is Product Owner / Product Manager.

# Lens: Product Owner / Product Manager - Quick Value Release

## How a QVR plays out in your day

You own the hypothesis and the order of the work. Requests arrive as features; your job is to turn each into a bet on a metric. The QVR is the form that bet takes when it needs to be delivered and read in 7-14 days.

You are the person who can say "no, not yet" with a reason. The QVR card is that reason in writing: this slice, this signal, this decision rule, and these things deliberately out.

## What you own vs what you influence

**You own:** the Impact Hypothesis, the QVR card, the ordering of QVRs, the acceptance of what is delivered, and the call to persevere, pivot or stop (with the sponsor).

**You influence:** engineering estimates, instrumentation, stakeholder expectations, release sequencing, and the roadmap narrative. You do not own the capacity (managers do) or the technical approach (the team does).

## The sharpest questions

1. "What is the behavior we expect to change, and in whom?"
2. "Which metric moves first, and what is its baseline today and where does it come from?"
3. "What is the smallest thing we can ship that a real user will use in the real context?"
4. "What are we saying no to in this QVR, and where does each 'no' live?"
5. "What threshold means persevere, which means pivot, and which means stop?"
6. "How many users or events do we need to see before the signal means anything?"
7. "Which part of this feature exists because someone asked for it, and which because the hypothesis needs it?"
8. "If this QVR fails, what will we have learned that the next one needs?"

## The artifact you produce, and where it lives

The full **QVR card**, kept in your product workspace next to the roadmap item it slices (the backlog tool, the product wiki or the planning doc). The roadmap item links to the card; the card links to its Impact Hypothesis. After the read date, add a short "result" section to the same card: signal reached, level of evidence, decision taken.

Roadmaps should show QVRs and their signals for the next cycle, and themes for later; avoid dated feature lists beyond the window you can read.

## Erosion patterns to watch

1. **The roadmap is a feature list.** Items have names but no signal. Fix: make "signal and baseline" a required field before an item enters the next cycle.
2. **The MVP that moves nothing.** A first version ships and no metric could respond. Fix: ask whether it could move the signal alone; if no, add the one missing piece or pick a different slice.
3. **Result without decision.** The QVR is read and the team moves on to the next item. Fix: record persevere, pivot or stop on the card the day it is read, with one line of why.

## Who to involve

The sponsor or business owner (confirms the metric and the decision rule), the tech lead or a senior developer (tells you what is truly small), a designer or user contact (for the real-context test), the analytics owner (baseline and evidence route), and a business analyst if the process behind the metric is complex.

## First 15 minutes

Pick the top item on your backlog. Write: "We believe that by [slice], [users] will [behavior], which will move [metric] from [baseline] to [target] in [days]." Then write three things it deliberately does not include. If you cannot name the baseline, send one message today to whoever owns that data. That message is the first task of the QVR.

3. Get it

Install

Did you use it?