Timeframes and the roadmap disclaimer

How far ahead a roadmap can honestly look depends on two things: the product's life cycle stage, met in Gathering inputs, and how fast its plans really change. The timeframe unit should follow both.

A product in introduction is still learning what customers will use, so plans change every few weeks: a short horizon in months, or simply Now / Next / Later, which shows order and falling certainty without pretending to know the month. A product in growth usually plans in quarters. A mature product with long cycles, such as hardware or a regulated service, can look ahead in halves or years.

One page can mix units, as long as each column carries its calendar meaning. CatChow needs exactly that: a mature subscription, a young clinic channel that is still learning, and a board that thinks in quarters. Three columns labeled “Now: to the end of December”, “Next: January–June” and “Later: beyond June” serve all three.

The wrong unit hurts either way. Too fine, and every guess becomes a promise that slips. Too coarse, or none at all, and readers lose the order they need.

Three column names mean little until the page says what each one promises, in the calendar and in commitment. Now is this quarter, to the end of December: the team is working on it and fairly sure. Next is January to June: the problem is clear, the solution still open. Later is beyond June: a direction the team believes in, without detail.

Filling the columns needs an order, and a roadmap has two levels of ordering. Themes are ordered by strategy: which objective they serve, whether they sit on the customer's critical path, what depends on what, and how strong the evidence is. Candidate solutions inside a theme are ranked separately; that is module 4's job.

Now is the theme order cut at real capacity: as many themes from the top as the engineering team of Lucy, the tech lead, can actually work on by December. Urgency from sales, a founder's enthusiasm or a wish to look ambitious only overfill it, and whatever doesn't fit becomes a broken promise in January. Order inside Next matters too: its top theme moves up first.

Certainty falls from left to right, and so does the level of detail. Only Now carries fairly firm commitments, and even those are about working on a problem, not about shipping a particular feature by a particular day.

Next says we will work on this problem soon; the solution may still change. Later says we believe in this direction; a Later theme may change, merge with another or drop out as the team learns. It isn't a queue of promises with a later delivery date.

That's exactly how many readers misread it. A client who hears “it's in Later” often remembers “yes, eventually”. Sales may repeat it as a commitment. So say it on the page, and say it in person: Later is where directions live until evidence earns them a place in Next.

The detail should follow the certainty too. A Now theme may show the solutions being tested. A Later theme is one line: the need, linked to an objective, and nothing that looks like a specification.

The most common complaint about a Now / Next / Later roadmap is that Later becomes a dumping ground. Every request lands there “so nobody feels ignored”. Clients hear a promise, the team inherits a pile nobody chose, and the column soon outgrows Now and Next together.

Three rules keep it honest. First, Later holds only themes linked to an objective, and only as many as the team could plausibly reach within a year. Second, everything else goes on a separate “not now” list (module 4 builds it properly), each item with a one-line reason, so requesters get a real answer instead of a vague maybe. Third, prune Later at every review: whatever hasn't moved in three monthly reviews gets promoted, merged or dropped.

Two shortcuts make things worse. A rough month on each Later item turns guesses into dates people will quote. Writing Later items as features (“loyalty points”, “dark mode”) invites clients to wait for them. Write themes, keep the list short, and let the “not now” list carry the rest.

Now, Next and Later are relative to today, so the columns roll. At each quarterly review the calendar labels move on, the top theme of Next moves into Now, and the strongest theme in Later can earn its place in Next.

But a theme doesn't leave Now just because something shipped. It leaves when its key result has moved. Reminder emails can go live on time while cancellations citing running out stay at 30%; ticking off the release and moving on is the feature factory from Outcomes over outputs in a new disguise. If the number hasn't moved, the theme stays and the team tries the next candidate solution.

When a theme is done, don't delete it at once. Keep a short strip of “Done, and what changed” on the page for a quarter or two: what the team delivered and what the number did. At the end of December it could read: “Done in Q4: reminder emails. Cancellations citing running out: 30% → 26%.” That track record is what makes readers trust the columns that are still uncertain.

A board asking “roughly when?” rarely needs ship dates. It wants to know when its money turns into results. So give it dates for evidence: the moments when you'll know whether a theme works.

CatChow can keep this one: the pilot in two PurrPoint clinics starts in November, so the first stock-out figures arrive in early December. That date doesn't depend on guessing how long the solution will take to build.

For the bigger steps, give order and dependencies instead of a guessed month. The rollout to all 14 clinics depends on the pilot results and on the new warehouse system. Saying so answers “when” more honestly than “March”, and it tells the board what to watch.

Avoid both easy exits. A precise ship date for a solution the pilot hasn't chosen is a promise you'll take back. “We don't do dates” or “some time next year” leaves the reader with nothing to plan around. The honest middle is a column, a date for evidence and what the next step depends on.

An outcome-based roadmap avoids guessed ship dates, but it doesn't pretend the calendar doesn't exist. Some dates are set by someone else: a trade conference, a regulation coming into force, a partner's season, a contract renewal. These hard external dates belong on the page, shown as events.

CatChow's stand at the national veterinary conference on 23 May is one. Putting it on the roadmap shows everyone a real constraint the plan has to respect.

What you shouldn't do is pin a launch to it before you know the solution. The clinic pilot hasn't chosen an answer yet, so “portal launch on 23 May” is a promise. If it slips, it slips in public, on stage.

Instead, decide what to show at the event at a set moment, for example after the pilot review, together with engineering. If a launch there really matters, make it an explicit trade-off: what else moves to make room? Don't let the date bend the priorities quietly, and don't hide it.

The internal disclaimer from Anatomy of a product roadmap, dated and in plain words, is only the first version. A disclaimer's job is to say what the page doesn't promise, and how firmly it must say so depends on who reads it.

Your own team needs just that internal version: the date of this version, one honest sentence that plans change, and the review rhythm (“we review it every month”). Your sales team needs a rule as well: don't forward the page or quote Next and Later to clients; check with the product team before promising anything.

A partner client reads the roadmap looking for something to rely on, so be firmer: it isn't a commitment to features or dates, the real commitments live in the contract, and you review the plan together on a set rhythm. The public gets the shortest version: direction only, no dates, and a plain request not to base a purchase on it.

Write each one in plain words. Legalese reads as evasive, and a disclaimer nobody understands protects nobody.

Placement and plain words work as for any disclaimer: at the top, where reading starts, never in small grey type at the bottom. What a public or partner disclaimer adds is a third point: what the reader should not do.

“Subject to change” is true of everything and leaves readers to guess. Compare: “This page shows the direction we're taking. Plans change as we learn, so please don't base a purchase on anything listed here.” It says what the page is, that it will change, and that nobody should buy on the strength of it. A partner version also points to where the real commitments live: the contract. A public company has its lawyers check the wording too, because outside readers may act on it.

How it fits together: “Roughly when?” is answered by three things together: a column with its calendar meaning, dates for evidence and for external events, and a disclaimer written for its reader. Next, Going deeper adds how sure the team is and what it is building.