Value Dashboard™

Design the evidence path and read the results of what you shipped.

1. Pick your role

2. Preview

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

---
name: value-dashboard
description: "Value Dashboard™ by VDS™: design the evidence route for a Quick Value Release (QVR) and read results honestly. Use when someone wants to know how to measure a feature or initiative, which KPIs to track, what to show in a sprint review or status report, whether something worked, what counts as evidence, or whether to persevere, pivot or stop. Adapts to the user's role (project manager, delivery manager, scrum master, product owner, business analyst, tech lead, architect, engineering manager, QA lead, developer)."
---

# Value Dashboard™

A project dashboard tells you how the team is performing. A Value Dashboard™ tells you whether the business is changing. This skill helps you design the evidence route before you build, and read the results without fooling yourself afterwards.

It is one pillar of the Value Design System™ (VDS™). Value is designed, not reported after the fact: if no impact was designed, there is no impact to show.

## Step 1: check the prerequisites

This skill works best once a hypothesis and a Quick Value Release (QVR) exist, because the dashboard measures whether that hypothesis held. Ask for:

1. The impact hypothesis, in the standard format: "We believe that by implementing [X], we will achieve [Y], which will move [Z] metric in [N] time."
2. The QVR: the smallest delivery that moves a real business metric.
3. At least one KPI baseline: where the metric stands today.

If there is no hypothesis or QVR yet, offer to build them first (Value Architecture Canvas™, then QVR). Do not block: draft the hypothesis yourself, label it E0 and ask the user to confirm it.

If there is no baseline, the first deliverable is to measure it. Say so plainly. Until a baseline exists, any "improvement" claim is an assumption. Label the whole dashboard E0 and put "capture baseline" as the first row of the plan.

## Step 2: choose indicators by type

A Value Dashboard™ organizes evidence in a few views. The template that accompanies VDS has five: Impact, Friction, Risk, Learning and System Health. The core of this skill is the first five rows below (the Impact view is split into Business KPI, Impact KPI and Impact view); Risk and System Health complete the template. Pick the minimum set, usually one or two signals per type, not a long list.

| Type | Question it answers | Example shape |
|---|---|---|
| Business KPI | Is the business outcome moving? | Conversion, cost per transaction, retention, cycle time of a business process |
| Impact KPI | Is the QVR itself changing user or process behavior? | Share of users who complete the new flow, minutes saved per task, errors per week |
| Impact view | What does the change look like in context? | A before/after table or trend, a short user observation, a case walk-through |
| Friction | What is it costing us to get this value? | Manual steps added, support tickets, rework, tech debt created, wait time |
| Learning | What did we find out, including from failure? | Hypotheses confirmed or invalidated, assumptions retired, open questions |
| Risk | What could still erode the value, and how likely is it? | Risk description, type (technical, operational, decision), probability, impact, mitigation, status |
| System Health | Is the team or system behind the QVR in good shape to keep delivering? | Signal, indicator and a green / yellow / red status for the team or system, with the risk and the action |

Who reads what: the Value Dashboard™ has three layers. The executive layer (sponsors, directors) sees the main business metric, the active QVR, expected versus real impact, key risks and early expansion signals, and answers "do we keep investing, adjust or stop?". The leadership layer (Impact Owner, Value Facilitator, Technical Value Leader, Strategic Tech Advisor) sees the ranked QVRs, estimated ROI, friction, decisions and learning. The operational layer (delivery teams) sees stories and tasks per QVR, progress, quality, instrumentation and technical dependencies. Do not push operational detail up to the executive layer.

Rules of thumb:

- Business KPIs move slowly and are influenced by many things. Impact KPIs move first and are closer to your QVR. Use both, and say which you can attribute to the delivery and which you can only correlate.
- Always include at least one Friction signal. Value = (Expected Impact x Actual Impact) / Friction. It is a decision heuristic, not a formula; a dashboard with no friction signal hides half of it.
- Always include at least one Learning signal. A negative result with documented learning is progress.
- Include at least one Risk entry. Delivery metrics (velocity, burndown, bugs) belong, if anywhere, under System Health as supporting context, never as the headline.

## Step 3: signals, not vanity metrics

A Value Signal is an observable data point showing that what was delivered is producing the expected impact. If you cannot name the signal, you cannot claim the value.

A metric is suspect if:

- It goes up whatever happens to the business (features shipped, story points, tickets closed, page views with no action).
- Nobody would change a decision if it went the other way.
- It is not linked to a sentence in the hypothesis ("which will move [Z]").
- It measures team activity rather than a change for a user, the business or someone's life.

Replacement move: for each suspect metric ask "What would we do differently if this moved?" and "Which part of the hypothesis does it test?" Keep it only if there is a good answer, or demote it to context.

Delivery metrics (velocity, burndown, defect counts) are not forbidden. They are supporting context on the dashboard, never the headline.

## Step 4: the evidence ladder

Every signal declares its target level and, later, the level actually reached.

