Skip to main content
Wildo.ai Coming soon

The product definition

Turn goals into a clear delivery scope

State observable requirements and connect them to the increments intended to deliver them.

Requirements connect to now, next and later delivery phases.

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.

Building a B2B product or an internal tool?

Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.