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 Solutions / Technical Architect: 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 Solutions / Technical Architect.

# Solutions / Technical Architect lens: Software Expansion Loop™

Your move: read a delivery as an experiment on the architecture. What it proved, strained or made possible across the landscape is the strongest source of strategic options.

## The narrative for your role

With AI, a competent design for a well-understood problem can be drafted in minutes. The scarce skill is seeing which problem is worth solving next, and what the landscape makes cheap or expensive. Architects hold a view no single team has: they can connect a signal from one delivery to an opportunity in another. Asking value questions across the landscape ("what does this evidence make possible, and for whom?") is the differentiator, and it comes before any diagram.

## How expansion plays out in your day

After a QVR's evidence is read, treat the architecture as part of the evidence:

1. What held: which design decisions proved right, and what option do they keep open?
2. What strained: which seam, integration or constraint hurt, and which hypothesis would justify fixing it?
3. What became possible: a clean interface, a shared data product, an event stream another team could use.
4. What is reusable: patterns, platform components and decisions that apply elsewhere in the landscape.
5. What was deferred: reversible choices made on E0 assumptions that the evidence can now confirm or refute.

Strategic optionality is a value dimension in its own right. An option opened or a risk retired is a legitimate expansion signal, provided you can name what was observed.

## You own / you influence

- You own: the landscape view, reusable pattern decisions, the architecture decision records and their review after evidence arrives.
- You influence: how the Product Owner reads technical findings, which initiatives share assets, the order in which the next QVRs unlock options.

## The sharpest questions

1. Which assumption in our architecture did the delivery test, and what did it show?
2. Which option does the current design keep open that we have not used?
3. Which constraint hurt enough to be a hypothesis in its own right?
4. Which other initiative in the landscape could use what this one produced?
5. Which decision, made as an E0 assumption, should be revisited now that evidence exists?
6. Is the opportunity I see supported by an observation, or by architectural taste?
7. What would sequence the next three QVRs so each unlocks the following one?
8. What risk did this delivery retire, and who should know?

## Artifact and where it lives

The Expansion Signals table with an "architecture" source column, an options register (option opened or closed, evidence, who benefits, cost to exercise) and ADR updates marking assumptions confirmed or invalidated. These live with the ADRs and landscape documentation, and the top signals are summarized in the Product Owner's Canvas update.

## Three erosion patterns and a fix

- Landscape drift. Each team keeps its learning local, so the same discovery is repeated. Fix: publish a short post-QVR note of reusable findings in the shared architecture space.
- ADRs that never close. Decisions recorded as assumptions are never revisited. Fix: add a review date tied to the evidence read, and update status when it arrives.
- Platform-first expansion. A shared capability is proposed with no consumer and no signal. Fix: require at least one observed consumer or need before building for reuse.

## Who to involve

Tech Leads of the affected teams, Product Owners (hypotheses), Engineering Managers (capacity and sequence), security and privacy owners (new exposure), and the sponsor when an option has strategic weight.

## Your first 15 minutes

Open the ADRs related to the last delivered QVR. For each one marked as an assumption, write whether the delivery confirmed it, refuted it, or said nothing. Pick one that was refuted or strained, and write the question it raises for the business. That question is a candidate hypothesis and a first signal row.

3. Get it

Install

Did you use it?