Intervention Engine
The Value Acceleration Process
A diagnosis can be accurate and still produce no change. The Value Acceleration Process turns it into an agreed outcome, a discovery event, an improvement backlog, a named owner, and a review mechanism that keeps the work moving.
The problem VAP solves
An improvement workshop can end with an accurate wall of observations. A diagnostic can name the structural problem. A backlog can contain sensible actions. None of those artifacts creates follow-through by itself.
The gap appears when daily work returns. Items have no clear owner. The backlog competes with funded delivery work. Reviews report status without forcing a decision. The diagnosis survives in a deck while the system keeps operating as before.
The Value Acceleration Process, VAP, closes that gap. The outcome is agreed before the event. The event is the discovery session itself, and it ends with an initial improvement backlog, a named owner, and review dates on the calendar. After the event, that owner orders the backlog, delegates and oversees the selected work, brings results to stakeholders, and keeps learning from execution.
Each step prevents a different failure:
- Without Measurable Outcomes, the group lacks alignment and direction and cannot reliably judge whether the effort succeeded.
- Without Visual Discovery, the loudest or most senior voice can dominate while relevant parts of the system remain unexplored.
- Without Actionable Output, even a sound diagnosis produces uneven or unreliable follow-through.
The backlog without the mechanism is a wish list.
Three steps, three different jobs
VAP follows the same three-step pattern at team, value-stream, and executive altitudes. The scope, participants, and operating cadence change. The jobs of the steps do not.
Step 1: Measurable Outcomes
Measurable Outcomes defines the result the improvement effort is trying to produce. It aligns the people involved and gives them a shared test for success.
An outcome describes a change in performance, customer experience, risk, cost, quality, or flow. It does not prescribe the solution.
Illustrative activity statement: “Implement agile practices.”
Illustrative outcome: “Reduce the time from customer request to deployed capability.”
Illustrative activity statement: “Improve cross-team collaboration.”
Illustrative outcome: “Remove the cross-team handoff delay that prevents the service from meeting its response target.”
The outcome then acts as a filter. An obstacle or opportunity belongs in this VAP only when it materially affects the outcome. This keeps discovery broad enough to find leverage without turning the event into an inventory of every problem or idea in the organization.
The outcome does not order the backlog. It determines what belongs in the event’s scope. The execution owner orders the backlog after the VAP event.
The failure mode is false alignment. People agree to an activity because the words sound familiar, then make incompatible decisions because they never agreed on the result. Work may finish on schedule while nobody can say what improved.
Step 2: Visual Discovery
Visual Discovery asks two questions:
- What is blocking the outcome?
- What opportunity could enable it?
The step uses a focusing visual, a representation of the actual problem space that gives the group somewhere concrete to look. Depending on the scope, the visual might be a value stream map, customer journey, process diagram, system architecture, dependency map, incident timeline, or another domain-specific view. When no pre-built visual fits and the group cannot construct a domain-specific one, the generic Effort by Impact matrix serves as a last resort. The composite below shows the three pre-built discovery views beside it.
The visual is not decoration and it is not a blank brainstorming canvas. Its job is to expose relevant parts of the system and make incomplete perspectives collide. A product leader may see customer demand. An architect may see technical dependencies. A delivery leader may see capacity and coordination constraints. No single view is the system.
Visual Discovery produces the initial improvement backlog. Each item is tied to the outcome and names either an obstacle to remove or an opportunity to exploit. Filtering is part of discovery, not a separate stage: a session surfaces far more than survives, and the outcome is what decides admission. What passes goes on the backlog. What does not is out of scope, which is not the same as unimportant.
The backlog belongs to discovery for a specific reason. This is the only moment when every stakeholder is in the room at once, able to weigh trade-offs, dependencies, and competing perspectives in live conversation. That conversation does not recur later. Moving backlog creation downstream discards the condition that makes the backlog worth having.
The backlog leaves the event nominally unsequenced. Participants may suggest a sequence while the room is still together, and often should. Sequencing instincts carry tacit knowledge about dependencies, risk, and local conditions that is expensive to reconstruct once items are written down and handed off. Anything the room suggests travels with the backlog as advice, never as a commitment. Setting the operative order is the execution owner’s decision, and it happens after the event.
The owner’s first ordering is a judgment call: relative effort, expected impact, dependencies, risk, and whatever the room advised. Nothing has completed yet, so there is no execution evidence to consult. From the first disposition onward that changes, and evidence from completed work becomes what reorders the backlog.
Discovery closes by handing off. Before the group breaks up, three things are settled while everyone is still present:
- The initial improvement backlog exists. Outcome-relevant obstacles and opportunities are captured with enough specificity to act on. The backlog is initial and nominally unsequenced.
- One person is named as execution owner. That person becomes accountable for establishing and driving the ongoing execution process and cadence.
- Stakeholder review dates are on the calendar, and the steering group has an initial membership. Putting the review points in the diary before the event ends is what keeps the execution mechanism from depending on informal follow-up. The steering group is named here too, with participants free to volunteer or suggest others on their team. That membership is initial, not final: it can change during Actionable Output.
These are not administrative details. They are the handoff from the event to an ongoing mechanism, and they are settled in the room because the room is what makes them cheap to settle.
Discovery stops there. The group does not set the operative order, select the first item, form an experiment, or begin the work. That is the owner’s job, and it starts after the event.
The failure mode is structured-looking theater. The group fills a canvas, but the loudest voice still controls the conversation, seniority decides what is safe to name, or the visual excludes part of the system. The output looks comprehensive while important conditions remain invisible. The other failure is leaving without a real owner or scheduled review dates, which means the event produced a list rather than a mechanism.
Step 3: Actionable Output
Actionable Output is what happens after the event. Visual Discovery produced the backlog, named the owner, and put the review dates on the calendar. Actionable Output is that owner turning the backlog into results.
The owner drives the execution process and cadence. Ownership means accountability for making the mechanism operate. It usually does not mean personally performing the selected item’s work. The process is where the backlog becomes active:
- Order the current backlog.
- Select the top item to execute.
- Work with the appropriate people to define the work or bounded experiment, delegate responsibility for carrying it out, and oversee execution.
- Ensure the result and evidence reach the scheduled stakeholder review.
- Record the disposition and update the backlog. Execution may remove an item, reshape it, change its order, or create new items from what was learned.
At the review, the deciding body makes one of three calls:
- Kill. The evidence does not support continuing. Stop this line of work and reclaim the capacity.
- Pivot. The evidence supports the underlying opportunity, but the approach needs to change. Revise the approach and run another bounded test.
- Persevere. The evidence supports continuing or expanding the approach. Authorize the next increment without pretending one experiment proved permanent value.
Kill, Pivot, or Persevere records the disposition of the selected item. It does not freeze the rest of the backlog. The outcome of the work may add items, remove items, or change their order before the owner selects what runs next.
The failure mode is performative follow-through: the owner has no capacity or authority, reviews occur but force no decision, or work expands before evidence arrives. The backlog stays alive on paper and dies in practice.
How VAP iterates
Two loops keep VAP from becoming a one-time workshop.
The outer loop: run the three steps again
A completed VAP event and subsequent execution cycle may expose a new constraint, remove an assumption, or create an opportunity that did not exist when the cycle began. The next entry point depends on what changed.
- Return to Measurable Outcomes when the strategic context, desired result, or success test has changed.
- Return to Visual Discovery when the outcome still holds but the system around it has changed or the backlog no longer reflects current reality.
The trigger may be a regular operating review or a meaningful event. VAP requires an explicit return decision, not one universal cadence.
The inner loop: keep the backlog alive
The inner loop turns execution into learning. What the work reveals can change urgency, expose dependencies, invalidate assumptions, create a better option, or add a new item. Those changes feed the backlog before the owner selects what runs next.
VAP at different altitudes
The mechanism stays stable while the operating context changes. The following are common applications, not mandatory templates.
Team altitude
A team can use VAP inside a retrospective or in response to a specific delivery problem. The outcome may concern cycle time, quality, interruption load, or a recurring dependency. The focusing visual shows the team’s actual work and surrounding interfaces. After the event, the owner delegates selected items to the appropriate team members and oversees follow-through. The team makes the review decision unless a blocker sits outside its authority.
Value-stream altitude
A value-stream group can use VAP to improve flow across several teams or resolve a shared constraint. The outcome may concern end-to-end lead time, throughput, integration quality, or customer-perceived latency. The focusing visual spans the relevant path from demand to release. The deciding body must include people who can change cross-team priorities, dependencies, and capacity.
Executive altitude
An executive group can use VAP as a portfolio improvement practice or in response to a strategic event. The outcome may concern time-to-market, cost of delay, investment capacity, risk exposure, or learning speed. The focusing visual covers the enterprise system around the outcome. Post-event work remains bounded, while the deciding body has authority to stop work, change policy, move capacity, and remove cross-boundary constraints.
At every altitude, the execution mechanism must provide an escalation path. An owner should not be held accountable for a constraint that only a higher-altitude decision can remove.
Why the separation matters
The three step names are not interchangeable labels for a generic improvement cycle. Each protects the work from a different distortion.
Measurable Outcomes prevents activity from masquerading as success. The result aligns the group and filters backlog admission.
Visual Discovery prevents authority from masquerading as system knowledge. The focusing visual and multiple perspectives expose obstacles and opportunities before the group creates the initial backlog.
Actionable Output prevents event output from masquerading as execution. The event establishes the mechanism. Ordering, execution, disposition, and learning happen afterward when the owner makes it operate.
Collapse the steps and the failure mode returns. Start discovery without an agreed outcome and activity replaces direction. Choose solutions before the picture is complete and the group commits to the first idea rather than the right one. Leave the event without an owner and review dates and follow-through becomes optional.
What VAP is not
VAP is not a replacement for the delivery method an organization already uses. It can operate alongside Scrum, SAFe, Kanban, a product operating model, or a custom delivery system because its target is the improvement work around that system.
VAP is not permission for a big-bang rollout. Its experiments are deliberately bounded so the organization can learn before expanding the intervention.
VAP is not a consultant-owned change plan. A facilitator may help establish the rhythm, but the outcome, backlog, ownership, evidence, and decisions must belong to the organization doing the work.
Run one VAP cycle
Choose one current improvement effort.
Before the event:
- Rewrite its intent as one measurable outcome, and make sure the group understands it before anyone gathers.
The event itself, which is the discovery session:
- Use the relevant system visual with affected stakeholders to surface the obstacles blocking that outcome and the opportunities that could enable it.
- Close discovery with an initial, nominally unsequenced improvement backlog, a named execution owner, review dates on the calendar, and an initial steering group membership.
After the event:
- The owner orders the backlog and selects the top item.
- The owner works with the appropriate people to define the work or bounded experiment, delegates responsibility for carrying it out, and oversees execution.
- At the scheduled review, record the disposition and update the backlog with what execution revealed.
If the event ends without an initial backlog, an owner, and review dates, the execution mechanism does not exist yet.
The VAP event establishes the mechanism. The owner makes it operate afterward.