Software Expansion Loop™

Turn the evidence from a release into the next hypotheses worth pursuing.

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: software-expansion-loop
description: "Software Expansion Loop™ by VDS™: turn each delivered Quick Value Release (QVR) into the next evidence-based opportunities. Use after a release, in a retrospective or QVR review, when someone wonders what comes next, when planning a roadmap, or before a conversation with a sponsor, stakeholder or client about the next phase. Requires at least one delivered and validated QVR; positive and negative evidence both count. Adapts to the user's role (project manager, delivery manager, scrum master, product owner, business analyst, tech lead, architect, engineering manager, QA lead, developer)."
---

# Software Expansion Loop™

Expansion is not what you ask for. It is what the data earns. This skill converts each delivery into 2 or 3 additional strategic opportunities, grounded in what the delivery actually produced, and feeds them into the next Value Architecture Canvas™ and Quick Value Release (QVR) cycle.

It is not a sales tactic, not account management and not a wish list. It is an evidence loop: each delivery that produces measurable impact feeds the next conversation about expanding scope, which opens more opportunity, which produces more impact. It is activated by accumulated data, not by one conversation. In short: delivered, observed, learned, next hypothesis.

The loop is operated through the Expansion Review: a short strategic ritual held after one or more successful QVRs and before committing new investment (the Professional Guide places it monthly in the VDS cadence). It answers four questions: what impact was demonstrated, what friction appeared as a result of growth, what new opportunities of value are now enabled, and which new QVR could capture them. Its output is a new Impact Hypothesis, not a vague promise.

## Step 1: check the prerequisite (strict)

The loop requires at least one QVR that was DELIVERED and validated, meaning it went live (or was completed) and someone looked at the evidence. Ask:

1. Which QVR was delivered, and when?
2. What was the hypothesis, and what did the Value Dashboard™ or any other evidence show?
3. Is there any evidence at all, even qualitative?

Both outcomes count. A QVR that confirmed its hypothesis, one that did not, and one that was inconclusive all produce expansion signals. A hypothesis that was invalidated is often the richest source of the next one.

If no QVR has been delivered: do not generate opportunities. Say: "The Software Expansion Loop™ extracts new opportunities from real delivery evidence. It needs at least one delivered and validated QVR. Once your first QVR is out and you have looked at the evidence, this pillar unlocks." Then offer the nearest useful step: finishing the QVR, or designing its evidence route with the Value Dashboard™ skill.

If a QVR is delivered but nobody has read any evidence, the first task is a short evidence read-out, not expansion. Label what is known as E0 or E1 and do the read-out first.

## Step 2: harvest expansion signals

An Expansion Signal is an observable fact from the delivery that suggests more value is available. It is not "the stakeholder is happy" and it is not "it would be great if". It is evidence that more is justified.

Look in these places and write down only what was actually seen:

| Source | What to look for | Example shape (do not copy, find your own) |
|---|---|---|
| Usage patterns | Where people go, where they stop, what they repeat | A step most users skip; a feature used in an unplanned way |
| Friction found | Obstacles that appeared when the delivery met reality | Manual rework next to the new flow; a slow upstream system |
| Requests | Repeated asks, in the team's or users' own words | The same question raised by several people |
| Adjacent users | Others who showed up or who would benefit | A neighboring team borrowing the output |
| Capabilities unlocked | What is now possible that was not before | A clean data set, an integration, a component, a decision |
| Workarounds | People building their own fixes | A spreadsheet created to cover what the delivery missed |
| Results beyond baseline | Metrics staying above baseline consistently, not once | The signal still holds three readings later |
| Growth pressure | New bottlenecks created by success, requests for more visibility or control, need to scale to other teams or areas | A second team asking to use the same flow |

For each signal capture: what was seen, how many times or how many people, who saw it, the source, and the evidence level (E0 to E4). Friction and workarounds are often the strongest signals because they cost the user something to produce.

Also recover the deferred scope: value that was deliberately left out of the QVR to protect its speed. It is a legitimate candidate, already scoped.

## Step 3: the no-invention rule

No evidence, no signal.

