From roadmap to work—and back again

Workomator keeps planning and delivery connected without making them the same thing. The project holds the shared direction; Builder holds the work you are actively taking forward. Pull a feature or specification into Builder by reference, so the project stays canonical while the work remains personal and focused.

1. Start with the durable context

Before creating a plan, capture the information that should guide every later decision: the project brief, product language, accepted decisions, constraints, and useful references. Put that in Project memory and the wiki.

This is the context that features and specs inherit. Do not repeat it in each work item unless a detail is unique to that item.

2. Put outcomes on the roadmap

The roadmap is a sequence of meaningful outcomes, not a long backlog. Add milestones for the changes the project needs to accomplish, then order them and mark the one that is active.

For each milestone, record the outcome, any important constraints, and the target window if it is known. Update the roadmap when the sequence or the definition of success changes—not just because a task was completed.

3. Plan features in the right horizon

Create a feature when you can name the product capability, the intended outcome, and the signal that would show it worked. Give it a horizon such as Now, Next, or Later, and connect it to the milestone it supports when that relationship is clear.

Features answer: what should the product do, and why does it matter? They are the bridge between a roadmap outcome and the detail needed to build it.

4. Write and review a spec

Create a spec when a feature needs a build-ready definition. The spec describes expected behavior, scope, review state, revision history, and the version that is ready to publish.

Link the spec to its feature. That keeps the implementation detail tied to the product outcome, while the feature remains useful as the long-lived planning record.

5. Pull the right item into Builder

When you are ready to act, choose Pull to Builder on the feature or spec. Workomator adds a personal Builder card that points back to the canonical project record instead of copying it into a second version.

In Builder, use the linked context to make the next move, develop the implementation, or prepare the item for review. The project record remains the source of truth; Builder is your focused place to advance the work.

6. Bring meaningful changes back to the project

As work changes the product direction, update the record where that change belongs:

• update Project memory when a decision, constraint, or shared reference should persist;
• update the wiki when the team needs supporting knowledge or product language;
• update the spec when behavior, scope, or the approved revision changes;
• update the feature when its outcome, horizon, or delivery status changes; and
• update the roadmap when the order, active milestone, or outcome sequence changes.

Not every implementation note needs to be promoted. Bring back the information that will help the next person understand why the product is the way it is.

A simple operating rhythm

Keep the rhythm lightweight: establish context, plan the outcome, shape the feature, define the spec, pull it into Builder, and update the shared record when the work changes the plan.

The loop is not paperwork. It is how the roadmap, feature list, specifications, and memory continue to describe the same product as it evolves.