MINDEF × DSTA

The Defence Product Playbook

A joint MINDEF and DSTA guide to product ways of working: defining value, structuring teams, testing early, modernising legacy, governing outcomes and the tools that enable them.

Co-authored by Tan Min Min (MPO) and Alvin Loh (DSTA).

MINDEF × DSTA

Build products that move the mission.

A practical guide to product ways of working for defence. Define the problem worth solving, structure a team that can solve it, and test with real users.

9sections
63min end to end
5interactive tools
4frameworks
Recommended reading order
What is inside

Nine sections

Read it in order, or jump to what you need.

How to read this playbook

At your own pace

Every section shows its reading time and remembers what you have read. Dip in and return where you left off.

Shaped around you

Your profile reorders the sections and marks the ones that matter most.

Built to try

Score a problem statement, climb the metric ladder, or size a team. The tools are live.

FoundationsOTI

Why product ways of working

6 min read

Defence plans carefully, then builds to the plan. That works when the requirement is known and stable. When the problem keeps changing, it does not, and the work should be run as a product instead.

The premise

Detailed upfront planning, staged approvals and fixed deliverables suit physical work: building a hangar, procuring a platform, fielding a well-understood system. Much of defence delivery is rightly run this way and should stay that way.

Software behaves differently. Operational needs shift, threats adapt, and the technology underneath turns over quickly. Specify everything upfront and you often field a system that is out of date at launch, misses what operators actually needed, or demands expensive rework.

Root cause

Where delivery comes apart

Slow launches, slow iteration and unclear impact usually trace back to the same three issues. Expand each to see how it shows up.

Needs are handed down as immutable requirements, and the team plans the whole product before starting development. Nothing validates the assumptions inside the requirement, and it is hard to adapt when constraints, operator feedback or the threat picture change midway.
The engineering side tracks what it can count, such as uptime, usage and features shipped. The operational side tracks long-term outcomes that take years to move. Neither tells you whether the product is solving real problems.
Trade-offs between operations and technology escalate to committees where everyone is represented. They meet infrequently and decide by consensus. By the time the outcome is visible, it is too late to change course.

The shift

Strengthening Ops-Tech Integration

The fix is not more process. Operations and technology should be integrated from the start and aimed at a single outcome, with one person accountable for reaching it. We call this Ops-Tech Integration (OTI). Operational judgement sits with the Ops Manager, who owns that outcome.

Before
  • Ops sets fixed requirements, then hands off to tech
  • Tech builds to spec, measuring delivery not outcome
  • Committees arbitrate, slowly
  • Impact surfaces too late to act on
After
  • One team owns the problem and the metric
  • Ops and tech iterate together quickly
  • Solutions are tested with real users early
  • The team pivots the moment evidence says so

When to use this

Best for problems that keep changing

A product approach helps most when the problem or the solution is still unclear. Reach for it when any of these are true.

Evolving problems

The need keeps changing, for example as operator expectations or the operating picture shift.

Unclear root cause

A new problem where you are not yet sure what is actually driving it.

Unproven solution

You cannot be certain the approach will achieve the intended effect until you try it.

A defence example

A C2 product supporting an integrated kill chain cannot be fully specified upfront. Operators discover what decision support they need only by using it against realistic scenarios. That is a product-critical problem: it needs quick, continuous iteration.

Foundations

The three principles

3 min read

Three principles every product team should implement in their approach.

The spine

Three fundamental principles should hold in how a product is developed. They apply whether the product is built in-house or by a contractor.

Design Innovation

A shared lens: the Double Diamond

Discovery is commonly framed through Design Innovation, the Double Diamond. It is a useful companion to the three principles: the first diamond is where you define the problem worth solving, and the second is where you test your way to the right solution. Diverge to explore, converge to decide.

Right problemRight solutionDiscoverDefineDevelopDeliver

Hover a phase. Diverge to explore, converge to decide, twice: first on the problem, then on the solution.

Principle 01METRIC

Define the problem, measure the value

11 min read

Two things make a product worth building: it solves a real problem, and you can measure whether that problem is getting smaller. This principle covers how to choose the right problem, write it down clearly, and pick a measure that shows whether it is working. It follows the METRIC framework.

Framework

METRIC: the six steps from problem to proof

