Skip to content

Getting started as a new graduate or someone early in their career

This page is part of the Career Path section.

The good news is that your education and early work experience can be beneficial to getting started in a career as a TPM. Did you have any group projects in school, university, or college? Those projects (call them programs?) taught you teamwork, leadership, breaking down features into component parts, and the definition of success. What role did you play in the group? Were you the one going off and coding something by yourself? That's not a great TPM trait. Were you leading meetings, taking notes, setting the agenda, breaking down tasks, putting people to work with their strengths, and keeping track of progress? You might not be surprised that all of those things are what TPMs do in the professional world.

What sort of courses did you take in school (assume I include university and college in the definition of school from now on)? A mix of technical, business, leadership, soft skills? How might you apply what you learned and experienced in those courses holistically? How might you interrelate those subjects? Again, that's part of what a TPM does.

In terms of preparing for an interview for a TPM role, especially as a new graduate or someone early in their career, you have three steps to prepare.

flowchart TD A[ What did I learn? ] --> B B[ How can I apply what I know? ] --> C C[ How can I show what I know? ] --> D D[ Interview preparation ]
  1. What did your learn in your courses, projects, and work experience so far that is related to the TPM role's capabilities?
  2. How will you apply what you learned by integrating it into a holistic program or programs? In other words, how have you reflected on what you learned to apply it in the future?
  3. How will you convey what you learned, what you know, and how you will apply it to a TPM job role? How will you tell a potential interviewer that you have the skills, experience, and aptitude for a TPM job?

Job post deconstruction - Intern TPM

Let's deconstruct a job posting for an Intern Technical Program Manager position that was posted by Microsoft in March 2024.

Here's the job description (edited for clarity / conciseness.)

Job title: Technical Program Management Intern

Date posted: Mar 13, 2024 Role type: Individual Contributor Profession: Program Management Discipline: Technical Program Management

Overview section

At Microsoft, Interns work on real-world projects in collaboration with teams across the world, while having fun along the way. You’ll be empowered to build community, explore your passions and achieve your goals. This is your chance to bring your solutions and ideas to life while working on cutting-edge technology. The internship is designed not only for you to do great work with the opportunity to learn and grow, but to experience our culture full of diverse community connection, executive engagement, and memorable events.

We're in search of an outstanding PM intern with passion for security, customers and product management coupled with a technical aptitude, we invite you to unite with us in our mission. By doing so, you will play a pivotal role in contributing to securing Microsoft’s operating systems.

Required Qualifications section

  • Product management background or background in a related field (military or industry)
  • Experience working with R&D teams

Preferred Qualifications section

  • Experience in Cyber Security
  • Experience in operating systems

Responsibilities list

  • Help develop and drive the security vision, roadmap, and priorities of security features being developed in the EnS group.
  • Defining objectives, key results, and corresponding work items for security features being developed in EnS.
  • Work closely with R&D and Data Intelligence teams, PM counterparts, and internal customers.
  • Collect and define data from Engineering Systems and other sources to present metrics on EnS security features.
  • Collaborate and coordinate across teams to ensure alignment on product/service development, management, and release, including tradeoffs, adjustments, and improvements.
  • Being a key part of the planning cycles, triaging and manage EnS [work plan].

First, what does "EnS" mean in this job description? It's obviously an internal term but I couldn't find a definition for it anywhere on the web. From context, let's assume it's something to do with enterprise ("E") security ("S"). The "n" might be short for "and."

Next, notice that the required qualifications list "product management background" and "experience working with R&D teams." How might someone in college or university have this experience? Seems like a high bar for an internship, right?

If your courses and workshops have involved making decisions about what to build and what not to build you have some experience with product management. While you might not have shipped (released to the public) a product, the choices you made (even if made as a team of students) forms the foundation of product management experience. Product management, and by extension, program management is about making choices of what to work on and what not to work on. Making choices of where to focus your and your team's efforts.

