All related (5)
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftMay 2

I love this question. Typically one does not boot strap their career as a Technical PM, at least not until recently (Some companies including Meta are hiring Technical PM interns now who start their career as a TPMs which is great). So the most common TPM career progression stems from Engineering, Data Science, Product Operations, Partner Solutions Engineering etc. I’ve seen so many people from those backgrounds be immensely successful as a Technical PM. And there are people with many more backgrounds who could be equally successful too.

I never look at job titles. You might even be surprised to hear that I never look at an interviewee’s resume. I do a lot of Solutions design (which is all about hypothetical problem solving anyway), partnership and leadership focused interviews, so what’s on the resume hardly matters in terms of the signals I want to gather during the interview. I focus on behaviors such as Strategic influence, Collaboration, Conflict resolution, Motivation, Product Intuition, Program Management etc. and I want to see examples rooted in tech as much as possible. In technical deep dive interviews is where past work matters (therefore resume) and I want to see candidates demonstrating strong E2E technical understanding, and the ability to deep dive into a few areas of their past work.

Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly Microsoft
Building with intent is key. As a first PM or TPM, you are often running a one-person show. You wear multiple hats and you tend to be scrappy, flexing to what the business needs you to do. That approach works wonders up to a certain scale but soon exposes its flaws. When you think about scaling out from there, here are a few things to consider - * Understand your business (replace with org or product team) needs deeply, ideally the 1 to 2 year trajectory of where it is going. That’ll tell you what type of product person you need to hire next. Someone with augmenting skills (Growt...
Rupali Jain
Chief Product Officer, WorkBoard
I'm going to suggest a few processes, but please do scale each process to the size of the organization. Treat your processes like you treat your product - establish 2-3 internal customer problems that are actually worth solving, and solve them with an MVP of a process and iterate as you learn - don't try to introduce everything at once. * Quarterly priorities: Getting into the habit early of writing down the plan for the quarter is a good muscle to build early in establishing the PM discipline even with only a handful of PMs.  Focus on articulating the big bets for that quarter a...
Zeeshan Qamruddin
Director of Product Management, Fintech, Hubspot | Formerly Segment, WeWork, Airbnb
At the company level, there are a few different methods of communications to keep everyone abreast of updates: 1. Product Notification emails (Ad Hoc) - These emails have a set template and allow product teams from around the company to share updates to their areas in a digestable format as major features go out of the door.  2. Product Newsletter emails (Weekly) - The weekly newsletter summarized major product updates and initiatives to all product team members.  3. Quartery Business Review meetings (Quarterly) - These larger meetings gather key parts of the business to...
David Cutler
VP Product, CookUnity
I've noticed a trend in the tech industry for product organizations to follow a structure that Spotify helped craft over the years, in which a company is organized into business sub-orgs that roll up into their own respective product and engineering leads. And those leads oversee various squads that make up the product areas within that sub-org. At CookUnity we call the product areas "zones", in which a product lead exists to drive the product strategy and manage the PM team. In smaller companies (<500), those product leads are likely the direct leadership team for the Head of Product.  ...