MMapMap organisational priorities to specific problems, then break them into sub-problems with clear hypotheses.
EEstablishEstablish a sharp problem statement for each product, using the 4C check.
TTrackTrack performance with a value metric, a baseline and a regular reporting cadence.
RReviewReview and realign when the metric is not moving as projected. Diagnose why, then act.
IInstitutionaliseInstitutionalise learnings across the portfolio through shared insight and dashboards.
CCommitCommit to regular reviews with senior leaders that hold teams to improvement, not activity.

Establish

Write a problem worth solving

Most weak products trace back to a weak problem statement: an aspiration, a solution in disguise, or a system simply reaching end of life. Build the statement by answering the 6W, then test what you have written against the 4C check.

What
The thing that is going wrong. Describe the problem, not the solution you have in mind.
Where
Where the problem happens: the place, the unit, or the step in the process.
When
The point at which it happens, and how often.
Who
The people who feel it. Name the group, and what it costs them.
Why it happens
The real cause underneath, not just the symptom you can see.
Why it matters
What keeps going wrong if nobody fixes it.

Load the weak example, then the improved one. The improved statement shows where each of the 6W sits.

4C problem-statement check

“Our C2 system is reaching end of life and needs to be replaced.”

Tick each dimension it satisfies. Try it on your own statement too.

0 / 4
Not yet a problem statement. It likely describes a solution, an aspiration or an age.

Four traps to avoid

Describes a desired end state, not a problem someone faces today. “We want a decision-ready force.” Ask instead: who is stuck, doing what, at what cost?
“We need a new data platform.” This assumes the answer. State what decision cannot be made today, and why, before naming any system.
“The system is out of support.” Age is not a problem. Name the user function that will lose a viable alternative, and what that costs operations.
“Users find it slow and clunky.” Without a specific user, task, frequency and severity, no team can tell whether they have fixed it.

Choosing between problem statements: SFR

You will usually have more problem statements than teams to work on them. Score each one low, medium or high on three counts, and start with the problems that score high on all three.

SSeverityHow painful it is for the user when it happens.
FFrequencyHow often it happens.
RReachHow many users it affects.

Hold back the ones that score high on only one or two. A severe problem that hits a handful of users once a year is a worse first bet than one that is severe, frequent and widespread.

Track

Climb the metric ladder

Teams default to counting what is easy: logins, uptime, features shipped. Those are inputs, and they say nothing about whether the problem is getting smaller. Aim for the value metric, the third rung. It is your North Star: it measures the outcome of solving your problem and still moves often enough to steer by. It should also act as a leading indicator of the outcome metric above it, the effect the organisation is ultimately chasing, which moves far too slowly to guide a team week to week. You should be able to explain how improving one will improve the other. Click each rung.

Confidence the problem is truly being solved rises up the ladder, but so does the time it takes to see a change.

Value metric

A leading indicator that directly measures the intended outcome of solving your problem. This is your North Star, the one the team steers by. Define one per problem, and pick one that can move at least twice a year.

Defence example

Median time to a confirmed recognised picture during surge periods.

Confidence it is being solved85%
Reject a candidate metric if
  • It can be gamed without the outcome improving.
  • Too much sits between it and the outcome for a movement to mean anything.
  • The link to the outcome rests on assumption rather than evidence.
  • It measures what the system does, not what changes for the user.
  • It is subjective or self-reported.

Pressure-test whatever survives against SMART: specific, measurable, achievable, relevant, time-bound.

Review

When the metric stops improving

A metric that stops improving does not mean the team has failed. But something is holding it back, and the team needs to know what. Work out which of these is happening before you change the plan.

Likely causeAction
Not addressing the root causeRevisit the problem statement
A false assumptionPivot the approach
Problem has changedRedefine or deprioritise
Blocked outside the teamEscalate to the Steering Committee
Team cannot move fastReview structure and skills

Commit

Prove it is worth the spend

Value must be weighed against cost. The Value-Cost Ratio tells you how much outcome you buy per dollar, and the year-on-year change is the signal that matters. Improve it either by growing value at steady cost, or by shifting a product to maintenance once its value has plateaued.

Value-Cost Ratio calculator

Illustrative: a cloud platform provisioning environment requests within a service-level target. Adjust the numbers.

Current platform
Annual cost$100,000
Requests per year100,000
Met within target10%

Value

10,000

within target

VCR

0.10

per $

Unit cost

