Move from evidence-backed priorities to a usable roadmap

In Discovery → Direction, use the three views for different questions:

• Active work: what the team has genuinely started shaping now
• Priorities: the saved, editable plan for what should be considered next
• Analysis: the latest complete analysis, including proposals, rankings, uncovered demand, evidence quality, and gaps

Analysis proposes changes; it does not silently rewrite the team plan. Review proposed additions and removals in Priorities before moving work into Active work.

Choose the relevant product scope. A product view and No product are ordered queues; All products is a grouped overview.

For each idea or opportunity, inspect the decision context that is available:

• linked evidence volume, diversity, recency, and severity
• affected accounts and relevant commercial context
• alignment with company goals and product strategy
• expected impact or value
• effort, feasibility, dependencies, and uncertainty
• open questions and readiness

Use ranking lenses to explore tradeoffs, then make the saved decision in Priorities. Do not treat missing evidence as proof of low value, or a high model score as approval to commit.

When a priority moves to Active work, Zentrik preserves a copy of the decision context so the original “why now” does not drift as the record changes.

Promote an idea when the team is ready to manage it as committed product work. Before promotion, confirm:

1. The customer or business problem is explicit.
2. Source evidence and the relevant opportunity remain linked.
3. The intended users and product area are known.
4. Scope boundaries and material constraints are visible.
5. A success check exists.
6. Open questions are accepted, assigned, or resolved.

The initiative becomes the home for the committed problem, scope, artifacts, tasks, decisions, and delivery context. Preserve the trace back to discovery instead of recreating the rationale in an unrelated brief.

From the approved initiative:

• review or create the initiative brief
• draft user stories and acceptance checks
• split stories into actionable tasks
• record dependencies, risks, and technical notes
• estimate work using the team’s available pace and capacity
• group work into milestones or sprint windows where appropriate
• connect Jira, Linear, GitHub, or another delivery path only after the hierarchy and field mapping are reviewed

On the initiative's Schedule tab, Plan timeline lays the drafted work out in time. Each cycle is a heading with its dates and story points, and each task is a bar coloured by the role doing the work. Tasks belonging to other initiatives appear faded, for context, and cannot be changed there. Move a task the same way you move an initiative on the roadmap timeline, described below; a task stays inside the cycle it belongs to.

Generated stories, tasks, estimates, and dates are proposals. The accountable product and engineering teammates should review them before downstream creation or sync.

Use Documents and delivery for the artifact and handoff workflow.

Use the view that answers the audience’s question:

• Now / Next / Later for sequence and commitment without false date precision
• Timeline when milestones, dependencies, or target windows need dates, and when you want to set those dates directly
• Capacity and impact views when the decision is about team load or goal tradeoffs

Reordering work can affect dates, capacity, and goal impact. Review the resulting plan before sharing it as a commitment. If a date is externally fixed, record the constraint rather than allowing the roadmap to imply it was calculated from capacity.

Delivery → Timeline shows the initiatives you have put on the roadmap, grouped by Now, Next, and Later. Use it when the question is when. The dates you set here are the initiative's own start and finish dates.

Read a row

• Each initiative keeps its own colour, so a row stays recognisable while you scroll. The colour identifies the initiative; it does not encode status.
• A bar fills with the share of estimated story points completed. The fill appears only when every estimated task reports progress, so an unfilled bar means the work has not started or cannot yet be measured.
• A completed initiative fades back, so finished work stops competing with work in flight.
• A dashed outline means the initiative has no dates yet. Its row reads No dates yet, and the bar spans the month ahead from today as a starting point. Drag or resize it to schedule the work.
• Past finish date appears beside the dates when a finish date has passed and the initiative is not complete.
• When a bar sits outside the dates on screen, its row shows a small arrow pointing the way. Select the arrow to bring the bar into view.

Change dates

• Drag the middle of a bar to move the initiative and keep its length.
• Drag either end to change only that date.
• While you drag, the exact start and finish appear at the ends of the bar and in the row, so you can see the result before committing to it.
• Release to save. The bar confirms the change, and the message that follows offers Undo.
• To work without a pointer, move focus to a bar and use the arrow keys to move it by a day, Shift with an arrow key to move only the finish date, Enter to save, and Escape to discard. At the Quarter zoom, each step moves a week.

Move around the calendar

• Drag any empty part of the calendar to pan through time.
• Switch between Week, Month, and Quarter. The date in the middle of the view stays where it is, so you keep your place.
• Today returns to the current date, marked by a vertical line.

Change what appears

• Add initiatives puts committed initiatives on the roadmap, and you choose whether they land in Now, Next, or Later.
• Select an initiative's name or its bar to open the record beside the timeline.
• Removing an initiative from the roadmap also clears its start and finish dates, because those dates describe its place on the plan.

A date you set here is a commitment you are making, not a calculation. If a date is fixed externally, record that constraint so the plan does not imply it came from capacity.

Revisit priorities and the roadmap when:

• new evidence changes the severity or reach of a problem
• a study invalidates or narrows an idea
• effort, dependency, or capacity assumptions change
• a committed initiative is paused, replaced, or completed
• delivery status changes downstream
• an outcome creates new evidence for the next decision

Return work to priority review when it is no longer active. Do not preserve its old rank automatically; reconsider it against the current cohort.

A healthy plan has:

• a visible distinction between analysis, the saved priority plan, active shaping, and committed delivery
• evidence and decision context for important candidates
• human review before a proposal changes priority or scope
• initiatives with a problem, owner, scope, success check, and dependencies
• roadmap views that match the audience and do not overstate certainty
• a review trigger when evidence, capacity, or delivery changes