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 Tech 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 Tech Lead.

# Tech Lead lens: Value Dashboard™

Your move: instrument for evidence by design, and treat tech debt as measurable value friction.

## The narrative for your role

Whether a feature moved a signal can only be answered if someone made the signal readable, and in most teams that someone is the tech lead. AI can write the event-tracking boilerplate in seconds; it cannot tell you which signal the hypothesis needs, where it will be read, or what the team will do when it is red. Asking "which signal must move, and how will we see it?" before choosing the design puts you one level above the code.

## How measurement plays out in your day

- Design review: add two items to the checklist, "which signal does this change move?" and "where do we emit the evidence?"
- Definition of Done: add instrumentation, so a story is not finished until its signal can be read.
- Friction as a first-class signal: tech debt, slow builds, flaky tests, manual deploy steps and on-call load all lower Value, because Value = (Expected Impact x Actual Impact) / Friction. Give them numbers: hours lost per sprint, incidents per month, lead time for a change.
- Debt decisions framed in value: "this shortcut saves two days now and adds an estimated X hours per sprint of friction on signal Y" is a decision the Product Owner can weigh. "The code is messy" is not.

## You own / you influence

- You own: instrumentation design, emit points and data quality of technical signals, friction measurement for the codebase, the technical share of the Done definition.
- You influence: which signals the product chooses (what is feasible and cheap to measure), the privacy posture of what is collected, how debt competes with features for capacity.

## The sharpest questions

1. What is the one signal this change is meant to move, and in which line of code or system will we see it?
2. Is there a cheaper way to get the same evidence than the instrumentation we are about to build?
3. What is the baseline, and can we capture it before the change ships?
4. What friction does this design add (manual steps, dependencies, new moving parts), and how will we measure it?
5. Which piece of tech debt is demonstrably slowing the signal we care about, and what is the evidence?
6. What do we deliberately not collect, for privacy, and does the signal still work?
7. If the signal does not move, will the telemetry help us understand why, or only that?
8. Would the design be different if we first asked who is affected and what changes for them?

## Artifact and where it lives

A short instrumentation plan appended to the design note or ADR (signal, emit point, event or log name, baseline method, owner), plus a friction register in the repository next to the code (item, measured cost, signal affected). The plan lives in version control so it is reviewed with the change; the friction numbers feed the Product Owner's dashboard.

## Three erosion patterns and a fix

- Telemetry as an afterthought. The feature ships, then someone asks how to know it worked. Fix: instrumentation is part of the story's acceptance criteria and reviewed in the pull request.
- Debt without a price. Refactoring competes with features on instinct alone. Fix: attach a measured friction figure and the signal it blocks to every debt item before asking for capacity.
- Over-measuring. Thirty events, none tied to a hypothesis. Fix: for each event name the decision it informs; delete those with no answer.

## Who to involve

Product Owner (hypothesis and signals), QA Lead (post-release checks), Solutions Architect and Engineering Manager (cross-cutting standards), developers (emit points), and whoever owns privacy and data protection.

## Your first 15 minutes

Open the story or change you are reviewing today. Ask the author one question: "If this works, what number moves, and where would I look?" If the answer is unclear, add one line to the design note naming the signal and the emit point, even if the emit point is just a log line or a manual observation protocol. That single line is the start of the evidence route.

3. Get it

Install

Did you use it?