$10

each

Modernised platform
Annual cost$175,000
Requests per year100,000
Met within target35%

Value

35,000

within target

VCR

0.20

per $

Unit cost

$5

each

0.100.20requests within target, per $ spent
+100% VCR

Figures are illustrative and do not represent any real platform.

6W: what, where, when, who, why it happens, why it matters4C: clarity, consequence, cause, confirmationSFR: severity, frequency, reachSMART value metricsVCR and unit cost
Principle 02TEAM

Structure the team right

11 min read

How a team is structured decides how fast it can move. This principle puts one accountable owner on the problem, surrounds them with just enough expertise and levers, and empowers the team to solve it. It rests on three rules, and the shape scales with complexity.

Ground rules

Three rules, before any org chart

Single-line accountability

One person is accountable for moving the metric. Not a committee, not a consensus.

Levers, not just requirements

The team holds the ops and tech levers to make trade-offs itself, rather than implementing orders.

Empowered to solve

It can change the operational approach, the technology, or both, to solve the underlying problem.

The structure

One structure that grows with the product

The same shape serves a two-week proof of concept and full scale development. A Steering Committee oversees the problem. Below it, the Working Committee runs the product: the OM and Product Lead sit inside it in a two-in-a-box, alongside the Leads. What changes with scale is how many tiers are present. Switch the scale below to see the structure expand and contract.

Team structure explorer
Steering Committee

Senior sponsors with a stake in the problem

Holds the OM accountable, clears blockers, vests the levers, makes cross-priority trade-offs.

Working Committee

Business Owner, two-in-a-box

Ops Manager (OM)

Owns the problem, the outcome and the ops levers

Product Lead

Brings product and engineering judgement

Joint decision-makers, and the core of the Working Committee. Where the problem needs no policy lever, this is the whole ownership layer.

The Leads

Product Lead

Vision, strategy, roadmap

Tech Lead

Architecture and standards

Design Lead

Experience and research

One member per lever needed to move the problem. The OM adds any operational leads required.

2 squads

Squad 1

Product Manager, Engineering Manager, Designer, software engineers.

Squad 2

Product Manager, Engineering Manager, Designer, software engineers.

Proving the metric can move. One accountable OM in a two-in-a-box with a Product Lead, a lean Working Committee, and one to three squads of around eight people each.

Proof of concept. Proving it can be built. One squad. The PM, Engineering Manager and Designer also act as the Product, Tech and Design Leads. Follow the principles, not the full form.

FSD. Full scale development, once the value is proven. Multiple sub-products, each with its own squads. A Programme Lead joins the Working Committee to set up the workstreams, funding and procurement that coordinate across them.

Co-sourced. One in-house squad sets direction and standards, working alongside several vendor squads. Strategic product and tech capability stays in-house, and a Programme Lead runs the vendor approvals and procurement the squads depend on.

Ops Manager

One accountable owner, two-in-a-box with a Product Lead

The accountable owner is often called a Business Owner, sometimes paired with a separate policy lead. To keep accountability single, we fold that remit into the Ops Manager rather than split it out. The OM is the operational owner: the equivalent of a Product Owner, accountable for the outcome.

The OM sits two-in-a-box with a Product Lead. The OM brings deep operational judgement and owns the levers. The Product Lead brings product and engineering expertise: able to read the codebase, weigh system design trade-offs, and turn intent into a roadmap. Together they make joint decisions. It is a partnership of equals, not a reporting line. The pair sits inside the Working Committee, not in a tier of its own above it.

When one is enough

Where the problem does not need distinct operational and product judgement held by two people, a capable OM who also carries product depth can own it alone. The two-in-a-box is also a useful transition: an OM builds product fluency alongside a Product Lead, then takes sole ownership once ready.

Lead or Manager

The same craft at different seniority

Lead and Manager are not different jobs. They are the same craft at different seniority, and this holds for every craft in the team. A Lead sits in the Working Committee, sets direction and standards across squads, and makes the hard trade-offs. A Manager runs delivery inside a squad. Whether you need both tiers depends on the product's scale and complexity.

Product

Lead · more senior

Product Lead

  • Owns vision, strategy and roadmap across the product
  • Sits in the Working Committee
  • Partners the OM in the two-in-a-box
Manager · in-squad

