Structuring Roadmap Timeframes and Time Horizons

Choose roadmap timeframes for a GO product roadmap: dates or quarters on internal plans, coarse horizons on external ones, and goals sized to fit.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

The date row is the top row of the GO product roadmap template. Roman Pichler defines it as the date or time frame when a goal should be met (GO Product Roadmap template and checklist). Structuring roadmap timeframes means making three decisions: how far ahead the whole roadmap looks, how long each goal's timeframe is, and how precisely the dates are stated for each audience. This skill covers all three. For the roadmap format itself, see the GO Product Roadmap page.

On the horizon, Pichler's rule is to look only as far ahead as you realistically can. He writes that "the further we look into the future, the less we can see", and that product roadmaps benefit from a twelve-month horizon in his experience, assuming the product strategy covers at least that period (Choosing the Right Planning Horizons for Your Product). For a brand-new product about to launch an MVP, he suggests you may not be able to plan the next twelve months without speculation and may be better off waiting for users' response.

On goal timeframes, Pichler likes quarterly goals and finds they often work well, but he does not require them. His guideline is that roadmap goals should be no smaller than six weeks and no bigger than four months (Get the Outcomes on Your Product Roadmap Right). A quarterly product roadmap is therefore a sensible default, and a goal that needs two months should get two months.

On date precision, the answer depends on the reader. Pichler recommends dates or narrow timeframes on internal roadmaps, which align development teams and stakeholders, and coarse timeframes or no dates on external, customer-facing ones (Should Product Roadmaps Have Dates?). Dates on an internal roadmap help capture real deadlines and check whether the plan is realistic. Dates on an external roadmap tend to be read as promises.

The output of this skill is a date row that states each goal's target date or timeframe, a planning horizon that matches what you can see, and a coarser version of the date row for any external view.

How It Works

Start by checking the planning model. Pichler places the roadmap between a product strategy, which he sees covering roughly six to eighteen months depending on the product's life cycle stage, and the product backlog, which holds the details such as epics and user stories (Choosing the Right Planning Horizons). The roadmap cannot sensibly look further ahead than the strategy it implements. If the strategy is short-lived or unvalidated, the roadmap horizon shrinks with it.

Then size each goal's timeframe. Goal size and timeframe are the same decision seen from two sides. A goal that would take a year needs splitting; a goal that fits in a fortnight is a sprint goal. Quarterly timeframes make planning easier and help manage stakeholder expectations, Pichler notes, and they align naturally with OKRs, which are usually set per quarter (OKRs and Product Roadmaps). He also describes cases for shorter timeframes, such as six weeks or two months for a young product facing uncertainty, and longer ones for a stable product making incremental changes.

Next, decide what the date cell says. For an internal roadmap, Pichler's checklist suggests a target date or a specific time frame, such as a date or a quarter. He argues that internal dates help in two ways: they capture deadlines, like a seasonal product that must be ready before the main sales period, and they let you check that the plan is realistic using an iron triangle of goal, date, and budget, where one corner must stay flexible (Should Product Roadmaps Have Dates?).

For an external roadmap, the date cell gets coarser or disappears. Pichler suggests timeframes big enough to avoid a death march, such as six-month periods or annual ones like this year and next year (Should Product Roadmaps Have Dates?). He also mentions sequencing releases on a now-next-later grid for external roadmaps (10 Tips for Creating an Agile Product Roadmap). That grid is the format Janna Bastow describes as replacing the timeline with time horizons (ProdPad).

Finally, remember that dates are tested at every review. Slower progress or new data can change a goal's date, and Pichler recommends reviewing the roadmap at least once every three months as a rule of thumb.

Step-by-Step Guide

Step 1: Set the planning horizon

Look at the product strategy and ask how far ahead it is validated. Set the roadmap horizon no further than that, and shorter if the product is new. If you cannot see beyond the next release, build a single goal for now and add the roadmap after you have user feedback. Write down the horizon and the reason for it.

