You are reading a paid 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.
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!
A TPM’s primary role during planning cycles is to help your engineering teams navigate priorities, politics, dependencies, and unrealistic expectations with clarity and calm.
Annual roadmap planning is where TPMs earn their stripes. It’s messy, emotional, political, and often wildly unrealistic but it’s also the moment when teams look to you for clarity, structure, and grounding in what’s actually possible.
Below is a practical field guide built around 20 real questions TPMs either ask or encounter during planning season with answers on how to navigate these questions with confidence, influence, and a steady hand.
As TPMs, our core responsibility is to advocate for what’s best for the business and ultimately for the customer. The most effective way to influence decisions is to connect every proposal, every ambition, every idea, back to the company’s strategic objectives. Use OKRs, mission statements, and clear metrics to anchor your point of view.
Ask thoughtful questions that guide the cross-functional team toward the conclusion you know is aligned with the business. Influence is often a function of the questions you ask.
A Word On Influence: Your influence grows with trust and tenure. Your credibility compounds with every successfully delivered program. If you’re new, your influence may be limited at first and that’s completely normal. Consistent execution builds the platform your future influence stands on.
The cleanest argument is capacity.
Use simple math: X engineers × Y working weeks = total available capacity.
As you map scoped work against that number, the reality becomes obvious. You’re not blocking, you’re revealing constraints and realities in which all decisions must be grounded in.
Your goal isn’t to prove anyone wrong; it’s to spark an honest conversation. Few things cut through noise like simple, visible data.
Ask clear, innocent questions: “Which OKR does this initiative map to?”
If the answer is vague, follow up: “Should it map to an OKR? If not, what’s the rationale?”
TPMs are at their strongest when they ask obvious but necessary questions that expose misalignment without creating conflict.
Your job is to surface bottlenecks early and make them impossible to ignore.
Start by aligning product owners on which initiative drives the most meaningful business impact or OKR progress.
If that fails, escalate to product and engineering leadership. The real choices are usually:
Prioritize one over the other, or
Shift resources by deprioritizing something else.
⚠️ Warning: Avoid the “just hire someone” solution; hiring plus onboarding can take months. Hope is not a roadmap. Remind leadership that credible plans require real constraints. Focus only on the butts in seats you have today, not what you hope to have tomorrow.
Bring it back to capacity and committed P0 work.
It’s fine to size stretch goals, but label them clearly as stretch, aspirational, not promised.
If leadership insists the stretch goal is mandatory, then it isn’t a stretch goal. Reclassify it as a must-have and revisit trade-offs.
Protecting engineering teams from overcommitment isn’t resistance, it’s leadership.
You have two realistic options:
Find a workaround. Can your engineering team temporarily bypass the dependency, even if it means tech debt or a short-term patch?
Negotiate timing. Adjust scope or sequencing so the work aligns with when the dependency team can support it.
Document decisions, communicate broadly, and make the downstream impact explicit. Clarity prevents re-litigation later.
Use a simple shared doc, a work breakdown or scoping document works best.
For each requirement, list:
Teams involved
High-level scope (epic-level detail)
Estimated effort (in weeks)
Google Docs enables async discussion with comments, which is more efficient and human than complex tracking tools.
If cycles don’t align, secure a soft commit first; a yes/no on whether they can support the work. Anchor in company OKRs when possible.
Next, lock down a date when they can provide final estimates. Mark that clearly in your tracker.
Progress beats perfection. “Soft committed with final sizing on <date>” is more useful than “Team X can’t commit.”
Level 1: Working group (TPMs, PMs, TLs etc).
Level 2: Functional leadership (directors).
Level 3: Executive leadership (VP+), reserved for cross-org priorities or roadmap-critical risks.
Most issues resolve by Level 2. Escalate higher only when the impact is broad and strategic.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.