Product Manager

  • Owns the backlog and delivery of one squad
  • Runs discovery and prioritisation day to day
  • Reports into the Product Lead where one exists

Engineering

Lead · more senior

Tech Lead

  • Owns architecture and technical standards across squads
  • Sits in the Working Committee
  • Makes system design trade-offs
Manager · in-squad

Engineering Manager

  • Owns the engineering delivery of one squad
  • Runs the team's technical execution
  • Reports into the Tech Lead where one exists

Design

Lead · more senior

Design Lead

  • Owns the experience and design standards across the product
  • Sits in the Working Committee
  • Leads research that validates the problem
Manager · in-squad

Designer

  • Owns the design work of one squad
  • Runs research and design day to day
  • Reports into the Design Lead where one exists

Programme

Lead · more senior

Programme Lead

  • Sets up the workstreams that coordinate across teams
  • Sits in the Working Committee
  • Secures funding, headcount and vendor approvals
Manager · per workstream

Programme Manager

  • Owns the programme management of one workstream
  • Procures tools and resources, and sets up the dashboards that monitor the metrics
  • Reports into the Programme Lead where one exists
A rule of thumb

Early on a product may have only Managers, who also carry the Lead responsibilities. As it grows into multiple squads, Leads appear to hold the line on strategy and standards across them.

Reference

Roles at a glance

Holds the OM accountable for solving the problem. Ensures the environment lets them, vesting levers and clearing blockers. Makes trade-offs where other priorities have dependencies.
Accountable to the Steering Committee for the outcome. Sits in the Working Committee, in a two-in-a-box with the Product Lead. Owns the ops and tech levers. Makes trade-off decisions, defines the problem and metric, and directs the product at least fortnightly.
Peers in the Working Committee. Each brings the expertise of one craft to a decision and sets the standards for it across squads: product, engineering, design, and the workstreams, funding and procurement that carry them. The Product Lead partners the OM in the two-in-a-box.
Runs the programme: sets up workstreams to coordinate across teams, secures funding, headcount and vendor approvals, procures tools and resources, coordinates with operations teams for a smooth release, sets up the dashboards that monitor the metrics, supports end users to resolve issues, and clears audits. Led by a Programme Lead in the Working Committee.
Product Manager, Engineering Manager, Designer and software engineers. Each squad owns a specific sub-problem. May be in-house or vendor-staffed.

Accountability

Who does what, phase by phase

One person is accountable for each piece of work, and only one. Use this to settle arguments about who decides, not to hand out tasks.

A accountable, the single ownerR responsible, does the workC consulted before decidingI informed after
ActivityOMProduct ManagerDesignEngineeringProgramme Management
Initiation
Engage operational stakeholders to identify and secure opportunitiesARI——
Research to validate the problem statement and understand user needsIRA, R——
Define and commit to the problem statement and value metricARCC—
Resourcing
Set up workstreams to coordinate across teamsARCCR
Secure funding, headcount and vendor approvalsAR——R
Procure tools and resources—I——A, R
Planning
Define the product vision, strategy and roadmapCA, RCC—
Design the product to solve the problem with a good user experienceICA, RC—
Design robust, stable and secure architecture—CCA, R—
Development
Deliver the roadmap with the engineering teamIA, RRRR
Build software to specification, securely and on timeII—A, R—
Coordinate with operations teams for a smooth releaseIA—IR
Use and adoption
Engage end users to drive adoptionIARIR
Set up dashboards to monitor metrics and derive insightsICIIA, R
Support end users to resolve issues—IIIA, R
Governance
Clear audits and address findingsAIIIR
Ensure compliance with design standardsI—A, R——
Ensure compliance with technical standardsI——A, R—

For leaders

How to begin: TEAM

TTargetPick teams on product-critical problems that are struggling with speed, focus or flexibility.
EEvaluatePrioritise by importance to the mission and by the product's size and complexity.
AAssembleAppoint the OM and Product Lead, define the problem and metric, then stand up the squads.
MMobiliseAlign stakeholders, adjust processes, and build the capabilities the team needs to decide well.
Principle 03TEST

Test early, iterate fast

6 min read

A requirement is a hypothesis until an operator has used it. This principle tests the theory of change cheaply and early, so the expensive build is committed only to ideas that have already earned it. It follows the TEST framework.

The idea

