Julien Dambron

Milestones Are Tombstones

· 4 min read

Milestones are made of stone. Move one and it stops meaning anything. They're more tombstones than measures of progress.

I stole that line from Jonathan Smart (Sooner Safer Happier). Here's the problem it names, and what to do instead.

The trap: deterministic thinking on emergent work

Software is unknowable work. You don't know what you don't know until you build it. Yet most planning treats it like a factory: pick a date, promise a solution, then push all the learning and risk to the end, where a change costs the most.

That's "Think Big, Start Big, Learn Slow."

A milestone is the artifact of this mindset: a hard date on a predicted solution. Optimistic dates aren't the problem. Fixed ones are. If you've done this exact thing ten times, a date is a forecast. If you haven't, it's a wish. In emergent work, a fixed date is a lie you've agreed to tell each other.

The tombstone lifecycle

  1. It's carved in stone. A date, a promise, a Gantt bar. Everyone aligns to it.
  2. Reality moves. The team learns something the plan didn't know.
  3. You move it. And now it's invalid. A moved milestone means nothing: it was a commitment to a prediction, not a measure of progress.
  4. Repeat. Every moved milestone teaches the team that dates are theater. Nobody believes the plan, but nobody says so.

Missing the date isn't the damage. The damage is the feeling of control milestones deliver while delivering none. They're the opposite of agility, which is the ability to change direction cheaply. A stone that can't move is the opposite of that.

What it looks like

"The new search ships April 30." That's a milestone. It names a solution and a date. It says nothing about whether search got better.

The same work as a hypothesis:

People abandon search because results are slow and noisy. We believe a thinner result set with better ranking will raise search-to-click. We'll know we're on track when time-to-first-result drops under 200ms and click-through moves from 18% toward 30%.

You can test that. You can kill it. You can be wrong in week two instead of month six. A milestone only lets you defend the date.

Replace them with outcome hypotheses

Instead of promising a solution on a date, frame the bet as a hypothesis:

Due to this insight → we believe this bet → will result in this outcome → we'll know we're on track when these measures move.

Three differences from a milestone:

You still need dates. Marketing has a launch window. Legal has a deadline. The board meets on Thursday. Those are constraints. You manage them. You don't optimize for them. You optimize the outcome.

How you work the bet: slice it

"Think Big, Start Small, Learn Fast." Don't eat the elephant in one bite. Get the thinnest vertical slice of real value into customers' hands as early as you can. Each slice de-risks delivery, generates value sooner, and lets you pivot before sunk cost sets in.

That's how a hypothesis stays honest. A six-month milestone hides learning until it's too expensive to use. A thin slice tells you next week whether the bet is any good.

The frame that holds it together is BVSSH (Better Value Sooner Safer Happier):

Sooner is the one milestones destroy. A carved date makes you protect the plan. A slice makes you protect the learning.

What to do with this

Next time someone puts a milestone on a plan, ask what it's protecting. If the answer is "a date we predicted," you're building a tombstone. Ask instead: what outcome are we betting on, and how will we know we're on track?

The date will move anyway. The outcome is the only thing worth betting on.