What about the "R&D teams" requirement? I'll give my opinion here that any college or university student in the second half of their undergraduate studies, or in the Masters or PhD studies, has done some research, possibly in a team situation. That's the lens I would apply if I were applying for this job.

Let's move on to the preferred qualifications. The hiring manager listed experience in cyber security. This is pretty broad. If you are in college or university you may have even taken a course in cyber security already. Ideally that project had at least one project, and ideally it was a group project. That gives you something to add to your resume and to discuss in the potential interview.

They also list experience with operating systems. Again, this is pretty broad. Many computer science or engineering programs at university have an operating systems course. The hiring manager isn't likely just looking for experience using operating systems. Since this is a TPM job listing they are likely looking for some experience with operating system internals. Maybe you even had a project to write a small OS in your course. If not, there are courses available online and even YouTube videos to get you up to speed. Just be sure that you don't overstate your experience and skills for any qualifications listed.

Now we'll move on to the Responsibilities section.

"Help develop and drive the security vision, roadmap, and priorities of security features being developed in the EnS group."

We've seen items like this before in this Book of TPM. There sections on program charters, leading and managing, managing scope, and communicating with stakeholders that cover some of this responsibility. Remember to draw from group projects, volunteer work, or even relevant personal projects to fill out your resume and prepare for the interviews.

"Defining objectives, key results, and corresponding work items for security features being developed in EnS."

First up we see the words objectives and key results. This is a hint that the team might use OKRs to plan, organize, and track their work. OKR stands for "Objective and Key Result" and it is a goal-setting methodology popularized by John Doerr at Google then adopted by many other companies and organizations. There is a public tutorial called "OKRs 101" at the site What Matters. For even more details you can read John Doerr's book Measure What Matters.

As for "defining work items" we cover that here at the Book of TPM in the project scope and tracking scope sections.

"Work closely with R&D and Data Intelligence teams, PM counterparts, and internal customers."

This responsibility covers some of the core expectations of the TPM role: teamwork, stakeholders (like internal customers), and communication. One last thing to note is the reference to "PM counterparts." This likely means you'll be working with one or both of other Program Managers or Product Managers. For a refresher on the difference between these and the TPM role see the "key differences" page on this site.

"Collect and define data from Engineering Systems and other sources to present metrics on EnS security features."

The way I read this responsibility is two-fold: One involves your analytical skills and the other might leverage your technical skills. Collecting the data may not be completely straightforward and could rely on some internal (non-shipping) programming. Analyzing will certainly require some technical skills and then you'll have to practice your analytics to draw meaning from the metrics.

The second thing I read in this line is the use of the term "Engineering Systems." This is another internal Microsoft term often shortened to "ES." ES is typically involved in setting up internal systems, like code repos and CI/CD frameworks, to aid in the productivity of Microsoft software engineers. Making an intuitive leap between "ES" and the cyber security requirement this role might include measuring and improving security for internal code development and deployment systems. This is just my interpretation based on experience -- you can't necessary read that from the job description alone.

"Collaborate and coordinate across teams to ensure alignment on product/service development, management, and release, including tradeoffs, adjustments, and improvements."

This is another line that highlights some of the core responsibilities of any TPM role. We've talked about teamwork, communication, and stakeholder management already. What this responsibility adds is a node to quality ("improvements") and risk management ("tradeoffs.)

"Being a key part of the planning cycles, triaging and manage EnS [work plan]"

This last responsibility listed covers planning, change management (triage -- making priority choices), and scheduling. A quick note on "triaging" as referenced here. This comes down to, at the interview stage, explaining how you have prioritized features or other work items to make decisions on what to work on next, and perhaps more importantly, what not to work on. In this context "triaging" also could imply helping to make priority calls on work items for other team members like software engineers. It's often part of a TPM's remit to make or change priorities to provide clarity to other team members who will work on those items directly.

And that's the end of the job description. Let me know if this was helpful or if you'd like another job description deconstruction by using the anonymous feedback form.