Foundation
The product flywheel
Three phases — Research, Design, Test. Research is the outer loop, done thoroughly at the start; Design ↔ Test is the inner loop, iterating at high cadence. Pick a phase to dive in.
Research
Understand users, operators, and needs. Define the right problem and what success looks like before solutioning.
Design
Translate validated needs into testable artefacts — interactive prototypes, virtual prototypes, capability storyboards.
Test
Run the artefact against real users or operators, capture the feedback in DASH, feed the next Design iteration.
Grounded in the 4Ds
The flywheel adapts the 4Ds of design innovation — Discover, Define, Develop, Deliver — into a tighter loop suited to defence programmes. Discover and Define collapse into Research (problem space). Develop becomes the Design ↔ Test inner loop (solution space). Deliver becomes the close-out at the end of each interval, where decisions are made and the next loop is seeded.
D1
Discover
Maps to
Research
Field and exercise observations, interviews, environmental scans. Surface the real problem rather than the assumed one.
D2
Define
Maps to
Research
Frame the problem, scope, and success criteria. Set the hypotheses the rest of the loop will test.
D3
Develop
Maps to
Design ↔ Test
Prototype, put it in front of operators, learn, adjust. The high-cadence inner loop of the flywheel.
D4
Deliver
Maps to
Close-out
Ship, hand over, or decide to stop. Capture what was learned and seed the next loop.
Cadence cheatsheet
How the flywheel maps onto a typical 4-month block of eight 2-week sprints — a planning interval for digital programmes, or design innovation for engineering programmes. The spine is the same — Research up front, rapid loops in the middle, close-out at the end — only the content of each block changes. 4 months is typical; the actual length varies by programme, and the proportions matter more than the absolute numbers.
Digital programme
Planning Interval (PI)
4 months · 8 sprints of 2 weeks
Sprints 1–2
Research
Field and exercise observations, problem framing, opportunity mapping. Hypotheses and access already lined up from the previous PI's close-out.
Sprints 3–7
Rapid prototyping + user feedback
Tight Design ↔ Test loops each sprint — prototype, put it in front of operators, learn, adjust. The bulk of the flywheel spin happens here.
Sprint 8
Close-out + prep for next PI
Ship / kill / pivot decisions, retro and write-up, seed hypotheses for the next PI, line up Research access.
How this aligns with the DevSecOps PI
↘ handover at sprint 8 close-out · ↑ upstream technical assessment in parallel with the current ProductOps design loop
Because ProductOps produces working reference code in every Design ↔ Test iteration, DevSecOps does not have to wait for the PI close-out to engage. They run upstream technical assessment — feasibility, integration, security, tech debt — in parallel with the current ProductOps design loop. Risk is reduced continuously, not only at handover.
The two PIs run as a dual-track model where ProductOps is always one PI ahead of DevSecOps. ProductOps designs and validates capability X in PI N while DevSecOps builds the previously-validated capability W and assesses X in the background. At sprint 8 close-out, validated X hands over to DevSecOps PI N+1, where the assessment work has already de-risked the build.
PI N (ProductOps): research, prototype, validate capability X — emit reference code each iteration.
PI N (DevSecOps): build capability W (validated in PI N-1) and run upstream technical assessment on X.
Sprint 8 close-out: validated X with draft requirements hands over to DevSecOps PI N+1.
Note: what ProductOps hands to DevSecOps is reference code that bootstraps development, not static designs. Working prototypes from the Design ↔ Test loop become the starting point for the build PI, alongside validated requirements.
For a team just starting out with no prior PI, sprint 1 absorbs some kick-off work (hypotheses, access).