Every product rests on a theory of change: if we build this, operators will behave differently, and that shift will move the outcome. Each link in that chain is an assumption. Testing is how a team finds the broken link before a system has been built around it.

The cost of being wrong compounds the later you learn. A flawed assumption caught in a two-day prototype is a lesson. The same assumption caught after fielding is a rebuild. Test early, and test with the people who will actually use it.

Design Innovation

Two diamonds: the right problem, then the right solution

Design Innovation, the Double Diamond, gives testing its shape. You diverge to explore, then converge to decide, twice. The first diamond makes sure you are solving the right problem. The second makes sure you have the right solution. Testing lives across both, but bites hardest in the second.

Right problemRight solutionDiscoverDefineDevelopDeliver

Hover a phase. Diverge to explore, converge to decide, twice: first on the problem, then on the solution.

Framework

TEST: four habits of teams that learn fast

TTrial with real operatorsTest with the operators who will actually use it, not internal stand-ins. A watchkeeper's judgement cannot be simulated by the project team.
EExpose the riskiest assumptionA prototype exists to be wrong quickly. Build the least you can to test the assumption most likely to sink the product, then throw it away.
SShorten the loopMeasure the time from user feedback to a changed prototype in days, not months. If it is slow, fixing that comes first.
TTurn tests into decisionsEvery test should end in one of three calls: keep it, change it, or drop it. A test that ends without one has taught the team nothing.

Benchmarks

How fast is fast enough

Proof of concept

3 to 6 months

to put something in front of real users for the first time.

Proof of value

Within 1 year

to launch to real users and show the metric can move.

These are reference points, not targets to game. If a team cannot reach them, the useful question is what is blocking it: access to users, procurement, funding, or the team's own structure.

Enable it

What leaders must clear out of the way

Teams cannot test what they cannot reach. Give the OM a route to actual operators, and the autonomy to manage the optics of testing an unfinished thing with a small sample.
Adjust finance and procurement so a team can hack a testable version within weeks, not wait a budget cycle. A good benchmark is a launchable prototype for a proof of concept inside three to six months.
If every test must succeed, teams stop testing anything risky. Judge teams on how much they learn and how fast they adjust, not on a run of flawless demos.
Guardrails still apply

Fast iteration does not mean loose assurance. Teams should track resilience and security as guardrail metrics alongside the value metric, and escalate any trade-off that carries real risk to the Steering Committee.

PathwayIMPACT

Modernise legacy products

8 min read

Most defence software already exists. Replacing it in one go is the tempting move and the wrong one, because operations cannot stop while you rebuild. Modernise in phases, prove each phase before starting the next, and retire the old system only once the new one has taken over its work. It follows the IMPACT framework.

First, a definition

Outdated is not the same as old

A product is not outdated because of its age. It is outdated when it stops being fit for purpose on any of three fronts: business fitness, it no longer solves the real problem; technical fitness, it is no longer secure or reliable; or cost fitness, it costs more than the value it returns. A decade-old system that still serves operators well is not a modernisation candidate.

Identify

Assess fitness, then prioritise

Score each product across five dimensions, and weigh that against how mission-critical it is. The two together tell you what to modernise first. Try it below.

Fitness assessment

Rate a product across five dimensions. Outdatedness is the inverse of fitness.

Business relevanceFair

Does it meet current needs and support the changes expected in the next 2 to 3 years?

User experienceFair

Is it easy for operators to use?

DataGood

Does it give users timely, accurate data?

ResilienceGood

Does it meet the required uptime for its role?

CostFair

Are the running costs reasonable for the value delivered?

Mission criticality70%
Modernise firstProtect and monitorLow priorityQueue for later
Less outdatedMore outdated →
Average fitness2.4 / 4

Protect and monitor

Ageing. Watch the weak dimensions and plan ahead.

Framework

IMPACT: six steps to modernise without a big bang

IIdentifyStock-take every product, score how outdated each is, and prioritise by fitness and mission criticality.
MMapMap where the product is today and where it needs to be, aligning ops and tech on the gap and the dependencies.
PPhaseBreak the work into phases that de-risk delivery and hand operators early wins.
AAssemble teamsStand up a team with single-threaded accountability and the levers to decide, following the TEAM move.
CChange managementPrepare, manage and sustain the human side, so the new product is adopted, not just deployed.
TTop-level ownershipTreat modernisation as a command responsibility owned at the top, where the hard trade-offs are made.

