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 Project / Program 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 Project / Program Manager.

# Lens: Project / Program Manager - Quick Value Release

## How a QVR plays out in your day

You are handed a scope, a budget and a date, usually before anyone has said which business metric should move. Your plan is probably organized around deliverables and milestones, and "on track" means "on plan". A QVR gives you a second, sharper way to plan: in the first two weeks, what is the smallest piece of the program that moves a real number, and how will we know?

For you, the QVR is also the best defense of scope. A program that can show an early signal moving earns the credibility to sequence the rest. A program that shows only milestone completion has to defend every change request on opinion.

## What you own vs what you influence

**You own:** the schedule, the scope baseline, the change-control process, the risk and dependency log, status reporting, and the sequencing of work packages.

**You influence:** which metric the program is judged on, the benefits timeline, what the sponsor treats as success, and how early evidence is read. You do not own the business metric; the sponsor or business owner does.

## The sharpest questions

1. "If we delivered only 10 percent of this scope, which 10 percent would move a number the sponsor cares about?"
2. "What does the business case promise, and in which month does the benefit start? Why not earlier?"
3. "Which work package has the longest lead time (approvals, procurement, access, environments), and does the first QVR need it?"
4. "Who confirms the baseline today, and where is it recorded?"
5. "What would the sponsor have to see in 14 days to say this program is working?"
6. "What is the change-control answer when someone asks to add scope to the QVR window?"
7. "If the signal does not move, who has agreed in advance that we pivot or stop?"
8. "Which milestone in the plan has no signal attached to it?"

## The artifact you produce, and where it lives

A **QVR card** per slice, kept next to the program plan (the schedule tab, the benefits register or the program wiki), and referenced from the status report. The milestone plan stays; each early milestone gets the QVR's signal, baseline, target and read date beside it. Add one row to the risk log per QVR dependency.

In the status report, add one line per QVR: "Signal: [name], baseline [x], now [y], target [z], read on [date]."

## Erosion patterns to watch

1. **Green status, flat signal.** Every milestone is on time, and the business metric has not moved. Fix: add a signal and a read date to each milestone that claims to deliver value; report both colors.
2. **The benefits arrive at the end.** All value is scheduled for the final phase, so a late slip destroys it all. Fix: pull one slice forward as the first QVR and put the benefit timeline in the plan.
3. **Scope absorbed in silence.** Change requests are accepted to keep a stakeholder happy while the QVR window slips. Fix: any addition inside the window is a card renegotiation, with the trade-off named in the change log.

## Who to involve

The sponsor or business owner (owns the metric and the pass/fail rule), the person who can produce the baseline (finance, operations, analytics), the product or process owner for the affected area, and one delivery lead who can say what fits in 7-14 days. Bring the risk owners for the top dependencies.

## First 15 minutes

Open the program plan. Pick the first milestone that claims business value. Write one line under it: "This moves [metric] from [baseline] to [target] by [date], read by [who]." If you cannot finish the line, you have found the conversation to have with the sponsor today. Then ask: "What is the smallest slice of this milestone that could move that number inside 14 days?"

3. Get it

Install

Did you use it?