Writing · Marketing Ops · Aug 15, 2026 · 6 min

A website roadmap with no dates on the cards

Website work arrives from everywhere and gets asked about by everyone, and those are two different problems. The people doing the work need to know what is in this week. The people asking need to know where a line of work sits this quarter. I run both off one set of records so the two answers cannot disagree.

7fields on a card, and no dates
2audiences, asking different questions

Website work arrives from everywhere

A new solution page from sales. A pricing change from product. An SEO fix that has been waiting three weeks. A homepage test somebody agreed to in a meeting nobody wrote down. None of it arrives through one door, and none of it arrives with a size attached.

The failure that follows is predictable. Everything is verbally agreed and nothing is visibly queued, so every request looks like it should start today, and the honest answer to "when can you do this" is a shrug with a tone of voice.

The intake column is how you get to say no

The board opens with a column called requests. Anything asked for lands there first, with a type, a rough size and one line about what it is. Nothing moves out of it until the scope is agreed.

That column does more work than the rest of the board combined. A request sitting in intake is a visible thing that somebody has to decide about. Without it, saying no means saying no to a person. With it, the conversation moves to the queue: this is what is in front of it, so tell me what it goes ahead of.

What a card carries

A card is deliberately small. It holds a title written as the outcome, a type, a size, an owner, the workstream it belongs to, a link to the artifact, and a status. Seven fields, and each one earns its place by answering a question somebody actually asks out loud.

Type matters more than it looks. A new page, a change to an existing page, a technical fix and a piece of research move at different speeds and carry different risk. A board that treats them identically will happily schedule a three-week research task beside a half-hour copy change. Type is also what makes a quarter legible: eleven cards is noise, while eight technical fixes and three new pages is a shape somebody can react to.

Anything longer than one line belongs in the document the card links to. Keeping the card thin means the person who owns the work can revise the thinking without touching the board, and the board stays scannable at the size a person actually reads it.

Rebuild pricing pagenew page · L · conversion
Ownerlinks to the staging URL
Statusin sprint
Fix canonical tagstechnical · S · infrastructure
Ownerlinks to the audit
Statusscheduled
Seven fields per card. The size and the type do the scheduling work that dates are usually asked to do, and the link means the card never has to describe the work it points at.

Two views, one set of records

The same cards render twice. Both views are built by grouping and filtering one set of records, so neither is a document that somebody maintains. One is grouped by status, the other by workstream, and a card moving changes both in the same instant.

The sprint board reads left to right: requests, scheduled, in sprint, then out through the release pipeline. It answers the question the people building things have, which is what am I doing this week and what is behind it.

The quarter map is a grid. Rows are workstreams such as homepage and conversion, solution pages, agent pages, feature pages, SEO and infrastructure. Columns are now, next and later. Each cell carries a state, and proposed work is drawn differently from committed work so the difference survives a glance.

That second view answers a different question: where is this line of work going, and what has actually been committed to. Leadership asks that one. Nobody doing the work asks it while they are doing the work.

Sprint boardrequests · scheduled · in sprint · shipped
Answerswhat am I doing this week
Quarter mapworkstream × now / next / later
Answerswhere is this going, and what is committed
Two audiences, two questions, one set of cards. Maintaining these as separate documents is how a roadmap and a sprint plan end up contradicting each other.

Most teams maintain these separately, and they drift

The common arrangement is a task tracker for the team and a slide for leadership. They start aligned. Then a card moves, the slide does not, and within a month the roadmap presented upward describes work that stopped two weeks ago.

Deriving both views from the same records removes that failure by construction. Moving a card is the only update. There is no second artifact to remember.

Every card points at the thing itself

Cards carry a link to the artifact: the staging URL for a page in progress, the research doc behind a proposal, the workplan for an SEO stream. Status is a URL you can open.

This is the part that removes the most meetings. "How is the homepage test going" has an answer that is a link to the staged version, so the person asking can look at it instead of scheduling twenty minutes to be told about it.

Why there are no dates on the cards

Cards carry a size, roughly S, M or L, and no dates below the sprint level. Dates on individual pieces of website work are fiction, and everyone treats them as fiction, which makes the whole board less trustworthy.

Sizes do the job dates were supposed to do. Three large items in one sprint is visibly wrong before the sprint starts, which is the only moment when that information is useful.

How the sizes get agreed

S, M and L only work if two people mean the same thing by them, so they are anchored to examples rather than to hours. A small is a change inside an existing template. A medium is a page that needs new copy on a layout that already exists. A large is anything needing a new layout, a new component, or a decision from somebody outside the team.

Anchoring to examples survives a change of staff in a way hours never do. Somebody new can size their first card on their first day by comparing it to work already sitting on the board, and the sizes stay comparable across quarters even as the people doing the work change.

The release log is the memory

Shipped work drops into a dated log with the release it went out in. It takes seconds to maintain and answers a question that comes up constantly and is otherwise expensive: when did this change, and what else went out with it.

It also turns the board into a record of what a team produced over a quarter, which is a different and more useful artifact than a list of what it plans to produce next.

Where this breaks

Three failure modes, all of them mine at some point.

The first is a card that sits in the in-sprint column across three sprints. It is usually a large that should have been split, and it hides because the board renders it as active work. A weekly glance at how long each card has held its current status surfaces them.

The second is intake turning into a graveyard. Requests land, nothing is ever declined, and the column grows until people stop reading it. At that point the board has quietly stopped saying no, which was the reason the column existed.

The third is the quarter map growing rows. Every new workstream feels justified the day it arrives, and a grid with eleven rows tells a reader nothing at a glance. Six is the most I have managed to keep legible.

What it costs

The board is only worth having if it is true, and staying true costs a few minutes at the end of each working session. Move what moved. Log what shipped. Put anything that arrived into intake rather than into your head.

That is the whole discipline. It costs a few minutes a day, and it replaced the weekly status round entirely.

Suggested posts