- Do not invent opportunities to fill the table. Two good signals beat five guessed ones. Zero is a valid answer: then the next step is to collect evidence (observe, ask, instrument), not to speculate.
- Do not present an assumption as a signal. If it has not been observed, mark it E0 and keep it out of the ranked list, or in a clearly labeled "to verify" row.
- Do not count politeness or satisfaction as a signal. A satisfied stakeholder who does not connect the result to their next problem has given you no Expansion Signal.
- Do not inflate small samples. "One user asked twice" is E1. Say so.
- Do not jump to building. Expansion feeds the next design cycle; it does not skip it.

## Step 4: turn 2 or 3 signals into next hypotheses

Select the strongest 2 or 3 signals (by evidence level first, then by how directly they touch a business outcome). For each, write a candidate hypothesis in the standard format:

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

Classify each by type of expansion: functional (new capabilities), scope (more users, regions or clients), technical (scalability, performance, automation) or strategic (new business models or processes). Each expansion is formulated and evaluated as a new QVR candidate.

Add for each: the value dimension (revenue growth, operational efficiency, customer or user impact, capability and learning, trust and authority, human and social impact, strategic optionality), the target evidence level, and the first KPI baseline you would need.

Check each against three questions:

1. Which signal in the table supports this hypothesis? (If none, delete it.)
2. Is it a new problem worth solving, or "more of the same"? "We can do more of the same" is not a reason. "Here is the impact we generated and here is the next problem it revealed" is.
3. Could the smallest version of it move a real signal in 7 to 14 days (a QVR)?

## Step 5: score lightly

Do not build a spreadsheet empire. Use the same arithmetic as ROI Sprint Planning™, at low resolution:

- Potential impact: 1 to 10, based on the signal's evidence and the size of the outcome it touches.
- Estimated effort: 1 to 10, rough.
- ROI = Impact / Effort.
- Add two short notes: risk or dependency, and learning value (does doing it settle an important unknown?).

Track each opportunity with a status that moves as the evidence does (for example Discovered, then Proposed, then decided in ROI Sprint Planning™), the same columns as the Expansion Loop Tracker: opportunity, potential impact, estimated effort, ROI, status, description.

State how confident the score is (tie it to the evidence level of the signal). A high score on E0 evidence is a prompt to go and collect evidence, not to build. When two options are close, prefer the one with the higher learning value and lower friction. Final selection happens in ROI Sprint Planning™ and with the Impact Owner; this step only proposes.

## Step 6: output, the Expansion Signals table plus next hypotheses

Produce this artifact.

```
## Software Expansion Loop™: [initiative or QVR name]
Role lens: [role]   Date: [date]
Delivered QVR: [name, date]   Hypothesis it tested: [..]   Result: [confirmed | not confirmed | inconclusive] at evidence level [E_]

### Expansion Signals
| # | Signal (what was observed) | Source | Count / who | Level | Friction or opportunity | Dimension |
|---|----------------------------|--------|-------------|-------|-------------------------|-----------|
| 1 | | | | E_ | | |
| 2 | | | | E_ | | |
| 3 | | | | E_ | | |

### Deferred scope (left out of the QVR)
- [item, estimated effort, why it was deferred]

### Next hypotheses
| # | Hypothesis (We believe that ... ) | Expansion type | Supported by signal | Impact (1-10) | Effort (1-10) | ROI | Status | Risk / dependency | Learning value | Target level |
|---|-----------------------------------|----------------|---------------------|---------------|---------------|-----|--------|-------------------|----------------|--------------|
| H-a | | | # | | | | Discovered | | | E_ |
| H-b | | | # | | | | Discovered | | | E_ |

### Beyond this initiative
- Reusable asset or pattern: [..]
- Shareable learning (anonymized, only if allowed): [..]
- Other team or initiative it could serve: [..]

### Recommendation and decision needed
Recommended next step: [Canvas update | next QVR on H-_ | collect more evidence on signal #_]
Decision needed from the Impact Owner: [concrete question]
```

## Step 7: feed the next cycle

Close the loop explicitly:

1. Update the Value Architecture Canvas™: new or revised hypothesis, newly known friction, new risks.
2. Define the next QVR candidates and hand them to ROI Sprint Planning™.
3. Design the evidence route for the chosen QVR with the Value Dashboard™ before building. Include the baseline, even if the baseline is "not yet measured".
4. Record the learning, including invalidated assumptions.

A useful cadence: run the loop at each QVR review, not once a year. Small, frequent loops compound; a large annual "opportunity workshop" produces wish lists.

## Using it in a conversation about the next phase

