A significant checkpoint or deadline
A milestone is a significant point in a project's timeline that marks the completion of a phase or the reaching of a checkpoint. It has no duration of its own; it is a marker, not a taskTaskProduct SpecificationA unit of work within a story or epicView reference →. The interesting tension is that a milestone can be a flag (we passed here) or a gate (we may not pass until conditions are met), and treating one as the other is how programmes either rubber-stamp failure or grind to a halt.
The word comes from the literal stones that marked distance along Roman roads, and project management kept the metaphor: a milestone tells you where you are along the route. In formal scheduling it became a zero-duration event dividing a plan into phases, a usage the project-management literature still carries).
The consequential evolution was turning milestones into decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → points. Robert Cooper's Stage-Gate system, developed through the 1980s and detailed in his book Winning at New Products, placed a gate before each stage of new-product development. At each gate, a cross-functional group reviews the evidenceEvidenceValidationData supporting or refuting a hypothesisView reference → and decides go, kill, hold, or recycle. The milestone stops being a date you pass and becomes a date you must earn by clearing a bar. McKinsey later argued that most milestones are toothless precisely because they lack this gating function, and recommended "decision gates with real teeth" where a project genuinely can be stopped.
The current debate pits milestone-based planning against outcomeOutcomeStrategyA desired business or user outcomeView reference →-based roadmapping. Output milestones ("ship the redesign by Q3") can be hit while the product fails, because shipping is not the same as moving a metricMetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →. The reconciliation most teams reach is to gate milestones on outcomes, so the checkpoint asks whether the result was achieved, and to keep date-only milestones for genuinely fixed external commitments such as a compliance deadline.
A team building a regulated lending featureFeatureProduct SpecificationA product capability or featureView reference → has a hard external milestone: the new affordability rules take effect on 1 September, and the feature must be live and compliant by then. That milestone is a gate, not a flag. They define its exit criteria explicitly: the affordability check passes the auditor's test suiteTest SuiteQuality AssuranceA suite of related testsView reference →, the data-retention policy is signed off, and the rollback plan is rehearsed. A second, internal milestone (private beta complete) is gated on an outcome, with no fixed date attached: at least 50 beta users complete a loan application without support contact. When beta evidence is thin, the gate holds and the launch milestone moves with it, which is the system working, not failing. A date-only flag would have waved the unproven feature straight at the legal deadline.
In the Unified Product Graph, a milestone sits in the programme-management region as the temporal spine other entities hang from. Projects aim at it through ProjecttargetsMilestonehierarchy, giving a body of work a dated checkpoint to converge on. Its gating power is explicit in two complementary edges: project_targets_milestoneMilestonegatesReleasecross-domain and milestone_gates_releaseMilestonegatesDeliverablecross-domain model the Stage-Gate logic where nothing proceeds until the bar is cleared, while milestone_gates_deliverableMilestonetriggersReleasecross-domain models the flag case where reaching the point fires the next step automatically. Separating gate from trigger in the structure means a team can query, for any milestone, whether it holds the line or merely marks the spot, which is the distinction Cooper's gates and outcome roadmapping both turn on.milestone_triggers_release
Type-specific fields on BaseNode
due_datestringTarget due date (ISO format)
met_on_timebooleanWhether the milestone was met on time
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
4 phases — initial: todo · template: WORK_ITEM
4 edge types connected to this entity.
project_targets_milestonemilestone_gates_releasemilestone_triggers_releasemilestone_gates_deliverable