Beyond Agile (3/52): A How-To Guide on Technical Program Management for Product Managers (Part 1)
You have mastered Product Management. I am here to help you master Technical Program Management. Put that PMBOK back on the shelf - let me share the only fundamentals that matter one piece at a time.
This week’s newsletter has been on my mind for a very long time and I am finally starting to work on this. So, publishing it early because I am just too excited. So much to talk about but let’s start with the basics.
You are a master of the roadmap. 🥷
You give Hemingway a run for his money when it comes to writing PRDs. 🖊
You can detect trends in all sorts of datasets better than Sherlock Holmes can point out the obvious. 🕵️♀️
You are unstoppable… 💪 until your boss goes:
“This is a great roadmap, can you put a project plan around our immediate priorities.” 😐
Okay, it’s not that dramatic or crazy but most common reactions that many PMs may actually have is, “Omg, I have to write tickets” or “ewww project management, I am a PM, I don’t do that.”
Okay, fine, I am being facetious 😬😏.
Look - I get it; you came to work on strategy, not build project plans BUT, especially in a small company or startups, you may encounter moments where it is important you understand some fundamentals of Technical Program Management. As important as strategy is, without execution its all just wishful thinking, desires, items on a roadmap.
So - Welcome to my How-To Guide on Technical Program Management for Product Managers (Part 1), where I will focus on just the exact, enough, information you need to know to become familiar with this engineering discipline without needing to get a certificate or something.
Let’s Do It.
On Project Plans
What is a Project Plan?
If you Googled the term Project Plans or ever heard anyone or seen a project plan, you may think of this bar chart looking behemoth.
A Project plan doesn’t have to look like this. Surprisingly, it can be in any format you are comfortable with as long as it tells your stakeholders the following information:
What is the work the teams need to do. (Task)
Who will work on what. (Owner)
When will the work be delivered. (ETA)
Is there work that depends on other teams, work, or delieverables. (Dependency)
Are we on track to delivering it by the committed date. (Status)
You may also hear this word - Milestone. Do not be alarmed.
Milestone is a combination of individual yet linked tasks coming together to unlock a component of system, a new user feature, next phase of a project, or deliverable.
These Milestones are also how you will communicate with your stakeholders project progress instead of sharing the entire project plan every time. More on this later.
Milestones can be treated as a task but one that is very important. It must always line up or fall after the pre-requisite tasks are scheduled.
Just keep it simple and straightforward and answer the questions above and you will be a Project Plan Wizard faster than you can say “Ewww, tickets.” I jest 😏.
If you are happy with just a list of todo items, great.
If you are happy with an Airtable, great.
If you really feel comfortable, you can build a Gantt chart.
Who builds the Project Plan?
Project plan is the dual responsibility of the engineering team and Technical Program Managers with input from the PMs (you!).
It reflects the work that the engineering teams must do in order to ship the product or feature that is prioritized on the roadmap.
In many cases, the requirements or high-level feature overview including potential UX flows and design ideas put together by the PMs and Designers will help the engineering team understand what the end result needs to be. Then, as they develop the solution to achieve the end result, the TPM will work to translate the solution from boxes and lines (High-level technical diagrams or eng docs) into a list of tasks that will go into the Project Plan.
Who maintains the Project Plan?
The responsibility of making sure the Project plan is published in a central location (wiki or shared drive), accessible by all stakeholders for consumption and maintained/updated regularly as engineering team makes progress is the responsibility of the TPM. So, as you play the TPM role, you need to make sure you work with the engineering team to keep that plan updated as well as any changes from Product Management team.
What tools are best for building Project Plans?
It all depends. Microsoft Project, Omniplan etc are the most common Gantt chart dedicated tools. However, as I said, a plan format is whatever you feel like you can best answer the questions above. My favorite tools for building project plans:
Any note taking app with support for lists or tables (I know…not what you thought. 🤓)
On Status and Reporting
At some point, your stakeholders will ask you “How is the project going?”.
Status reporting is not about showing your homework or detailed technical details. It is giving the right level of information in a timely manner so leadership is never blindsided by things going wrong and can make timely decisions.
Who writes Status Reports?
Ultimately, the TPM is responsible for publishing the Status Report. However, it is very important that the report content is written collaboratively with the engineering team or reviewed by the engineering team leads who are being discussed in the report.
NEVER EVER write anything in status, particular blockers or risks, without first discussing and reviewing it with the team in question.
What are the contents of a Status Report?
I will always advocate for simplicity to start and since my goal is to teach you only the fundamentals that matter, all the templates or suggestions I will give will be based on simplicity backed by my own experience in this field.
Here is a template of what an effective basic status reporting looks like:
Project Overview - Key information about the overall project effort.
Project Champion/Exec Lead.
Status (Not Started, In Progress, At Risk, Blocked, Complete)
Exec Summary - Important information such as project blockers, exec decisions required, key achievements/milestones, and project risks.
Key Upcoming Milestones - Remember what a Milestone was (see On Project Plans section above). You can either pick only the next 5-7 milestones or list them all out, all depends on what your stakeholders care about.
Highlight the current status of the Milestone (Not Started, In Progress, At Risk, Blocked, Complete), if it is owned by a specific person or team, completion ETA.
Thats it. Always keep it simple and add more if based on your own experience and learning from the feedback your stakeholders give.
NOTE: If you don’t have major updates to give, don’t make stuff up just to fill the report. A simple “On Track” or “No updates” is sufficient. Your stakeholders will remember what you wrote and if it is off by any stretch, you will have to manage it.
How often should Status Reports be written?
The most common cadence I have see is weekly. I hate weekly. If your project is super complex the amount of things to report is massive. Progress isn’t always linear either; some weeks we make huge progress, other times not enough progress to highlight in Status.
Start with every 2 weeks and adjust according to the feedback from stakeholders.
What is the best way to publish Status Reports?
At Apple, during my time, it was a massive email that went to Craig Federighi and his directs. Eventually we built internal tools for reporting status.
Some companies may prefer Slack or wiki pages.
Doesn’t matter how the report is published, you do what works best for your stakeholders. What is more important is building an archive of all the status reports published for review at any given time.
On Stakeholder Management
I have written in the past on stakeholder management.
One of the prime directives of Technical Program Managers, especially modern TPMing, is stakeholder management. There are so many moving parts, people, personalities that part of Technical Program Management is to ensure the teams remain collaborative, constantly fed up to date information, giving their voices importance and as projects progress bring them along for the ride.
You can read more on stakeholder management below.
There is tons more that we need to talk about but, for now, take these important starting concepts in and look for more on this subject from me later.
Until next time. 👋
Was this essay useful? Your feedback is very important to me.