This article is featured in the Skiplevel newsletter where I answer questions directly from the tech community about leveling up their technical skills and communicating with engineers.

Q: My team just missed a big release with a contractual deadline by almost 8 weeks. I wish this was a one-time thing but its happened twice now. Every time it happens I get the brunt of the heat from my CEO but I can’t control how fast the engineering team builds. I’m afraid this negatively affects my promotion. What do you think and how can I prevent this from happening again?— Asked by Sr. Product Manager @ Series D Healthcare startup

Yikes, this is a stressful position to be in, but hopefully you’d find some solace in knowing that you’re not alone. Many product managers find themselves in a similar position.

Estimating project timeline is notoriously difficult because the work in itself is about solving something. It involves lots of unknowns and risks.

If only there was a fool-proof way to predict the unpredictable. Alas, there isn’t and such goes life. C’est la vie.

The good news is there are ways to manage unpredictability to set your team up for the best possible outcome and this is a core product management skill you should be developing.

Managing unknowns in a project for better timeline estimates comes down to two things:

1. Making as much known about the unknowns as early as possible
2. Managing the expectations of stakeholders

Let’s get into it.

Making the unknowns known as early as possible

If the core of the problem stems from unknowns then it goes without saying that we want to shed as much light on the unknowns as possible. These unknowns will almost always be of a technical nature. Usually they stem from the following:

• Unknowns about third-party integrations
• Lack of developer expertise on existing codebase
• Trying out new technologies

You want to get in front of these unknowns by engaging engineering early on in the product development process while you’re working on figuring out the product requirements. By opening up a line of communication early, engineering can start conducting research tasks into possible unknowns and risks before the requirements are fully fleshed out and before the build process officially starts. This will remove a lot of uncertainty once the engineering team moves into the implementation phase.

Here are two project management strategies for making unknowns known as early as possible:

Spike: Timeboxed research tasks

A spike refers to a time-boxed research activity that helps teams make better decisions & deliver better products. Timeboxing is a time management technique used in Scrum and Agile project management, where specific tasks are allocated fixed and realistic deadlines. Timeboxing ensures efficient use of time to complete tasks within defined periods based on the complexity of the task.

Using the timebox strategy, engineer can create timeboxed tasks on their sprint board to investigate and research possible technical solutions.

For example, let’s imagine your product calls for integrating with a third party video editor. There are many options on the market. Before deciding on which video editor to use, research needs to be done to figure out which video editor fulfills all the requirements, is technically feasible, the effort required for implementation, possible risks, and general pros and cons of each option.

Prototyping

Prototyping is a highly effective way to get in front of risks and unknowns early on. With prototyping, engineers come up with a possible technical solution to a requirement → write out the unknowns and concerns about the solution → implement a skeleton version of the solution.

The idea behind prototyping is not to implement the entire technical solution—just enough to answer the outlined concerns. In the process of prototyping engineers also identify possible risks, giving them an opportunity to get in front of them early.

Prototyping should ultimately reveal whether the tested technical solution is a winner or we need to go with another solution.

Manage stakeholders expectations by setting realistic expectations

The very nature of building software is unpredictable. Having hard deadlines for building software is in itself a risk.

Ideally building software will take as long as it takes. But try telling senior management that!

Unfortunately, senior managers often lack experience in software development or are so far removed from the development process that they’re unable to fully appreciate the unpredictable nature of technical implementation. This only makes it far more important that you manage expectations early and often throughout the product process.

Always over-estimate based on the number of unknowns

There’s always going to be a level of guessing when estimating project size and timelines, but there is some method to the madness.

Typically, you want to start by breaking up the project into subtasks, estimate how long each one will take, and then add up the days.

To account for the unknowns and risks in the project, you want to take into consideration a few factors:

1. Have we done a similar implementation before? How long did that take?
2. How many unknowns are there?
3. How risky are these unknowns? What are the consequences in the worst case scenario and the most likely scenario?

Doing spikes and prototypes early should remove a lot of unknowns. With what’s left, estimate as well as you can. It’s unavoidable there will be some amount of very un-scientific gut feeling here, but when in doubt, err on the side of caution.

It goes without saying but all of this should be done with primary input from your engineering team. Ultimately they’re the ones building the features and understand best what’s involved in the process.

Instead of hard deadlines, provide date ranges of completions along with an outline of the risks

Instead of promising a hard deadline provide a date ranges of when the project will be completed and define the best case scenario, most likely scenario, and worst case scenario (add extra padding for comfort).

It’s important to also include alongside the projected completion dates possible risks and unknowns that might derail the project. This helps set accurate expectations amongst stakeholders. Being able to point back to the risks in the event deadlines aren’t met helps cushion any blowback on you as the product manager.

In Conclusion

The difference between OK project management and great project management is developing your ability to manage unknowns and set realistic expectations.

Your ability to manage unknowns when working with your engineering team comes down to how well you identify unknowns early, make as much known about unknowns as possible, and setting accurate stakeholder expectations.

This requires a certain degree of foresight, communication skills, and understanding of the software development process. As you gain more years of experience working in software these skills will come easier to you and help develop your gut feeling about project timelines.

If you want to level up your technical skills and your ability to communicate and collaborate with engineers, enroll in the Skiplevel program. The Skiplevel program is a comprehensive, on-demand course + community that helps you become more technical without learning how to code.

Sign up for Skiplevel’s newsletter to get more content like this straight to your inbox.

If you like what you read, make sure to ❤ it, share it, and leave any thoughts in the comments!

Follow and subscribe for more technical tips!

Want to feel more confident in your technical skills?

Become more technical in just 5 weeks, without learning to code! We also train teams! Find out more at skiplevel.co/teams and book a call with me to get started.

Skiplevel is a program that helps product managers and teams become more technical without learning how to code.

Learn more about the Skiplevel program ⟶

Connect with Irene on LinkedIn and Twitter and follow Skiplevel on LinkedIn, Twitter, and Instagram.