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 Software Developer / Engineer: 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 Software Developer / Engineer.

# Software Developer / Engineer lens: Software Expansion Loop™

Your move: notice what the build and the running system taught you, and hand it on as evidence. Developers see signals first, because they are the first to touch reality.

## The narrative for your role

With AI assistants, producing working code is quicker for everyone, so the code itself differentiates less. What differentiates is the quality of the questions you bring before and after building: who does this change things for, what did we see once it ran, what does that make worth doing next? Developers who surface well-formed signals become partners in deciding what to build, not recipients of a backlog.

## How expansion plays out in your day

You do not need a new meeting. You need a habit of writing down four kinds of observation while you work and after release:

1. Surprises in usage: logs or telemetry showing behavior nobody designed for.
2. Friction in the build: the module that fought back, the data that was inconsistent, the step you did by hand.
3. Repeated asks: a question or request you got from users or teammates more than once.
4. Cheap new options: something that became easy because of what you built (a reusable function, a clean data set, a working integration).

Each observation carries what you saw, how often, and how sure you are. You do not have to write the hypothesis; the Product Owner does that. Your job is the evidence.

AI Layer note: if an assistant helped uncover a pattern (for example by summarizing logs), record that, and also record what you verified yourself. An assistant's summary of a pattern is a lead until you have checked it.

## You own / you influence

- You own: the technical observations, their accuracy, the honest statement of how sure you are.
- You influence: what the Product Owner and Tech Lead learn about real usage, the estimate of how cheap a next step is, the reuse of what you built.

## The sharpest questions

1. What did I see in the logs that nobody expected?
2. Which part of the build was harder than it should have been, and what does that block?
3. Which request have I received more than once?
4. What did I build that could now be reused, and where?
5. What did I defer to stay within the QVR, and is it still worth doing?
6. Which of my observations is checked, and which is still a guess?
7. Who should know this, and in what words would they understand it?
8. If this opportunity is real, what is the smallest step that would show it?

## Artifact and where it lives

A short "observations since release" note (what, how often, how sure, link to the log or code), posted in the team's usual channel or added to the Expansion Signals table by the Product Owner. Reusable pieces go into the team's assets list with a one-line description. Keep it light: a few lines per observation is enough.

## Three erosion patterns and a fix

- Insights kept in your head. You know the odd behavior exists and tell no one. Fix: write it down within a day, with the evidence.
- Pet projects dressed as opportunities. An interesting technical idea is proposed with no observation behind it. Fix: before proposing, write the signal that supports it; if there is none, label it E0 and say so.
- Unchecked AI summaries. A pattern reported by an assistant enters the table as fact. Fix: verify against the raw data and record the level honestly.

## Who to involve

Product Owner (hypotheses), Tech Lead (shared patterns and reuse), QA Lead (confirmation from defects), and users or support when you need to understand what a behavior meant.

## Your first 15 minutes

Open the logs or telemetry for the last release. Look for one thing nobody planned for, write it in three lines (what, how often, how sure you are), and send it to the Product Owner with the question "Does this match what users are telling you?" Their answer is the next piece of evidence.

3. Get it

Install

Did you use it?