When the conversation is with a sponsor, stakeholder or client, lead with evidence, then the signal, then the proposal, in that order: "Here is the impact the delivery produced and how strongly we know it. Here is what we saw while it ran. Here is the next problem it points to, and the smallest step to test it." Show the evidence level in plain words, for example "we observed this with six users, so we treat it as a lead". Never turn the conversation into a pitch for more of the same.

## Erosion patterns to name when you see them

- Feature wish list: opportunities with no signal behind them. Ask for the observation that supports each.
- Roadmap by request volume: the loudest voice sets the next release. Ask for the signal and the hypothesis.
- Renewal without growth, or growth without evidence: both come from not connecting demonstrated impact to the next problem.
- Learning left behind: negative results and workarounds never reach the next cycle. Put them in the table.
- Scope inflation: "while we are at it" additions. Only marginal-cost extras join the current QVR; the rest go to the next cycle.

## Closing

End with the single next move, who owns it and by when, and the evidence you expect from it. Then return to the start of the sequence: Canvas, QVR, ROI Sprint Planning™, Value Dashboard™, Software Expansion Loop™.

## Role lens

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

# Delivery Manager / Delivery Lead lens: Software Expansion Loop™

Your move: spot next-phase opportunities in the evidence of what you delivered, and bring them to the sponsor as "here is the impact, here is the next problem", not as "we can do more".

## How expansion plays out in your day

You carry the relationship and the delivery. When an engagement renews at the same level for years, the usual cause is that the team waited for the client to propose the next step, or proposed "more of the same". An Expansion Signal is the opposite: evidence from the delivery that more is justified.

The loop is a standing item in the value review, after the Value Dashboard™ read-out:

1. What the delivered QVR evidenced and at what level.
2. What we saw while it ran: usage, friction, requests, adjacent users, capabilities unlocked.
3. The 2 or 3 strongest signals and the hypothesis each suggests.
4. Which one the sponsor wants to explore as a next QVR, and what evidence we will collect.

The conversation moves from account management to shared discovery. You are not selling; you are showing what the data earned.

## You own / you influence

- You own: the account-level view of signals across streams, the next-phase conversation, the choice of which signals to bring and how to present evidence levels.
- You influence: what the sponsor sees as the next problem, how teams record signals as they work, whether expansion proposals are held to the no-evidence-no-signal rule.

## The sharpest questions

1. Which delivered QVR gives us evidence strong enough to talk about, and what level is it?
2. What is the next business problem that evidence points to, in the sponsor's words?
3. Are we proposing more of the same, or a new problem the delivery revealed?
4. What did users or stakeholders do with the delivery that we did not plan?
5. Which friction did the sponsor's own people experience, and have they said it out loud?
6. Which signal in my table could be wrong, and how would I check it?
7. What happens to our proposal if the sponsor's priorities shifted since the last review?
8. Which asset or learning from this engagement can help another, and are we allowed to share it?

## Artifact and where it lives

The Expansion Signals table and next hypotheses as a one-page addendum to the value review pack, plus an account-level index (signal, source, level, hypothesis, status: proposed, in discovery, in QVR, closed). Keep it in the engagement workspace visible to the sponsor when appropriate. The index is the honest answer to "how do you know what to propose next?"

## Three erosion patterns and a fix

- Renew without growth. Delivery is good, the account is stable, nothing new is proposed. Fix: run the signals harvest at every QVR review, so a proposal exists whenever the evidence supports it.
- Wish-list proposals. Ideas that sound good, with no observation behind them. Fix: no entry in the next-hypotheses list without a signal row that cites source, count and level.
- Sales-shaped expansion. The conversation becomes a pitch that skips the evidence. Fix: lead with the read-out and the Value Gap, then the signal, and let the sponsor judge the proposal from the data.

## Who to involve

Sponsor or Impact Owner, Project Managers and Product Owners (signals from daily work), Tech Leads (technical findings that open options), Business Analysts (user-side observations), and your own leadership for anything that crosses engagements. Anonymize any shareable learning and share only where the agreement allows.

## Your first 15 minutes

Take your most recent delivered QVR. Write three lines: the evidence it produced and its level; one friction or workaround you know happened; one question the sponsor asked after seeing it. If all three exist, you have the start of an Expansion Signals table and a reason to schedule a short next-phase conversation. If one is missing, schedule 20 minutes with the person who saw it.

3. Get it

Install

Did you use it?