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 Product Owner / Product Manager: 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 Product Owner / Product Manager.

# Product Owner / Product Manager lens: Value Dashboard™

Your move: read signals to reorder the backlog. Every item is a hypothesis; the dashboard tells you which hypotheses are earning their place.

## How measurement plays out in your day

Your backlog is a queue of bets. Without evidence the order reflects who asked loudest, last or most senior. The Value Dashboard™ gives you a second input to ordering: what the signals say about what already shipped.

A practical weekly rhythm:

1. Read the signal for each released item against the threshold set before release.
2. Mark each hypothesis: confirmed, not confirmed, inconclusive, not yet readable.
3. Move work up when it extends a confirmed hypothesis or removes friction that blocks the signal. Move work down when its parent hypothesis is not confirmed. Remove it when a stop condition is met.
4. Add a Learning line: what do we now believe that we did not believe last month?

Distinguish two kinds of indicators when you decide. An Impact KPI (users completing the new flow) tells you quickly whether the change works. A Business KPI (retention, revenue) tells you whether it matters, slowly and with many confounders. Do not wait for the slow one to act on the fast one, and do not claim the slow one on the strength of the fast one.

## You own / you influence

- You own: the hypothesis for each item, the signal and threshold, the ordering of the backlog, the persevere, pivot or stop recommendation for your product area.
- You influence: whether the team instruments its work, whether stakeholders accept a negative result as learning, how much capacity goes to friction removal.

## The sharpest questions

1. For each of the top ten items, what is the hypothesis and which signal would move?
2. What did the last release actually do to its signal, and where is that written?
3. Which items on the backlog survive only because someone senior asked for them?
4. Which confirmed hypothesis has no follow-up item, and which unconfirmed one still has three?
5. What is the baseline for the metric my roadmap claims to move?
6. Is my best-performing metric a signal tied to the hypothesis, or a vanity number that always rises?
7. What would make me stop this stream of work, and have I written that threshold down?
8. What does the sample actually allow me to conclude: possible, probable, or only a lead?

## Artifact and where it lives

A hypothesis column and a signal column added to the backlog itself, plus a Value Dashboard™ one-pager per active QVR, and a short "evidence log" (date, hypothesis, reading, level, decision). Keep all three where the team plans, so the evidence is next to the work it justifies. The evidence log is also what you bring to stakeholder prioritization conversations.

## Three erosion patterns and a fix

- Feature factory. Items shipped with no hypothesis or signal. Fix: do not admit an item to the next sprint without a one-line hypothesis and the signal that will tell you.
- Success theater. Adoption of a feature is reported as proof of value although it only measures clicks. Fix: tie each adoption number to the behavior or outcome it is supposed to produce, or demote it to context.
- Orphaned results. A hypothesis is not confirmed and the item stays on the roadmap because it was announced. Fix: schedule an explicit persevere, pivot or stop decision, and treat "pivot with learning" as a normal outcome.

## Who to involve

Business Analyst (outcome traceability), Scrum Master (review and retro), developers and Tech Lead (instrumentation), a data or operations contact (baselines), the sponsor or business owner (thresholds, stop decisions), and a few real users for E1 and E2 evidence.

## Your first 15 minutes

Take the top five backlog items. For each, write the hypothesis in one line and name the signal and baseline. Mark any item where you cannot do that as "no hypothesis (E0)". Pick the one with the largest effort and the weakest hypothesis and ask the team what the smallest test would be. Do not reorder yet; first see how many items cannot be justified.

3. Get it

Install

Did you use it?