The short answer
A goal roadmap needs six things: a destination stated as an outcome, the areas that must each hold for that outcome to happen, the dependencies between them, one small active set, evidence that closes each area, and a review date. Anything beyond those six is decoration. Anything missing from them is where the roadmap will break.
Most templates give you the first item and a lot of boxes. The other five are the ones that decide whether the document survives contact with a real month.
1. A destination written as an outcome, not an activity
"Learn Python" is an activity. It has no end state, so nothing can ever close it, and six months later you will still have it on the map feeling vaguely behind.
"Ship a working tool that someone other than me uses" is an outcome. It can be true or false. It tells you which Python to learn and, more usefully, which Python to skip.
The test: could a neutral observer look at your situation in a year and say definitively whether this happened? If not, you have written an activity, and the roadmap will have no way to tell you it is finished.
2. Areas that could each fail independently
Under the outcome, list the things that must each hold. Not steps in sequence — conditions that must be true.
For shipping that tool: the thing has to exist, it has to run somewhere other than your laptop, someone has to know it exists, and it has to survive their first real use. Those fail for different reasons. Sequencing them is premature; naming them is not.
Four to six of these is normal. If you have twelve, some of them are tasks. If you have two, one of them is hiding something.
3. The dependencies you would otherwise discover late
Draw the arrows. Which area cannot start until another one has moved? Which one, if it went badly, would make three others pointless?
This is the section templates skip, and it is where most of the value sits. A goal roadmap that shows six parallel tracks is usually lying — real work has an order, and the order is usually discovered the expensive way. Ten minutes spent asking "what has to be true first?" routinely reorders the whole plan.
In Minty Path these are relationship lines: dashed cross-links kept visually distinct from the solid parent-child hierarchy, precisely because a dependency is not a hierarchy. "Deployment depends on the code existing" is not the same statement as "deployment is part of the code."
4. One small active set
A roadmap that marks everything as current is a list, not a plan. The active set is the part you are working on now, and it should be uncomfortably small — one to three areas.
Minty Path encourages this through Focus, which stays separate from both status and dates. A branch being Focus makes no claim about urgency or timing. It claims only that this is where attention goes. Everything else stays on the map, visible and inactive, which is the state most of a plan should be in most of the time.
The discomfort is the point. If choosing three feels arbitrary, that is the roadmap surfacing a decision you were previously making by accident.
5. Evidence that can close each area
For every area, decide in advance what would prove it done. Not "feel confident about deployment" — a URL that resolves. Not "understand the market" — five conversations you actually had, with notes.
Minty Path makes this structural rather than aspirational: a branch cannot reach Complete without an Evidence entry attached. Evidence can be a file, a link, a screenshot, a result, or a written note explaining how you applied something — but it has to exist. You cannot close a branch by deciding you are done with it.
Parent branches then complete on their own. They are structural, carry no manual status, and become Complete once every end branch beneath them is Complete. You are never asked to judge whether a whole category is finished, which removes the most common place where roadmaps quietly drift from reality.
6. A review date, and permission to be wrong
Put the next review on the map itself. Monthly is usually right for a year-long goal; weekly is enough for the active set alone.
Distinguish the two kinds of date while you are there. An Aim date is a soft target you chose and can move without consequence. A Deadline is fixed by something outside you — an application window, an exam, a contract. Minty Path keeps a passed Aim date calm rather than rendering it as overdue, which sounds like a small interface decision and is not: once every self-imposed target turns red, red stops carrying information, and the one date that genuinely could not move gets ignored along with the rest.
What does not belong on it
- Every idea you have had about the goal. A roadmap is a filter, not an archive. Ideas you are not acting on belong in a note or an inbox, not as branches implying they are part of the plan.
- Dates on everything. Most branches need no date at all. A date you invented for motivation teaches you to distrust your own dates.
- Percentage complete. It invites you to feel progress on work that has produced nothing yet. Evidence closes an area; estimates do not.
- More than one destination. If the map has two outcomes, it is two roadmaps sharing a page, and they will compete for the same evenings. Split them and make one Primary.
A worked shape
For "get a job that does not require night availability," the map might hold: skills that make me hireable elsewhere (Focus), evidence I can show someone (Focus, depends on skills), financial runway, people who would refer me, and the conversation with my current employer (depends on having an offer). Two active. Three visible and waiting, on purpose. The dependency arrows make the order obvious rather than something you rediscover in month four.