Goal Path Planning

Roadmaps fail when they try to show everything without distinguishing what matters. Goal path planning starts with the outcome you're committed to and works backwards — so every milestone either leads to the goal or it doesn't, and the roadmap makes that distinction visible.

How Goal Paths Work

A goal path is a highlighted chain of dependencies from your current work to a business goal. On the visual roadmap, goal path dependencies appear as amber animated arrows (thicker than regular purple dependency arrows).

When you mark a dependency as "on goal path":

• It appears in execution order calculations and delivery forecasts
• It's prioritized for team assignment
• It shows in the "On GoalPath only" filter
• It's highlighted in automatic progress reports

Milestones not on the goal path remain visible but are deprioritized — they're possibilities, not commitments.

Reverse Planning: Start with the Outcome

Instead of planning forward from where you are, start with where you need to be.

Step by step

1. Create a Goal representing your desired business outcome (e.g., "Enterprise-Ready Product")
2. Ask: "What milestone must be completed right before this goal?"
3. Create that milestone and connect it to the goal with a dependency
4. Repeat for each milestone: "What must be done before this?"
5. Mark the chain as "on goal path" to prioritize it

This creates a dependency chain from your current state to your goal:

Every milestone justifies its existence by answering: "Does this need to happen before we reach the goal?"

Why reverse planning works

When you plan forward, scope creeps in quietly — each addition seems small. When you plan backwards from a goal, the roadmap becomes a constraint. Work that doesn't serve the goal is visible as off-path, making it easier to defer or cut.

Commitments vs. Explorations

Real projects involve alternatives and experimentation. Your roadmap should capture possibilities without committing to all of them.

Example: Exploring two approaches

Both milestones connect to the goal, but only "Guided Checklist" is on the goal path. The tutorial stays visible as a backup if the checklist doesn't work out.

Benefits of this pattern:

• Preserve context about decisions not taken
• Pivot quickly if the initial approach fails
• Filter to "On GoalPath only" to see committed work
• Stakeholders see what you're pursuing vs. what you're considering

Goals with Forecasts

Each goal on the roadmap has a delivery forecast based on the work that leads to it. The forecast follows the dependency chain:

• Add scope to a goal path → the forecast extends
• A prerequisite falls behind → the goal's expected date shifts
• Complete work ahead of schedule → the forecast tightens

You see the impact of scope decisions before you make them — not after the deadline passes.

Using Goal Paths in Practice

Strategic planning

Use goals to represent quarterly OKRs or business initiatives. Connect the milestones that contribute to each goal. The goal path shows which connections you're actively pursuing — your current strategy, not all possible strategies.

Multi-team coordination

When multiple teams contribute to a shared goal, the roadmap shows how their work converges. All teams can see which of their milestones are on the critical path vs. exploratory work.

Trade-off conversations

When stakeholders can see what's on the goal path and what isn't, the conversation shifts from "can we add this?" to "what does adding this do to our timeline?" Goal paths make trade-offs visual, so decisions happen with full context.

Sub-goals

Large goals can be broken into smaller sub-goals. Create a new goal for each sub-goal, then connect milestones to those sub-goals instead of directly to the top-level goal. This creates a hierarchy: strategic goals → tactical sub-goals → concrete milestones.

Best Practices

1. Be intentional with the goal path. Only mark milestones as "on goal path" if you're actively committed to them. Keep alternatives visible but off-path.

2. Use goals sparingly. Create goals for significant business outcomes, not every feature. Typical projects have 3-7 major goals.

3. Review regularly. As priorities change, update the goal path. Move milestones on or off the path as your strategy evolves.

4. Keep dependency chains short. Long chains increase risk and forecast uncertainty. Parallel work is better than sequential when possible.

5. Use spatial layout meaningfully. Position goals as a "north star" (often top-right). Flow dependencies left-to-right (past → future). This makes the path visually intuitive.

FAQ

Q: What's the difference between a dependency and being on the goal path?

A: Dependencies are prerequisite relationships ("A must finish before B starts"). The goal path is your chosen strategy ("these are the milestones we're focusing on now"). A milestone can have dependencies without being on the goal path — it might be an alternative approach you're keeping as a backup.

Q: Can I have multiple goal paths?

A: There's one goal path per project. You can have parallel branches on that path — multiple milestones contributing to the same goal. For separate initiatives, use different projects.

Q: Should everything on the roadmap be on the goal path?

A: No. The roadmap should contain explorations, alternatives, and "someday maybe" ideas. Only milestones you're actively committed to should be on the goal path. This keeps your strategy clear while preserving context about other options.

Q: Can milestones contribute to multiple goals?

A: Yes. You can connect a milestone to multiple goals via dependencies. The roadmap visualizes all these connections, making it easy to see how work contributes to different objectives.

Q: How do I set a milestone as "on goal path"?

A: When creating or editing a dependency between milestones, toggle the "on goal path" option. This highlights the dependency as an amber animated arrow on the roadmap.