Planning for uncertainty

The Overlap #43

The Overlap is a newsletter somewhere between product development and organizational development. It comes out every other Wednesday.

Found from this block

You’re a smart PM. You know traditional timelines, roadmaps, and Gantt charts don’t cut it. You know that timelines outdate themselves the moment the work starts. You know it’s a trap to assume that your timeline is 100% certain—no one figures out “every little piece of effort” at the start of the project. You know that there are better ways to do this.

And yet. You often get asked, “Hey, can you make a timeline for this project?”

Your organization loves timelines. You want your org to plan in a way that acknowledges uncertainty yet provides clarity on how they’ll realize their strategy.

What do you do?

First, understand the "job" the plan accomplishes

As Behzod put it, planning is meant to be valuable for everyone who participates. The plan is meant to be valuable for everyone who doesn't.

Behzod Sirjani @beh_zod

@kevinyien @timcasasola Definitely — *planning* is meant to be valuable for everyone who participates. *The plan* is meant to be valuable for everyone who doesn’t.

For designers and developers, the plan helps them prioritize their work. And gives them clarity on major launch dates that they work towards.

For product marketers, the plan helps them communicate to your product's audience major dates. For features that are being built on time, they’ll feel confident to announce the dates those features will launch. For features that are taking longer than expected, they’ll know not to promise a date there.

For product managers, the plan helps set expectations with leaders. It also helps them unblock dependencies: If the PM's team wants to work on a specific surface that impacts another team, that other team needs to know and be aware.

For leaders, the plan helps set expectations with their peers. And also helps them advocate for what their team needs: If the leader's team has a lot on their backlog, but not enough resources on their team, they have a strong case to ask for more resources.

The point: the plan serves many different jobs for many different people. Your job is to get clear on those jobs.

Second, help your team reflect on their current way of planning

Help your colleagues see that the plan rarely matches reality.

You can take a Gantt chart that was created at the beginning of a project and ask if all the dates were hit on time. Chances are, they weren’t. But chances are, it was still helpful to come up with those deadlines anyway. Again, planning is useful for those who participate.

Help your colleagues see that the conversation that led to the plan was more helpful than the plan itself. To do that, you can ask two questions:

• What were the factors that led to us meeting the deadlines we met?

• What were the factors that led to us missing the deadlines we missed?

Your team will likely arrive at a combination of these insights:

• We made the deadlines we made because we’re certain of how that work gets done. We’ve done it before. It’s our bread-and-butter.

• We missed the deadlines we missed because they didn’t reflect some unexpected complexities that came up. These unexpected complexities weren’t captured in our initial estimates — this was the first time we took on this type of challenge.

You can then ask, “What led us to come up with the deadlines that we missed? In what ways was it helpful? Harmful?”

Your team will likely arrive at some conclusion that planning is helpful because it helped…

• the team prioritize.

• set expectations with leaders and other stakeholders.

• other teams plan around them.

• serve a need around predictability.

But it wasn’t helpful to assume that the deadlines they missed would take that long, and that they should factor in unexpected work and uncertainty in their initial estimates.

Boom.

Third, facilitate your team to try a different way of planning

You can recap. “Great, it sounds like timelines are helpful for A, B, and C reasons. And, we're seeing challenges around X, Y, and Z.”

At this point, you can choose to either facilitate or teach.

• Facilitate a brainstorming session ("Of challenges X, Y, and Z, which should we solve for in our next project?").

• Or, you can hold off, and share ideas on how to create more realistic timelines. Three ideas I've shared with teams I've worked with:

  • Responsive Roadmaps — "Each step in a responsive roadmap includes an increasing amount of uncertainty. As you move from projects out to missions, exactly how and when you’ll achieve that goal become fuzzier." 

  • Subtly Detailed Roadmap Items — for work that we're doing now, we should have a ton of detail about how that work gets done. For work that's in the far future, we should have as little detail as possible about how that work gets done.

  • Strategic Roadmaps — as you acknowledge uncertainty, frame the decision points your team will need to make in the future.