Phase

Why never a big bang

Replacing an entire system at once means any failure hits every user and every function at the same time, with nowhere to roll back to. Phasing contains the blast radius, delivers value sooner, and lets each phase teach the next.

Big bang

Higher risk
  • One cutover, one moment of maximum exposure
  • A failure affects all users and functions at once
  • No safe rollback point
  • Value arrives only at the very end, if at all

Strangler fig

Recommended

Build the new system around the old one. New components intercept and handle requests piece by piece, slowly taking over until the legacy system can be retired safely. Operations never stop.

Legacy carries all
New handles slice 1
New handles most
Legacy retired

Change management

Prepare, manage, sustain

Capture how the current product really works, the knowledge as well as the features, in a central repository. Engage the four user groups early: operational owners, ops users, the technical team and end users. Design for better outcomes, not feature parity.
Communicate through every stage, before, during and after each deployment. Build shared skills through joint training, and secure proper knowledge transfer from any outgoing vendor.
Track adoption and satisfaction, update the standard operating procedures, and keep a continuous improvement cycle running so the product stays relevant.
Modernise the work, not just the tech

The biggest trap is rebuilding the old process in new technology. Modernisation is a chance to simplify how work is done. Ask whether a feature should be replicated at all before you port it.

Top-level ownership

Modernisation reshapes capabilities and forces hard trade-offs on resourcing, build-versus-buy and organisational design. That makes it a command responsibility. The Head of the organisation is accountable for the outcome. The work can be delegated, but the accountability cannot.

AssuranceCouncil

Govern and review

6 min read

Governance is how the organisation holds teams to outcomes, clears their path, and decides where to invest. Product reviews need a standing body with the authority to act on what they surface. This section proposes one shape for it, and sets out the cadence and the questions that make a review worth holding.

What it takes

Three things the reviewing body needs

Whoever runs these reviews needs three things at once: the authority to hold owners accountable, the seniority to clear blockers, and a view across the portfolio to decide where the investment goes. Where a forum already carries all three, use it. Where the remit is split across several, the council below is one shape worth considering.

Proposed

The Ops-Tech Product Council

Ops-Tech Product Council (OTPC)Proposed formation

A standing body that oversees a portfolio of product-critical problems. Chaired at Chief or CE-equivalent level, supported by the organisation's most senior product and engineering leaders. One council can serve MINDEF, an SAF Service, or DSTA, and convene jointly where a problem spans them.

Hold to account

Ensure each OM has a clear problem aligned to priorities, and metrics that show it moving.

Empower

Vest the levers, clear blockers, and secure direct access to real users for testing.

Trade off

Decide across products where priorities, dependencies or security posture collide.

The name is a proposal. What matters is a single accountable body with the seniority to vest levers and the discipline to review outcomes.

Cadence

Review frequency follows criticality

How often

Monthly

Reviewed by

Council chair, supported by the Product Lead and Engineering Lead

Urgent and important problems inside the organisation's key priorities. Frequent, senior attention.

Quality

What makes a good review

A good review checks progress on the problem and steers the OM where they are off track. It covers outcomes, what the team learned and what they propose to change, not status updates or implementation detail. Teams should come with their metric over the past quarter, what they learned from users, and the adjustments they want agreed.

Questions worth asking, by theme

Walk me through the problem and how you know it matters to operators. How does this metric connect to our priorities? What value would tell us the problem is solved in three to six months?
What is the metric now, and how has it moved this quarter? What are the top three factors driving it? Which are within your control, and which need external change?
How many real operators have you tested with this month? What surprised you most? Show me a recent prototype. How did their feedback change your approach?
How long from user feedback to a shipped change? What is slowing you down? Are you testing with real operators or internal proxies?
What adjustments are you proposing? What operational change would speed you up? What trade-off between speed, scope and resources do you need from us?

Portfolio

Three signals leaders should track

% of products with a 4C problem statement

A low figure points to capability gaps in OM roles. Consider training.

% with SMART, appropriately lagging value metrics

A low figure means teams are defaulting to output metrics, not outcomes.

% improving their value metric year on year

Flat or declining across the portfolio signals a systemic issue to investigate.

A note on plateaus

A metric that climbs then flattens is not always failure. It can mean the product has delivered its available value. That is the signal to shift it from active development to maintenance, and move the investment to a problem that can still move.

