Milestone

Quarterly plans often had only a start and an end. In January a team decided to build permissions management, and at the end of March everyone gathered to find out whether it happened. The problem was the two and a half months in between, where there was no way to say how the plan was doing.

What came up in weekly meetings was usually some version of "going well" or "almost there." Nobody listening had grounds to push back. With no written statement of what should be true by now, all that remains is the owner's sense of it, and that sense runs optimistic — what's built is visible and what's left is not.

Pagedeck lived this. A project reported as on track through all of February turned into a one-month slip in the second week of March. Looking back, it had been stuck since early February, but with no standard for judging stuck, the owner didn't know he was late either. By then Sofia had told two enterprise accounts to expect the end of March.

A milestone plants a judging point inside those two and a half months. That's the whole idea: learn that a plan has slipped partway through rather than on the day it was due.

One milestone is a date and a state bound together in a sentence. A date alone leaves nothing to look at on the day, so the conversation falls back to asking the owner how it's going. A state alone has no deadline, so the day to check never arrives.

A milestone worth writing carries three things.

1. The point in time — when the check happens. On a quarterly plan, usually every two to four weeks. Tighter and the checking becomes the work; looser and there's no room left to react once a slip is visible.
2. The state expected by then — a sentence someone can rule on. Not "end of August" but "by the end of August, five internal teams have configured permissions on their own." The first tells you the date passed. The second tells you the plan did.
3. Who rules on it — whoever says done or not done. When the people who built it judge their own work, the optimism above walks right back in. Usually it's the group that receives the output.

The ruling has two values: done or not done. Allow "80 percent there" and the milestone dissolves back into feelings. If any condition is unmet, it's not done, and what remains gets written down along with how many days of work it represents, since that number is the raw material for adjusting the next one.

What to do on a miss is also decided in advance. There are three options: cut scope, move the date, or add people. The practical value of a milestone is that one of the three gets chosen while choosing is still possible. In the last week of March the only remaining option is moving the date, and that is the most expensive of the three because it is the one other teams have already planned around.

Roadmaps are the most common home. On a timeline roadmap, which pins work to calendar boxes, milestones appear as points inside the quarter. On a now-next-later board, which sorts by urgency instead of dates, they attach only to items in the now column — work in the later columns hasn't started, so there's no state to describe yet.

They do the same job inside an epic, a large chunk of work that breaks into several stories. Leaving a two-month epic whole makes a mid-point check impossible, so three or four checkpoints go inside it and get reviewed as each one comes up. The checkpoints are usually the moments where something becomes usable by someone other than the person building it.

They also carry outward commitments. When a schedule is being matched with an enterprise customer or progress is being reported to investors, a milestone is the only point the other side can hang their own plan on. Here, handing over one general availability (GA) date — the point where everything is open to everyone — earns less trust than handing over the checkpoints leading to it. A slip then gives the other side time to adjust with you.

Milestones sit at a different level from objectives and key results (OKR), the practice of splitting a goal from the results that confirm it. An OKR sets what the quarter is for; a milestone is a checkpoint on the road to it. Written into the same box, one of the two gets pushed out.

"The next milestone is Friday. Do we pass it as things stand?"

Asking in advance whether the stated conditions will be met by the date.

"That's a date, not a milestone. Write down what has to be true."

The state to rule on is missing, so nobody can tell whether it was met.

"We missed the second milestone. Let's decide now whether to cut scope or move the date."

The slip is confirmed, so pick one of the three options.

The quarter Pagedeck built permissions management, there were three milestones: by the second week of February, roles can be created and deleted in the settings screen; by the first week of March, five internal teams have configured it themselves; by the third week of March, one enterprise customer is running on real data. The second one was missed, and Mia moved external partner invitations into the following quarter on the spot, which protected the third. Sofia never had to give her customers a new date.

Using milestone as another word for deadline is the most frequent mistake. Both are points on a calendar, so the confusion is natural. But a deadline demands that something be finished by a date, while a milestone proposes looking at what exists on that date. The direction is opposite. Read as a deadline, a team builds the minimum needed to pass on the day and carries that much debt into the next checkpoint, which is how a plan can clear every milestone and still arrive at the end of the quarter with nothing shippable.

The other mistake is assuming more is better. Frequent checks feel reassuring, so the temptation is weekly. But every checkpoint brings collecting the state, ruling on it, and adjusting when it's off. At weekly spacing that work returns every week, and within a month or two some milestones pass without anyone ruling on them. Once that happens, the rest become decoration. Three to five per quarter is usually enough.