Operating Stage

Origin & evolution

Dividing a process into named, ordered phases is the oldest move in process design: the funnel⬇️FunnelGrowthA conversion funnel tracking user progressionView reference →, the pipeline, the value stream🌊Value StreamStrategyAn end-to-end flow delivering value to the customerView reference →, the customer-journey stage. What these share is that the phase, not the single instance, is the unit of measurement and comparison. The natural question is about "the qualify stage" of every deal, not about one deal at a time.

The harder problem, and the one the operating stage solves, is cross-surface roll-up. When five tools each touch the same process, each tends to invent its own phase names. Mapping every tool’s phases onto one shared set of canonical stages is what lets an organisation see the whole process rather than five disconnected slices of it. The stage is the join key that makes that mapping possible.

Sequence is expressed structurally rather than as a label on each stage: stage_order gives the position and the lifecycle’s cyclic flag supplies the wrap from the last stage back to the first. Order lives in one place, so inserting a stage does not require rewriting successor pointers across its neighbours.

How it works in practice

A content team runs two surfaces that both reach the distribute phase: the CMS publishes a release, and a CDN layer automates cache invalidation and edge propagation. Each surface has its own journey phase, "Publish & go live" and "Propagate to edge". Both realise the one canonical Distribute & Automate stage.

Because both phases point at the same stage, "show everything happening at Distribute right now" returns work from both surfaces at once. Because the stage is measured by a metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → (time-to-live for new content, say), a measurement taken at the Distribute stage feeds the Analyze stage, and the loop from work to outcome🏆OutcomeStrategyA desired business or user outcomeView reference → is closed.

Operating stage vs. its neighbours

• Journey phase. A journey phase is a product-specific band of one user journey🛤️User JourneyExperience DesignAn end-to-end map of a user experienceView reference →; an operating stage is the canonical phase it realises. Many journey phases across many surfaces map onto a single operating stage.
• Pipeline stage🧽Pipeline StageSales & RevenueA stage in the sales pipelineView reference →. A pipeline stage is a phase of a specific sales or delivery pipeline instance; an operating stage is the canonical, reusable phase that such pipelines can be modelled against when the process is shared across products.
• Operating lifecycle. The lifecycle is the whole loop; the stage is one ordered band of it. A stage only has meaning inside its containing lifecycle, which supplies both its sequence context and the wrap.

In the graph

In the Unified Product Graph an operating stage belongs to its lifecycle via operating_lifecycle_contains_operating_stageOperating LifecyclecontainsOperating Stagehierarchy and is ordered by stage_order. Real product phases reach in from the Experience region via journey_phase_realises_operating_stageJourney PhaserealisesOperating Stagecross-domain, the bridge that turns per-surface journeys into a cross-surface process view. Each stage reaches into Analytics via operating_stage_measured_by_metricOperating Stagemeasured byMetriccross-domain, which closes the loop from what users do back to whether the process is working.