Operating Lifecycle

Origin & evolution

The idea predates software. Manufacturing has described its work as a defined, repeatable process since the assembly line, and Deming’s Plan-Do-Check-Act loop made the cycle itself the unit of improvement. Lean named the end-to-end flow a value stream🌊Value StreamStrategyAn end-to-end flow delivering value to the customerView reference → and insisted it be mapped as one shared thing rather than re-derived by each team.

In modern product organisations the same pattern reappears wherever a process spans more than one surface. A content operation, an incident🚨IncidentDevOps & PlatformA production incidentView reference → response, a release🚢ReleaseProduct SpecificationA shipped version of the productView reference → train, a sales motion🔁Sales MotionGo-To-MarketA repeatable sales motionView reference →: each is a loop with named stages that several tools and teams each touch a slice of. The recurring failure is that every tool models its own copy of the phases, so the organisation can describe each surface but never the process as a whole.

What distinguishes an operating lifecycle in UPG from a single product’s workflow is governance and reuse. A workflow is something one product team owns and changes on its roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference →. An operating lifecycle is a contract many products conform to: it is defined by a specification📋SpecificationFoundationsA specification entityView reference →, it has no owner, and changing it is a process separate from any one product’s release cycle.

How it works in practice

A platform ships three surfaces (a CMS, a CDN automation layer, and an analytics dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference →) that each touch the content process. Without a canonical lifecycle, each surface carries its own phase model: the CMS calls a step "Publish", the automation layer calls the same moment "Release", the dashboard calls it "Go-live". A question like "what is happening across the whole content process at the distribute stage?" has no answer, because there is no single node to ask about.

With an operating lifecycle, the team defines one canonical loop, Plan & Govern → Create & Manage → Distribute & Automate → Analyze & Optimize → Extend & Integrate, and marks it cyclic: true so the final stage wraps to the first. Each surface’s journey phases🔖Journey PhaseExperience DesignA named phase in a user journey that groups a sequence of actions the user performs to reach a milestone.View reference → realise the relevant canonical stage. The distribute question now resolves across all three surfaces, and the Analyze stage’s metrics🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → close the loop back to outcomes.

Operating lifecycle vs. its neighbours

• User journey🛤️User JourneyExperience DesignAn end-to-end map of a user experienceView reference →. A user journey is one product’s lived path through a surface; an operating lifecycle is the canonical process that journey is an instance of. Journeys are product-specific and many; the lifecycle is shared and singular.
• Lifecycle (state machine). The lifecycle render shape on most entities is a status state machine for a single node (draft → active → archived). An operating lifecycle is a first-class entity in its own right: a named process with ordered stages that other entities map onto, not a status field.
• Specification📋SpecificationFoundationsA specification entityView reference →. A specification is the governed rulebook; an operating lifecycle is one of the things a specification can define. The lifecycle conforms to its spec the way an implementation conforms to a standard.

In the graph

In the Unified Product Graph an operating lifecycle is a registry-hostable canonical entity in the Foundations region. Its stages attach via operating_lifecycle_contains_operating_stageOperating LifecyclecontainsOperating Stagehierarchy, the ordered spine of the loop. It is anchored to its governing rulebook by specification_defines_operating_lifecycle, so a lifecycle without a defining spec is an ungoverned root. The cyclic flag plus each stage’s order express the sequence and the wrap. Real product phases reach in from the Experience region via journey_phase_realises_operating_stageJourney PhaserealisesOperating Stagecross-domain, which is what lets siloed per-surface journeys roll up into one cross-surface process view.