Skip to documentation

Planning and roadmaps

Move from evidence-backed priorities to a usable roadmap

Use this workflow when the team has more credible work than capacity. It separates analysis, the saved priority plan, active discovery work, committed initiatives, delivery planning, and the roadmap so each surface answers one question.

A score is an input, not a product decision. Review the evidence and assumptions behind a candidate, record the human choice in Priorities, and only commit work when the problem, scope, and success check are clear enough.

The roadmap communicates the current plan. It does not by itself prove that an item shipped or produced the intended outcome.

1. Review Direction: now, next, and why

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.

2. Compare the candidates

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.

3. Commit the work as an initiative

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.

4. Turn the initiative into build-ready work

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

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.

5. Choose the roadmap view for the audience

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
  • 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.

6. Review the plan as evidence changes

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.

Expected result

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

Troubleshooting

Check these steps against what you see in your workspace. If something differs, note your workspace name and the screen, then contact us.

Analysis and Priorities disagree

That can be intentional. Analysis is the immutable latest run; Priorities is the human-reviewed saved plan. Review the proposal and record the decision in Priorities instead of expecting analysis to rewrite it.

The roadmap dates look precise but are not trustworthy

Check estimates, dependencies, team capacity, fixed-date constraints, and downstream status. Use Now / Next / Later until the inputs support a dated timeline.

A high-ranked item is not ready to commit

Keep it in discovery or Active work. Resolve the problem frame, evidence gaps, scope, success check, and material open questions before promotion.

Continue from here

Did this guide answer your question?

Your response helps us prioritize missing or unclear documentation.

Still stuck?

Send your question to Zentrik support. This guide will be included automatically.

Ask Zentrik support