Foundation
The tripartite product structure
Product outcomes are achieved through complementary ownership of operational value, user experience, and technical delivery — three roles, one product.
Why three roles, not one
A single product manager can hold either mission depth, user-experience depth, or technical depth — but rarely all three at once, and never at the accountability level each requires. DSTA's programmes span defence-critical missions, complex operator workflows, and non-trivial systems engineering. That's why we recommend a tripartite structure — three roles, each holding their own accountability without stretching thin.
The three roles work as a triad, not a hierarchy. Each owns a distinct problem surface, and product outcomes emerge from the interlock between them.
The wider product team
The tripartite is a coordination and accountability layer, not the entire product team. Each PM anchors a wider sub-team that does the depth work: programme decisions live with the tripartite, craft depth lives with the sub-teams they represent.
Ops PM
Product Lead
Usually the Ops Manager (OM)
Owns the operational problem and mission outcomes.
Anchors: Product owners and lead operational users.
- Owns problem definition: operational pain points, mission outcomes, stakeholder needs from the user/ops side.
- Defines success metrics tied to operational impact, not just delivery.
- Prioritises the backlog against operational urgency and resource constraints.
- Acts as the voice of the end-user community (operators, ops staff) and translates their workflows into requirements.
- Owns relationships with operational stakeholders and sponsors, managing expectations and securing buy-in across the chain of command.
- Owns business case and resourcing justification — articulating why the problem is worth solving and what it costs not to.
- Validates that proposed solutions (from UX/Tech PM) actually solve the operational problem as framed, not just a plausible adjacent one.
- Owns go-live readiness from an operations standpoint: training, rollout, change management, adoption.
- Owns post-launch outcome tracking — whether the operational metrics defined upfront actually moved.
UX PM
Design Lead
Usually the UX Architect
Owns the user experience and product value proposition.
Anchors: The UX design team.
- Owns the experience layer: how the product behaves, feels, and is structured for the user.
- Translates ops requirements into interaction models, information architecture, and design specs.
- Plans and runs user research — interviews, contextual inquiry, journey mapping — to ground design decisions in observed behaviour rather than assumption.
- Produces working reference implementations (front-end and back-end) that let design intent be validated through real interaction, not just static mockups.
- Owns iterative design validation — usability testing, A/B testing, design critiques — and uses findings to revise the working artefact before handoff.
- Maintains design system / pattern consistency (e.g. PRIZM compliance) and ensures new components extend rather than fragment the system.
- Owns interaction and content design decisions: navigation logic, error states, empty states, microcopy, accessibility considerations.
- Owns the design-to-handoff package — documenting design rationale, interaction logic, and known limitations so Tech PM can assess hardening scope accurately.
- Owns design QA post-build — confirming the hardened / productionised version hasn't drifted from the validated design intent.
Tech PM
Tech Lead
Usually the Development Programme Manager
Owns technical delivery and solution implementation.
Anchors: The development team.
- Owns programme management, delivery planning, and dependencies.
- Technical authority; provides engineering oversight and technical governance.
- Owns system architecture and technical solution design.
- Owns architecture review and integration — assessing whether the prototype's approach fits the broader system architecture (data models, APIs, existing services).
- Owns non-functional requirements: security, performance, scalability, compliance, and technical quality.
- Owns production hardening — closing the gap between working prototype and production-grade: error handling, logging, monitoring, resilience to edge cases.
- Owns technical debt accounting — deciding what in a prototype is kept as-is, refactored, or rebuilt.
- Owns security and compliance sign-off — pen testing, data handling, classification boundary compliance; not self-certified by whoever built the prototype.
- Manages engineering capacity and sequences the path from prototype to maintained product.
Coming next
How the three roles collaborate through the flywheel — which role leads which phase, and where the handoff surfaces are (PRDs, prototype repos, architecture reviews, DASH). Draft landing in a future iteration; the current page focuses on role accountability.
Where the roles map to the Quality Model
This structure is why the Quality Model divides functional code (owned by UX PM) from NFR code (owned by Tech PM), and why the assurance layers span both. Ops PM sets the outcome bar those two streams are ultimately measured against.