EnablementFlywheel

Tools to use

7 min read

DSTA's ProductOps Pipeline provides the flywheel and the toolchain that take a team from research to a tested product, holding the same quality bar however the work is authored.

The enterprise layer

ProductOps sits above delivery

DSTA runs three operating disciplines in parallel. ProductOps governs what gets built, how product decisions are made, and whether what ships achieves the intended effect. DevSecOps governs how software is built, secured and shipped. MLOps governs how models are trained and deployed. ProductOps is the upstream layer that decides what the other two operate on.

ProductOps is an enterprise capability, not a role on your team. It is distinct from Programme Management, which coordinates delivery within one product. ProductOps is the reason a small team can move fast without reinventing standards, tooling or assurance each time.

ProductOps

What to build, and whether it worked

DevSecOps

How it is built, secured and shipped

MLOps

How models are trained and deployed

The operational core

The flywheel, not a production line

Instead of locking finished designs and handing them off, each turn of the flywheel produces reference artefacts that DevSecOps acts on concurrently. Research is the outer loop, run thoroughly up front. Design and Test are the fast inner loop. Click a phase.

ResearchDesignTestFlywheelProductOps
ResearchOuter loop

Understand the problem deeply. Run thoroughly at the start of a track, and revisit only when findings reshape the problem itself.

DiscoverySynthesisArtefact production

It maps cleanly onto the three principles: Research is where you , and the Design-Test inner loop is how you your way to the right solution.

The toolchain

Tools that carry each phase

CLARABespoke

An AI product-intelligence tool that reads a programme's knowledge base, drafts structured research artefacts, and files them back with citations.

When to use

The hub through which most prompts run, across the whole flywheel.

Research · Design · Test
PRIZMBespoke

An AI-ingestible design system. Components, tokens and templates that models read and generate conformant UI from. This playbook is built on it.

When to use

Any digital interface work. It is the paved road.

Design
DASHBespoke

A measurement platform for UX and product metrics: usability, satisfaction, OKRs, and capability metrics for engineering.

When to use

Baselining before, and proving the outcome after.

Test
Claude CodeCOTS

Natural-language code generation for rapid prototyping straight from a requirements doc, paired with PRIZM for conformant output.

When to use

Turning a validated design into a working prototype fast.

Design
DynatraceCOTS

Live product instrumentation with natural-language insight extraction on running products.

When to use

Understanding how a fielded product actually behaves.

Test

Assurance

One quality bar, whoever writes the code

As AI writes more of both functional and non-functional code, quality cannot rest on who authored it. The ProductOps Quality Model engineers parity in four layers, early rather than late.

L1
PreventionPre-build

Before the build. Rules in CLAUDE.md, PRIZM paved-road components, typed contract boundaries. Parity is engineered here.

L2
Outcome validationDesign onwards

Within ProductOps. Test plans, usability, scorecards and OKRs flow into DASH. Did the work achieve its intended effect?

L3
Automated scanAt PR

Within DevSecOps, at pull request. Composition analysis, static and dynamic scanning, container checks.

L4
Integration verificationPost-merge

After merge. Confirms the pieces work together in the whole.

Parity is engineered at L1, not enforced at L3

If quality only shows up at the scan gate, you are catching problems late and expensively. Build the guard rails into the paved road, and most defects never get written.

Explore the live pipeline

The full toolchain, prompt library and guided journeys live in the DSTA ProductOps Co-pilot.

Open the Co-pilot
Adoption

Get started

5 min read

Start by seeing what good looks like, and how far you are from it. Then close that gap with two or three teams before you take it wider.

Where you stand

What good looks like at three levels

Three groups have to change: the organisation, the Ops Manager, and the product team. Each one below shows what good looks like, and the signs that tell you it is happening. Be honest about where you are today. Select a level.

What good looks like

OMs are accountable for solving problems and can align teams towards the outcome.

OMs write clear 4C problem statements
OMs define value metrics that contribute to priorities
OMs direct their product at least fortnightly

The rollout

Three phases, starting small

Pilot with two or three teamsNow

Pick sub-problems that are critical and urgent in the next six months, and that a digital solution can plausibly move. Baseline every maturity indicator and set a target with your sponsor.

Expand to the problem spaceNext

