How to estimate project timelines as a non-technical PM

Estimating well comes down to managing risk

In reality, once an engineer knows what work is needed, coding itself doesn’t take very long, especially now with AI.

Where it gets tricky are the unknowns, and the bigger the project, the more unknowns there are.

So when your engineer says "2 months," they're not really telling you how long the work takes. They're telling you how long the work takes plus how much uncertainty they think is involved.

They do that because we don't treat estimates as estimates. We treat them as commitments. Every number an engineer says out loud gets written down, repeated in a leadership sync, and held against them later. So they build in protection by padding the estimate.

Your engineer can see the unknowns but you can see the roadmap, the customer promise, and what it costs to be late. Neither of you has the full picture on your own which is exactly why the estimate should come out of a conversation instead of a single date handed down by the other.

Where the unknowns tend to hide

In software development, most risks that affect time estimates cluster in the following places:

• Third-party dependencies: e.g. vendor APIs, payment processors, auth providers. You're at the mercy of someone else's system.

• Internal dependencies: anything that needs another team to deliver first. Their priorities aren't your priorities, and their timeline is its own estimate with its own unknowns stacked inside it.

• Data changes or migrations: anything touching records that already exist is very high risk and requires careful planning or simply not feasible.

• Legacy or unfamiliar code: systems nobody currently on the team wrote. Every change means first figuring out what the existing code actually does, and whether anything else depends on it.

• First-time work: e.g. a new framework, a new integration, a new tool the team hasn't used before. There's no past experience to estimate against, so the estimate is more or less educated guesswork.

The other thing to keep in mind is that there are three different types of unknowns, and they're not equally solvable:

• Known unknowns: these are answerable in advance through discovery. e.g. Does the old customer data have the email field we need? Will the payments team's endpoint be ready by June?

• Unknown unknowns: things engineers didn't even know to ask. e.g. the vendor rate-limits at 100 requests a minute, legal needs to review this. You can't list these upfront, but an experienced engineer often can name a few, because they've seen work like this go sideways before.

• Unknowable until you build: nobody can know until the build is in progress, no matter how much planning happens first. e.g. the library upgrade breaks four other things in the codebase.

Stop asking “When will this be done?”

Start asking:

• “If everything goes the way we hope, what’s the fast case?”

• “If the things you’re worried about actually happen, what’s the slow case?”

• “Which is more likely, and why?”

Now instead of just "2 months," you get something like:

"Best case 6 weeks, worst case 12, realistically about 8."

This is now a conversation starter because you can ask the follow-up question:

"What's the difference between 6 weeks and 12 weeks?"

Mostly likely, some of what they’ll come back with is specific, concrete, and most importantly, actionable. For example:

• "Whether the payments team can give us that endpoint or we have to build our own"

• "Whether the database have the fields we need or we have to backfill"

• "Whether the current search index can handle the expected traffic or we need to stand up a new one"

This is where technical foundation stops being a nice-to-have.

If you're not sure what an endpoint is, why backfilling data is a big deal, or what problem a search index solves, you won’t be able to tell which is worth pushing on and which is your engineer being appropriately careful.

The good news is that the questions below work whether or not you feel confident in your technical skills (though they work better once you do).

4 ways to shrink the estimate without pushing

For every unknown, explore ways to mitigate it or make it go away entirely.

Of course, some items are genuinely outside anyone's control – the vendor's API is what it is, the compliance review will take as long as it takes, and some problems won't show themselves until the code is running against real data. Pushing on those will only burn credibility with the engineer building it.

Still, as a PM you’re not entirely powerless. Here are 4 practical things you can do to lower the time estimate:

1/ Help engineers think reflect on what might be some unknown unknowns

• What’s gone wrong on work like this before?

• If this doesn’t go as planned, what’s your best guess as to why? Why is that your best guess?

Ask an engineer to predict their own failure helps them turn unknown unknowns into known ones, which are the kind you can actually do something about.

2/ Do discovery to answer known unknowns

• Could we spend two days finding out before we commit to a date?

You’re asking for a spike aka a small, timeboxed investigation before committing to a technical solution. For example, test the vendor's API, or exploring the legacy code.

3/ Find out what the expensive part is, then negotiate it

• Which part of this is the biggest chunk of the estimate?

• If we cut X, does the time estimate change? By how much?

• Is there a version of this we could ship first and add the rest later?

Sometimes 70% of an estimate comes from one requirement. Engineers are creative problem solvers, so asking them how they might design the business requirement in a way that is less complex from a technical perspective while still addressing the business problem can save a whole lot of time and effort.

4/ Unblock the things that you can unblock

• What are you waiting on from someone else? Can I go and get it for you?

• What’s one thing I can do that will help speed this along for you?

This is where you earn real credibility. Getting a commitment out of the payments team, chasing legal for a review, deciding the requirement that’s a loose end are all things you can do as a PM. Every one of them is time sitting in the estimate that you can personally remove, without waiting on engineers.

TL;DR: Are your engineers inflating their time estimates?

The answer is yes, but the padding is less about dishonesty and more about a hedging for the unknown.

As a software engineer, I can say first hand how often I've started a technical task with one assumption, only to find out how much more complex it was after I started working on it, and countless other examples of times when things simply didn’t go as planned.

Getting into the habit of laying out the best, average, and worst case up front, instead of a single immovable date will get you more credibility with engineers, protects you from over-promising and under-delivering to stakeholders, and ultimately, more accurate roadmaps.