Step 2: List hard deadlines and planning rhythms

Collect the dates that genuinely constrain the plan: seasonal windows, contractual commitments, regulatory deadlines, and events the product must be ready for. Note the company's planning rhythm, such as quarterly OKRs or budget cycles. These are the fixed points the timeframes have to respect.

Step 3: Size each goal's timeframe

With the development team, estimate roughly how long each goal will take. Use a quarter as the default where it fits, and deviate when the goal clearly needs less or more. Split goals that exceed about four months and merge goals smaller than about six weeks. The output is a timeframe per goal.

Step 4: Check realism with the iron triangle

For each goal with a date, ask which of goal, date, and budget can flex if things go wrong. If the date is fixed, the goal must be allowed to shrink; if the goal is fixed, the date or budget must be allowed to move. Confirm that the plan does not rely on overtime. Adjust timeframes that fail this check.

Step 5: Write the internal date row

State a target date or timeframe for each goal: a specific date where a real deadline exists, a month or quarter elsewhere. Make later columns less precise than earlier ones, since confidence falls with distance. Mark any date that is a hard external deadline so readers can tell it apart from a target.

Step 6: Derive the external date row

For the customer-facing view, replace specific dates with coarse periods, or remove the date row and show only the sequence. Check that nothing in the external view could be read as a delivery promise you are not prepared to keep. Keep the external view generated from the internal one so they never contradict each other.

Step 7: Revisit dates at each review

At every roadmap review, compare progress with the dates. Move dates, trim goals, or change budget deliberately, following the flexibility you agreed in step four. Tell stakeholders about date changes promptly, since a quietly slipping date does more damage than an announced one.

Best Practices

• Match the horizon to what you can see. A detailed column for a period you cannot forecast is speculation, which Pichler warns makes stakeholders lose trust in the roadmap (Three Common Product Roadmapping Mistakes).
• Use quarters as a default and deviate on purpose. Goals should be as long as the outcome needs, within Pichler's range of six weeks to four months.
• Keep one flexible corner. Every dated goal needs an agreed release valve, whether scope, date, or budget.
• Make precision fall with distance. The nearest column can carry a date; the last one might only say a half-year.
• Separate targets from deadlines. Readers treat every date as a promise unless you show which ones are fixed by the outside world.
• Keep internal and external views in one source so a change to one updates the other.

Common Mistakes

• Dates on a public roadmap: Customers and sales teams read specific dates as commitments, and missed ones damage trust. Use coarse periods or sequence only.
• Forcing every goal into a quarter: A goal that needs six weeks padded to a quarter wastes time, and a goal that needs five months squeezed into one fails. Size the timeframe to the goal.
• Planning too far ahead: A roadmap that looks beyond the product strategy fills its later columns with guesses. Shorten the horizon.
• Treating every date as fixed: Without a flexible corner, slips turn into overtime and quality cuts. Agree in advance what gives.
• Letting dates drift silently: A date that moves without anyone being told erodes trust faster than an announced change.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: GO Product Roadmap

Related Skills

• GO Product Roadmap Template: How to Build One
• Defining Goals for a GO Product Roadmap
• Setting Metrics for GO Roadmap Goals
• Mapping Features to GO Roadmap Goals
• Aligning Stakeholders with a GO Product Roadmap
• Reviewing and Adapting GO Roadmap Goals

Sources

• Roman Pichler: GO Product Roadmap template and checklist
• Roman Pichler: Choosing the Right Planning Horizons for Your Product
• Roman Pichler: Get the Outcomes on Your Product Roadmap Right
• Roman Pichler: Should Product Roadmaps Have Dates?
• Roman Pichler: OKRs and Product Roadmaps
• Roman Pichler: 10 Tips for Creating an Agile Product Roadmap
• Roman Pichler: Three Common Product Roadmapping Mistakes
• Janna Bastow: Why I Invented the Now-Next-Later Roadmap

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.