Once a pilot succeeds, widen to the larger problem it contributes to, bringing in the other products that shape that outcome. Baseline and measure again.

Expand across the organisationLater

When the evidence convinces you the practices help teams solve problems better, roll them out organisation-wide.

Change, honestly

What this really asks of the organisation

Start with a senior sponsor at Chief or CE-equivalent level, because this is genuine change management, not a tooling swap. It means new roles and accountabilities, adjustments to procurement, funding and compliance so teams can move, and a rebalancing towards quality technical talent alongside operational staff.

Measure the indicators monthly or quarterly. Where they improve, scale to more teams. Where they do not, reassess the blockers, whether change management, people, or finance and procurement, and adjust the approach. Treat the rollout itself as a product.

The one-sentence version

Put one accountable owner on a problem that matters, give them a metric and the levers to move it, and review the outcome, not the activity.

Glossary and terms

3 min read

The language of this playbook, in plain terms.

A to Z

Glossary

4C

The test of a good problem statement: Clarity, Consequence, Cause, Confirmation.

6W

The six questions a problem statement should answer: what, where, when, who, why it happens, why it matters.

C2

Command and control.

CLARA

DSTA's AI product-intelligence tool, the hub for the prompt library.

DASH

DSTA's measurement platform for UX, product and capability metrics.

DSTA

Defence Science and Technology Agency.

Fitness assessment

A five-dimension score of how fit for purpose a product is.

Flywheel

The ProductOps operating loop: Research, then Design and Test.

FSD

Full scale development. Building the product out at scale once its value is proven.

IMPACT

The modernisation framework: Identify, Map, Phase, Assemble teams, Change management, Top-level ownership.

Leading indicator

An early behaviour change that validates part of the theory of change.

METRIC

The value framework: Map, Establish, Track, Review, Institutionalise, Commit.

MPO

MINDEF Product Office.

North Star metric

Another name for the value metric.

OM

Ops Manager. The accountable operational owner of a product's outcome.

OTI

Ops-Tech Integration. Operations and technology aimed at one outcome.

PRIZM

DSTA's AI-ingestible design system. This playbook is built on it.

Product Lead

The senior product role in the Working Committee; partners the OM two-in-a-box.

Product Manager

The product role running delivery inside a squad.

Programme Lead

The senior programme role in the Working Committee; a peer of the Product, Tech and Design Leads.

Programme Management

The function that coordinates delivery across the squads of a product: workstreams, funding, procurement, dashboards and user support.

Programme Manager

The programme role running procurement, dashboards and user support for one workstream.

ProductOps Pipeline (enterprise)

DSTA's organisation-wide product capability, standards and toolchain.

Proof of concept (PoC)

The first stage: proving the thing can be built and put in front of real users.

Proof of value (PoV)

The second stage: proving the value metric can actually move.

RACI

Who is Responsible, Accountable, Consulted and Informed for each activity in a product team.

SFR

The prioritisation test for problem statements: Severity, Frequency, Reach, each scored low, medium or high.

Squad

The delivery team: PM, Engineering Manager, Designer and engineers.

SMART

The test of a value metric: specific, measurable, achievable, relevant, time-bound.

Steering Committee

The oversight body that holds the OM accountable, vests the levers and clears blockers.

Strangler fig

A gradual modernisation strategy that replaces a system piece by piece.

TEAM

The team principle, and the first-steps mnemonic: Target, Evaluate, Assemble, Mobilise.

TEST

The testing framework: Trial with real operators, Expose the riskiest assumption, Shorten the loop, Turn tests into decisions.

Theory of change

The causal chain from what you build to the outcome you seek.

Two-in-a-box

The joint OM and Product Lead ownership pairing.

Value metric

A leading indicator that directly measures the outcome of solving the problem.

Value-Cost Ratio

Outcome delivered per dollar spent; its year-on-year change is the key signal.

Working Committee

The body that runs the product: the OM and Product Lead two-in-a-box, plus the Leads.

About

About this playbook

A practical guide to product ways of working, written for the defence ecosystem. The Tools section draws on DSTA's ProductOps Co-pilot, and the whole site is built on the PRIZM 4.0 Enterprise design system.

DSTA ProductOps Co-pilotPRIZM 4.0 Enterprise

Jointly developed by MINDEF and DSTA

Co-authored by Tan Min Min (MPO) and Alvin Loh (DSTA).