| Level | Name | What it is | Example |
|---|---|---|---|
| E0 | Assumption | Belief without evidence | "Users will want this" |
| E1 | Qualitative signal | Feedback, observation, testimonial | 3 users say they would use it, and why |
| E2 | Observed behavior | Someone did something | 5 users completed the flow unaided |
| E3 | Proxy metric | A number that moves with the value | Share of searches resolved in under a minute |
| E4 | Business metric | Revenue, cost, retention | Cost avoided, paid renewals |

Rules:

- Never present E0 as E2. Always label the real level.
- Raise the level when it is cheap to do so. Do not over-invest in measurement.
- Intangible value can legitimately stay at E1 to E3.
- A QVR with no evidence route, even an E1 one, is not ready to build.

## Step 5: small-sample honesty

Most delivery teams have few data points: a handful of users, one sprint, two weeks of data. Be explicit about what that allows.

What a small sample CAN tell you:

- Whether something is possible (it happened at least once).
- Which problems are blocking people (one observed failure is a real failure).
- A direction worth testing next, labeled as a lead, not a result.

What it CANNOT tell you:

- That an effect is real, stable or general. Three users is E1, not E3.
- How big the effect is. Do not quote percentages from tiny counts without showing the counts.
- Causation. Ask what else could have moved the signal: seasonality, a campaign, a staffing change, another release.

Habits to apply every time:

1. Show the raw count next to any percentage ("4 of 6", not "67 percent").
2. State the comparison: against baseline, against a control group, or against nothing (then say "no comparison").
3. List confounders before celebrating.
4. Write the threshold for success and failure BEFORE the data arrives. Reading results against a threshold set afterwards is storytelling.
5. Use words that match the evidence: "suggests", "is consistent with", "we observed" for low levels; "demonstrates" only for E3 or E4 with a stated comparison.
6. Never present an assumption as a fact. If it is not measured, it is E0 and it says so.

## Step 6: intangible value

Not all value is a business number. If you cannot measure it, observe it; if you cannot observe it either, it is still a hope. Intangible is never an excuse to skip evidence; it is a reason to choose different signals.

Pick one primary value dimension and at most two secondary ones: revenue growth, operational efficiency, customer or user impact, capability and learning, trust and authority, human and social impact, strategic optionality.

For intangible dimensions, define an observation protocol, for example: "Hold 5 short conversations with question X. Success if at least 3 mention Y without being prompted." Record who observed, when, and with what wording. Spontaneous behavior beats stated opinion.

## Step 7: output 1, the one-page dashboard spec

Produce this artifact. One page, copy-pasteable.

```
## Value Dashboard™: [initiative or QVR name]
Role lens: [role]   Date: [date]   Owner of the dashboard: [name or role]
Hypothesis: We believe that by implementing [X], we will achieve [Y], which will move [Z] metric in [N] time.
Primary value dimension: [one]   Secondary: [up to two]

| # | Type | Signal | Baseline | Target | Success / failure threshold | Source | Cadence | Target level | Owner |
|---|------|--------|----------|--------|-----------------------------|--------|---------|--------------|-------|
| 1 | Business KPI | | | | | | | E_ | |
| 2 | Impact KPI | | | | | | | E_ | |
| 3 | Impact view | | | | | | | E_ | |
| 4 | Friction | | | | | | | E_ | |
| 5 | Learning | | | | | | | E_ | |
| 6 | Risk | | | | | | | E_ | |
| 7 | System Health (optional) | | | | | | | E_ | |

Baseline status: [measured on date / not measured: first action is to capture it, level E0]
Decision date: [when we read this and choose persevere, pivot or stop]
Minimum instrumentation: [event, log, counter, one-question feedback or observation protocol]
Privacy note: [what is collected, what is deliberately not]
```

Keep the instrumentation minimal and respectful of privacy: collect what the signal needs and nothing more, especially when minors or personal data are involved.

## Step 8: output 2, the results read-out

When data or observations arrive, produce this read-out.

```
## Results read-out: [initiative or QVR name]   Period: [dates]
1. Result vs threshold (set beforehand): [signal, result, threshold, met or not met]
2. Evidence level reached: [E_ actual, not desired]   Sample: [counts]
3. Confounders: [what else could explain it]
4. Friction paid: [what it cost: manual steps, tech debt, tickets, rework]
5. Value Gap: promised [..] vs evidenced [..] ; gap = [..]
6. One-sentence learning: [..]
7. Recommendation: Persevere | Pivot | Stop, because [evidence]
8. Decision needed from the Impact Owner: [concrete question]
```

## Step 9: reading results, persevere, pivot or stop

- Persevere: the signal moved as per the threshold. Next QVR on the same hypothesis.
- Pivot: there was learning, but the hypothesis does not hold as stated. Write a new hypothesis.
- Stop: no signal and no relevant learning. Free the capacity.

Give the recommendation with its evidence level. The decision belongs to the person who owns the impact. A negative result with documented learning is not a failure; hiding it is.

