
Turn goals into a clear delivery scope
Requirements explain what people need to do and what quality the application must provide. The roadmap explains which increments are intended to deliver those commitments.
Wildo keeps the two connected by references. A phase can point to the requirements and success criteria it serves, making scope easier to review as the product evolves.
Example — Plan a usable first release
The first increment makes customer ownership and next actions visible. Its requirement states the observable behavior; the roadmap phase names that requirement and the product goal it supports.
For engineers
Make the requirement observable
This illustrative requirement belongs in the surrounding requirements snapshot:
import type { FunctionalRequirementConfig } from '@wildo-ai/saas-specifications';
export const ownedFollowUp: FunctionalRequirementConfig = {
ref: 'functional-requirement-owned-follow-up',
statement: 'Every open deal can show an owner and a dated next step.',
rationale: 'Make customer commitments visible to the whole team.',
acceptanceCriteria: [
'A team member can assign an owner to an open deal.',
'The record displays the next action and its due date.',
'The team can identify deals missing either value.',
],
icpRefs: ['icp-small-team'],
jobRefs: ['job-keep-next-step-owned'],
};
The acceptance criteria are statements to verify. They do not become executable tests simply by being declared. Customer and job references connect the behavior to its intended audience.
State the quality of the interaction too
A functional requirement says that a person can record follow-up. A quality requirement can say how easily they should be able to do it. This illustrative target belongs in the snapshot’s nonFunctional collection:
import { NonFunctionalRequirementKind, type NonFunctionalRequirementConfig } from '@wildo-ai/saas-specifications';
export const quickFollowUp: NonFunctionalRequirementConfig = {
ref: 'nfr-quick-follow-up',
kind: NonFunctionalRequirementKind.USABILITY,
statement: 'A trained teammate can record a next action in under thirty seconds.',
metric: 'Elapsed time from opening the record to saving the next action in a usability session.',
acceptanceCriteria: ['Each participant completes the task without assistance within the target time.'],
};
The target and test procedure are product decisions, not measured results. Both functional and quality requirements can be named in a phase’s deliversRequirementRefs and checked for delivery coverage.
Put those commitments into the roadmap
import { RoadmapPhaseHorizon, RoadmapPhaseKind, type RoadmapPhaseConfig } from '@wildo-ai/saas-specifications';
export const firstRelease: RoadmapPhaseConfig = {
ref: 'roadmap-phase-shared-follow-up',
sequence: 10,
title: 'A shared follow-up workspace',
objective: 'Make customer ownership and the next dated action visible.',
horizon: RoadmapPhaseHorizon.NOW,
kind: RoadmapPhaseKind.MVP,
deliversRequirementRefs: ['functional-requirement-owned-follow-up', 'nfr-quick-follow-up'],
deliversSuccessCriterionRefs: ['success-criterion-first-working-pipeline'],
};
The phase’s sequence records relative order; its horizon and kind describe planning intent. The reference lists explain what the phase is meant to deliver. They do not report implementation progress.
Review scope and delivery separately
Export the requirement snapshot and roadmap through requirementsSpecification and roadmapSpecification. Their validators check supported structure and references; the coherence report uses family context to inspect coverage and dangling links.
When a requirement moves out of a phase, review the connected success criterion and offer as well. Keep the roadmap honest about intended scope, and use application verification to establish delivered behavior.