If your team is already bought into alternative approaches to timelines, I'd go ahead and facilitate a session on how to improve the way your org does timelines.

If your team is newer to these ideas, I'd ask the team to read these articles first. Then, I’d schedule a session a week later. In that session, have the team reflect on what they learned and what they can apply from those articles.

Know when to make a decision even when you’re not 100% certain

Most timelines assume we have 100% certainty of all the actions a project entails. We rarely have 100% certainty, and we need our timelines to account for that.

This means that, as a PM, you have a skill to practice: knowing when to make a decision when everything isn’t certain.

When you’re 70% certain about a decision, you’re faced with three choices:

1. Wait until you’re 100% certain about that decision

2. Wait until you’re 85% certain about that decision

3. Make the decision now, with 70% certainty

Generally, 1) takes the longest. The cost of not making this decision outweighs the benefits of deciding with 85% or even 70% certainty.

For less consequential decisions, we should just make it.

For more consequential decisions, we should invest time in gathering information before making the call.

I think this takes practice. I’m still learning how to do this well.

Tim Casasola @timcasasola

I’m learning to know when to “not take action until we have more clarity” with “take action with partial clarity we have.” It’s hard.

Brandon Chu says this nicely in making good decisions as a product manager:

1. The less important a decision, the less information you should try to seek to make it.

2. Gathering information follows a Pareto principle, meaning you can get 80% of the information quite easily, but getting the final 20% requires a lot of effort.

3. Most decisions are not important.

[…]

“Your goal shouldn’t be to always make the right decision, it should be to invest the right amount of time in making a decision relative to its importance.”

Many PMs are overthinkers! Myself included.

But I’m getting better at deciding quickly. Sometimes, I pretend that parts of my life are a blitz chess match where I have seconds to act rather than hours. I’m feeling too lazy to bike to the climbing gym even though I planned to go? Fuck it, I’m still going to bike to the climbing gym. Other days I’m like, fuck it, rest day. The point is that I make this decision quickly and I don’t spend hours thinking about it.

visakan veerasamy @visakanv

(my answer if you’re curious is to practice moving/acting fast, ie treat sections of your life like a blitz chess match where you have seconds to act rather than hours between moves. Do the fastest, easiest moves that seem least likely to fuck things up. Optimize for velocity)

Impact what you can control, practice on yourself

Remember, you can’t change the way an organization does timelines overnight. But you can change the way your teams do it.

You can also practice making decisions quickly. As an exercise, journal to yourself:

• What decisions won’t sink the business/outcome if made incorrectly? (Make these quickly)

• What decisions will sink the business/outcome if made incorrectly? (Gather as much information as possible)

In what ways have you nudged your team past traditional ways of planning?

How have you oriented your team to plan in a way that acknowledges uncertainty yet still pushes you all to act quickly? Reply as an email or comment! I’ll share your replies on my Twitter if you’re cool with that.

---

My team is hiring a Product Design Lead

We’re looking for someone who can help us be better product designers. Know anyone? Send them this job description.

What I’m Reading

1. How to Steer Clear of Group Decision-Making Churn. Alastair shares ten questions that help teams make quicker decisions.

2. The Shit Facilitators Say Twitter is hilarious.

3. This tweet from Ken Kocienda: “I guess it’s tempting to lard on all sorts of processes on top of these simple ideas. My advice: don’t. Simple processes can work. The goal is to ship great products, not build the most complex processes.“

4. Reflecting on things I failed to get done at Google.

5. Market-Protocol Fit. You’ve heard of product-market fit: the product finds a market. The Other Internet talks about how there’s a different phenomenon for crypto-forward organizations: distribute tokens broadly, and then witness product innovation. This is what they call market-protocol fit.

See you in two weeks,
–tim