Product managers are always juggling lots of initiatives at once, so it’s crucial for product managers to know how to effectively manage projects and deadlines. In my own journey to product management, I didn’t have any formalized training in resource management and timeline management. So, to shore up that weakness, I obtained a Project Manager Professional (PMP) certification, which empowered me with an expanded tool kit of mental models and techniques to lead my initiatives more effectively. One key technique that I gained from studying for the PMP certification is the critical path method, which identifies the key bottleneck in any project.

It was through the critical path method where I fully internalized that not all velocity is created equal. In other words, only the velocity on the critical path matters. Below, I’ll share what a critical path is, how to use the critical path method, and why it’s so important for product managers to understand the critical path.

What Is the Critical Path?

Imagine you’re trying to kick off user research. As part of that user research, let’s say that you list out the following tasks, in no particular order:

• Find participants
• Schedule interviews with participants
• Interview participants
• Write up interview findings
• Pay participants
• Decide which mock user flows to show participants
• Create mocks and wireframes alongside designers
• Validate mocks and wireframes with engineers for feasibility

You want to know how long it’ll take for the user research to complete, since your executive stakeholders are expecting a readout in one of your upcoming monthly leadership reviews.

The time it takes to complete every action on the critical path is the shortest possible time it takes to fully complete a project. So, if your critical path requires 3 months, your project will take a minimum of 3 months to complete.

In other words, the critical path is the bottleneck – you can’t go any faster unless you address problems with the critical path. If you try to speed up anything else, or if you try to sequence non-critical path actions differently, it’s not going to enable you to deliver any faster.

As a product manager, you care about the critical path because it blocks your ability to ship, which blocks your ability to learn and to deliver results. 

How to Use the Critical Path Method

Some of the tasks that you need to knock out can be done independently of one another. Other tasks that you need to do might depend on each other.

For example, you might decide that your initiative looks like the following:

An arrow means that a task depends on another task. So, as an example, I can’t validate my mocks with my engineers unless I first create the mocks alongside the design team. And, I can’t create the mocks with my design team unless I first identify what flows I want us to run by users.

Great! We know the ordering of our work now. But that doesn’t tell us which path is the bottleneck. To do so, we now need to add in our estimates of how long each task might take.

So, here’s a new diagram with initial estimates from each team that I’m working with:

This is useful! Now I can figure out higher-level estimates by adding up the time it takes for each path to run.

If I draw a path from “schedule interviews” to “pay participants”, that’s 4 + 3 + 1 = 8 weeks.

If I draw a path from “validate mocks” to “write up results”, that’s 2 + 3 + 4 = 9 weeks.

We can now look for the longest series of tasks, because that’s what’s blocking us from going any faster. I’ve highlighted the critical path below in red.

The longest time it takes for my initiative to wrap up is 1 + 3 + 2 + 3 + 4 = 13 weeks. 

But, let’s say that you’re aiming to wrap this entire initiative in 10 weeks instead. Where could we accelerate this initiative?

The good thing is that because we know where the bottleneck is, we know what items don’t matter to us.

So, for example, I don’t need to ask the User Research team to schedule interviews faster, because that’s not on the critical path. Similarly, I don’t need to ask Finance to pay participants any faster, because that’s not on the critical path either.

Let’s say that I ask Design to speed up the creation of the mocks by 2 weeks, and I ask Engineering to speed up internal validation by 1 week. Let’s also say that I ask the User Research team to staff twice the resource onto conducting interviews, so that now it only takes 1.5 weeks. What does our diagram look like now?

Notice how I reset my diagram above, because the critical path might have changed! If we work our way through each of the paths again, you’ll find that there’s a new bottleneck. I’ve highlighted it in red below.

Now the bottleneck is sitting with the top half of the diagram. Our minimum time to wrap up this work is now 1 + 4 + 1.5 + 4 = 10.5 weeks.

Even though my previous critical path only takes 1 + 1 + 1 + 1.5 + 4 = 7.5 weeks, it’s no longer the critical path.

Remember that we need to find the longest total time in the entire diagram, and the longest total time is 10.5 weeks right now.

That’s close to the 10 weeks that I’m aiming at, but not quite enough. Should I ask Design to speed up creating mocks yet again?

No! While it was on the critical previously, it’s no longer on the critical path.

Rather, I should now ask User Research to schedule interviews more quickly, or I should ask an associate product manager to work with me to write up the results more quickly.

Keep in mind that in the vast majority of product management organizations, nearly every person is tackling multiple initiatives. So, if you take up unnecessary resources, you’re slowing down the rest of the organization.

Don’t be selfish! Remember that your job is to enable your customers and your business to succeed, and that means thinking in terms of global optimizations rather than acting in a selfish way.

Why Product Managers Need to Identify the Critical Path

In the example above, even a relatively trivial user research initiative might require multiple conversations with different stakeholders to negotiate for time and resources.

And, as product managers gain breadth and depth of scope, they’ll juggle more initiatives, and each initiative will be more complex, nuanced, and interdependent.

If you don’t understand the critical path, you’ll ask teams to make sacrifices that don’t matter. Remember, if you accelerate anything that isn’t on the critical path, you haven’t accelerated the total delivery time at all.

In contrast, if you do understand the critical path, you have an arsenal of options at your disposal:

• Resequence the initiative
• Delay the initiative to a less constrained time
• Add more resources to the critical path
• Cut activities from the critical path

Closing Thoughts

By drawing on the discipline of project management, product managers can accelerate the velocity and the quality of their work. On top of that, product managers who understand project management can go above and beyond in ensuring that their organization is allocating resources to the most effective uses of time.

By leveraging the critical path method, you’ll have more clarity on how to accelerate your initiative so that you can deliver impact in the world. The concept of critical paths may be foreign to you for now, but you’d be surprised at how quickly you can pick it up!

In my experience, I’ve never had to diagram an actual critical path for my work. But, understanding the mental model has enabled me to accelerate just about every initiative that I’ve touched, while saving my teammates from making unnecessary sacrifices.

That means that we all have better work life balance and better morale, and we can ship even more impact!

 

---

Have thoughts that you’d like to contribute around the critical path method or around managing deadlines? Chat with other product managers around the world in our PMHQ Community!