Apply The Renewal Test: "If this were up for renewal tomorrow (the contract, the funding, the team's mandate), what specific impact could we demonstrate with data?" Answer only with evidence from the read-out. A team passes the test because it measured impact during the work, not because it prepared a case at the last minute. If the honest answer is "we do not know", the finding is a measurement gap, and the next QVR is to close it.

## The Value Gap

The Value Gap is the distance between the impact that was expected when the work was commissioned and the impact that was actually generated and evidenced. It can exist while stakeholders are satisfied, sprints are completed and the relationship is good. Satisfaction does not close it.

Make it explicit on every read-out: promised, evidenced, gap, and what you believe explains it. Where the gap is large and there is little evidence, the honest statement is "unproven", not "failed".

## Erosion patterns to name when you see them

- Dashboards of activity under a "value" title: a report with more columns is not a Value Dashboard™. Replace the headline with a signal tied to the hypothesis.
- "Done" treated as "created value": separate technical Done from value done.
- Several deliveries with no evidence read: propose a short review before building more.
- "It is intangible, it cannot be measured": apply the rule above and pick an observable signal.
- Metrics chosen after the fact: fix thresholds before data.

## Closing

End with the next decision: what evidence is expected, when it will be read, and what will be done depending on the result. Then point to the next pillar: once a QVR is delivered and validated, the Software Expansion Loop™ turns what was found into the next hypotheses.

## Role lens

The user's role is Delivery Manager / Delivery Lead.

# Delivery Manager / Delivery Lead lens: Value Dashboard™

Your move: run a value review with your sponsor or client, show evidence rather than activity, and pass The Renewal Test every quarter instead of the week before a decision.

## How measurement plays out in your day

You sit between teams that deliver and stakeholders who judge. They judge on what they can see. If what they see is velocity and hours, they will evaluate you on effort and cost, because you never gave them a reason to evaluate impact.

The Value Dashboard™ changes the shared conversation. The recurring value review, monthly or at each QVR boundary, has a fixed shape:

1. What we said would change (hypothesis, baseline, target).
2. What changed, at what evidence level, with counts.
3. What it cost in friction (rework, tech debt, manual steps, support load).
4. The Value Gap: promised vs evidenced, stated without defensiveness.
5. Recommendation: persevere, pivot or stop, and the decision needed.

A pivot or stop recommendation, backed by evidence, builds more trust than a green report that later collapses.

## You own / you influence

- You own: the value review as a ritual, the cross-team consistency of dashboards, the honesty standard for reporting, the sponsor relationship around evidence.
- You influence: which hypotheses get a QVR, whether baselines are agreed in the contract or charter, whether delivery teams instrument for evidence, and what the sponsor considers a good result.

## The sharpest questions

1. If the sponsor were asked today what changed in the business because of our work, what would they say, and would the evidence agree?
2. Are we being evaluated on effort and cost because we never offered another metric?
3. Which of our teams has a hypothesis with a baseline, and which only has a backlog?
4. What is the Value Gap on our largest engagement right now, and does the sponsor know about it?
5. Which recommendation would I make if I had to stop one stream of work this month based on signals alone?
6. Do the dashboards across my teams use comparable evidence levels, or does each team inflate differently?
7. Would we pass The Renewal Test today with what is written down, not what we remember?
8. What did a delivery teach us that the sponsor does not yet know?

## Artifact and where it lives

The one-page Value Dashboard™ spec per active QVR, and a value review read-out per cycle. Keep them in the engagement's shared workspace, visible to the sponsor, not in an internal-only folder. Maintain a single index page: one line per hypothesis, current signal, level, decision date. This index doubles as the evidence file when a renewal or extension conversation arrives.

## Three erosion patterns and a fix

- Activity decks in value clothing. Slides of sprints completed and tickets closed. Fix: lead every review with a signal tied to the hypothesis; move delivery metrics to an appendix slide.
- Satisfaction mistaken for impact. The relationship is good, so no one checks the outcome. Fix: ask for the Value Gap line in every review; a happy sponsor with a large unexplained gap is the highest-risk situation.
- Last-minute value case. The renewal case is assembled in the final weeks from memory. Fix: keep the index current each cycle so the case already exists.

## Who to involve

The sponsor or Impact Owner (decisions and thresholds), Project Managers and Product Owners on each stream (signals), a data or operations contact on the business side (baselines), and your Tech Lead or Engineering Manager (instrumentation and friction signals). Involve the sponsor early on thresholds so a negative read is a shared learning, not a surprise.

## Your first 15 minutes

Pick your largest engagement. Write one sentence on what the sponsor expects to change, and one honest line on what you can currently evidence, with the level (E0 to E4). If those two lines are far apart, that is the Value Gap. Schedule a 30-minute value review with the sponsor in the next two weeks and bring only that: the promise, the evidence, the gap, and one decision.

3. Get it

Install

Did you use it?