TBM 225: Milestones and Stepping Stones

I will be in Edinburgh and Hamburg in late June for Turing Fest and Product at Heart. Both are great conferences, and it would be great to connect in person while there.

Short post this week.

I strongly believe in the power of language to "hack" organizational challenges.

Lately, I've become fascinated with—wait for it—the word milestone. This may be a surprise if you've read my newsletter for a while. I've spent a lot of words over the years talking about impact, goals, OKRs, strategies, outcomes, North Stars, etc. But I've been using milestones a ton lately, so I thought I'd share some of my thoughts.

First, let's acknowledge the baggage. In the project management world, a milestone is a specific point in time that marks the completion of a major deliverable. "Hitting" a milestone serves as a checkpoint to measure the progress of a project. If you've been doing this for a while, you probably remember—and have worked hard to forget—those massive lists of numbered/coded milestones in MS Project. The problem, of course, is that milestones in that context tended to have a hollow nature. Sure, the project was "moving forward," but you still wondered if anything would pay off. And the perception that progress was simply about checking off the predefined steps in the journey (especially for product-like work) felt wrong.

But let me flip this around with an observation. In a world of quarterly goals, OKRs, etc., I have noticed that teams often have lost that muscle for thinking about the steps in the journey. I'm not talking about steps in the project-sense or hollow timebox goals like "deliver x, y, and z by the end of the sprint." Instead, I'm talking about meaningful integration, movement, and learning points that focus the team, hold certain assumptions constant, and act as a forcing function.

A forcing function is an aspect of a design that prevents the user from taking an action without consciously considering information relevant to that action. It forces conscious attention upon something ("bringing to consciousness") and thus deliberately disrupts the efficient or automatized performance of a task. (source)

Caught between the dysfunctional world of delivery-centricity and the utopian world of outcome-centricity (and solution agnosticism) mixed with far-off quarterly and annual goals, teams sometimes lose the plot. Getting there will be a function of getting to many places along the way. 

For example, a key milestone might be having N number of external users go end-to-end through a workflow using their data or "forcing" yourself to show V1 of a report prototype in an important meeting and get feedback. I recently met a team who set an immediate milestone of getting any change into production using a new deployment path by the end of the day. They created a string of these daily milestones with increasing complexity and details.

Yes, these are goals—milestones are goals. But they are a particular goal type that forces integration and keeps that near-term sense of focus and urgency.

You know you have a good milestone when it feels slightly uncomfortable. That discomfort is a signal. If it feels like:

• It may be too early

• It may be too small or trivial

• It feels "too minimal."

• You "may need to get creative" to get it done

• It slices across the problem and goes end-to-end (feels integrative)

• You may learn something, and that something might annoy you

• You'll need to "hold some things constant."

• Someone may say, "That's it?"

• You will have to cut scope (not work harder)

• It will either force a pivot or increase confidence (in a major way)

Very practically, it is a reasonable expectation to ask a team to "map out your milestones for the next couple of months (or weeks)."

I also think it is important to avoid language with baggage. The problem with milestone is that it assumes a known road, a known mile marker, and a very linear sense of progress. "If we just hit our milestones, we'll be good." 

My favorite twist lately is thinking of milestones as stepping stones. I asked a team, "What are your stepping stones to get from here to there," and it clicked. It captures the idea that you are building a foundation and have options.

Yes, you may be trying to get to the other side (that part is clear), but you have to think it through. Stepping to one stone may unlock other sets of options, and every stepping stone becomes a “home base” for the next decision.