There Is Too Much To Estimate
2025.27 - It’s Planning Season 2026! I have some thoughts, some wise cracks, bit of sarcasm, but very useful advice on how to survive this annual ritual as a TPM.
You are reading a free post from my newsletter — The Art of Doing Technical Program Management. I write with an aim to demystify the art of technical program management and deliver proven real-world strategies, practical advise and tips, and actionable frameworks to help you level up as a Technical Program Manager.
If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.
We know the patterns…
Every planning cycle I’ve ever been part of begins with a familiar ritual. Someone pulls up a list, those pesky 50 features long roadmap, and declares, “We just need estimates so we can decide what fits.” And thus, two schools of thought emerge:
School A: Estimate everything. Size all 50 features so leadership can make informed trade-offs.
School B: Focus deeply. Narrow it down to 10 features, then estimate them in detail to understand what scope needs to be trimmed.
Both schools believe they are doing the sensible and rational thing. One seeks breadth; the other, depth, both want something realistic to build and ship. And somewhere in all of this, the TPM is meant to guide engineering through the fog of estimation without burning everyone out or getting lost.
The Harsh Realities of Estimation
No matter which school you belong to, a few things are always true:
Planning cycles are too short. You never get a full quarter to estimate.
Leadership expects high-confidence numbers right away.
Requirements can be half-baked, and designs are still in “concept” mode.
Which means your estimates are, at best, leading indicators, not promises. Margins of error will be high. Engineers will pad where they must. And as solutions evolve, timelines will stretch and contract like a rubber band.
Estimation isn’t a science or precision arithmetic, it is forecasting and prediction.
When You’re in School A
When you’re asked to estimate everything, 50 features, 12 epics, and 300 Jira tickets before next Friday, the only realistic approach is not building precision rather it’s expectation management.
Set the tone early: Make it clear that confidence levels vary with the estimates.
High Confidence: These won’t change.
Medium Confidence: Within ±1–2 sprints.
Low Confidence: We’ll revisit once missing requirements arrive.
Break it down: Don’t provide a single “magic number” for a feature. Instead, show what’s known, what’s unclear, and where the gaps lie. A long list of XL estimates is not useful to anyone.
Negotiate at the right altitude: Don’t slice 10% off fifty features, it’s chaos and delusional. Cut 80% of the roadmap first, then refine the remaining 20%.
Watch for disguised work: Bug fixes pretending to be features will wreck your capacity planning. Save a chunk of your capacity for KTLO and Bug Fixing.
Anchor with a North Star: Ask Product which metrics truly matter. When the list is long, clarity about impact becomes your best friend. Go further and ask them to stack rank everything if they don’t want to cut the list.
When You’re in School B
In School B, you’ve got fewer features but deeper expectations. The pressure shifts from speed to accuracy.
Set confidence levels anyway: Smaller list ≠ perfect data. Confidence levels will be required. See point in School A.
Define the MVP early: Don’t over-engineer the wrong features. You still need to focus the finite time you have to plan.
Maintain rhythm: Extra time can lead teams into endless rabbit holes of “what if.” Keep the cadence steady.
Stay humble about capacity: Even a tight, focused list can exceed bandwidth once reality sets in.
Final Words
No matter which school you’re in, estimation always comes down to this: How well did you set expectations?
Because at the end of the cycle, the goal isn’t to have perfect numbers, it’s to ensure no one is shocked when the numbers change.
Communicate early. Share progress often. Remind everyone that estimates evolve as clarity improves. Surprises at the end mean panic meetings, which lead to rushed compromises and those rarely end well.
Estimation isn’t about control. It’s about alignment. And as TPMs, that’s our real art form; bringing order, honesty, and calm to a process built entirely on uncertainty.
Happy Planning!
-Aadil
P.S. I have launched my first new on-demand TPM Course right here on this newsletter — Foundations Of Technical Program Management.
📣 Subscribe to my new “On Demand Course” annual subscription and unlock my highly rated Maven course content + FREE access to all future courses.
🔥 50+ TPMs have taken the course live. Some used it to level up their TPM game while others used the content to MOVE INTO a TPM role.
In the modern AI world, the foundations of TPM role will be the key difference between churning AI slop or becoming an impactful AI native TPM.
💪🏽 Unlock your full TPM potential today!
I also find that pairing roadmap estimation with a strategic narrative for that product space helps focus the discussion. Product development teams love context and aligning everybody on that first greases the wheels for the estimation process. Happy planning everybody!