AMA: Meta (Facebook) Head of Technical Program Management, Vasanth Arunachalam on Technical Product Management

I'll answer this question in combination with "How is the role of technical product manager different than other product managers?" There is likely no formal definition of ‘technical product/program management’. Like I mentioned earlier, it is this fungibility aspect that makes this role a much sought after one in the industry right now. While a traditional product manager focuses on building products to solve consumer (or business) problems, a technical product manager takes it further to tackle highly complex technical problems in the pursuit of doing so. Typically a technical product manager thrives in product areas with high technical complexity: * Platform/Infrastructure areas * Any product or program that requires massive cross-org/cross-company effort * Deep technical areas such as Integrity, AI/ML

This response also applies to one of the other questions asked here - "What qualities stand out in some of the best TPMs you know?" I strongly believe that you can be a successful technical product manager regardless of your background, as long as you have the passion and growth mindset. It is not rocket science (for that matter, look at Elon Musk for rocket science). So I’ll focus on some of the desirable soft skills that makes one a successful technical product manager - * Able to technically grok how things work, very fast * Balanced (between Strategic and Technical thinking) & Objective * Data driven * Extreme ownership * Being thorough * Strong communication * High EQ & Empathy * Dealing with ambiguity and chaos * Growth mindset I’m intentionally not focusing on domain skills, because they can learnt. A good technical product manager should be able to take up any problem and build something to solve for it. Along the way they’ll likely gain the domain skills required to meet that goal (Eg: ML/AI, Integrity/Risk, Distributed systems, Autonomous vehicles, Game theory, Ad Auctions etc). I personally don’t fret over incrementally building my career around a set of ‘domain skills’. I’ve always looked at my career as a mosaic, I’ve done a variety of roles as a technical product person and gained a wide range of experiences. What matters is 3 things: 1) Do you find your work to be meaningful? 2) Are you learning something in that process? 3) Are you having fun?

I’ll try to answer this first question along with the question of - “What metrics do technical product teams look at to define success, what do you find to be the most important?“ because they are similar. KPIs or Metrics are essentially a way to measure how successful your program or product is. There are a few traits any ‘metric’ should possess - they should be explainable, able to move/influence by the team, able to test for impact, without any bias and more importantly tied to the business goal you are trying to accomplish. The metrics you’d want to define and track will likely vary based on factors such as - what type of program/product you are building (Eg: External consumer focused Vs Internal scale focused)?, what stage in the lifecycle it is in (Eg: Prototype Vs Growth Vs Mature), what matters to you within that lifecycle phase (Eg: During growth - User Acquisition Vs Revenue). Generally speaking you’d want to have a set of business (Eg: User growth, Revenue) and technical metrics (Eg: Availability, Latency) to provide a more balanced view. And don’t be afraid of (re)defining your success measures as your products/programs evolve. One of the common pitfalls I see is technical product/program managers having a myopic focus on legacy metrics that has far outlived its purpose.

Great to hear that more and more SWEs/SREs are considering transitioning into this career. I was a SWE myself before I transitioned to this role. Technical Product/Program Management (TPM) is a well established industry standard role now. I see more start ups hiring their first TPM even before they hire their first PM because of the technical bent and the fungibility the role comes with. A technical product person is able to operate more freely in the spectrum between Engineering and Product Management. I also think thats the biggest value add and allure of this role. Having said that we have a lot of ‘building the discipline’ work to do. It is still a fairly nascent discipline that is currently in hyper growth phase. We need to foster and nurture a strong community around it (Such as Product@) and we need strong advocates/mentors who can help others transition into this career. I foresee Technical Product/Program Managers leading product groups with multiple cross functional disciplines.

I love this question because it flips one of the previous questions to focus more on the individual. IMO the success of a Technical Product/Program Manager largely lies in the ‘What’ and the ‘How’. What impact did they have? This individual measure of success should be tied to the business (product or platform) goals. The TPM should directly be held accountable for delivering on those goals. This is also the (relatively) easy part to measure (Eg: How many new users signed up for the app?, How much incremental revenue did the feature bring?, Did the platform ship on time?“ How did they land that impact? This is the ‘hard to measure’ part. For a TPM it is equally important to demonstrate leadership qualities such as - high EQ, deep Empathy, Conflict resolution, crisp communication, ability to influence without authority etc and overall be a kind and respectful individual. Often peer feedback has proven to be an effective means to gather these signals.

I personally enjoy my role. I think no challenge is insurmountable. If I were to think hard, especially at Meta, the pace at which technology advances is simply astounding. Especially in Integrity (a.k.a Trust & Safety) domain that I lead, the complexity of adversarial problems and the AI/ML investments we make to solve for those, is staggering. As a people manager I need to be deliberate about keeping myself up to date and grounded in my area of ownership.

I talked about my take on desirable qualities in one of my previous responses, so I’ll focus on the common mistakes I’ve personally made in my career in the past, that hopefully will help others avoid those pitfalls. * Mistaking motion/effort for progress (This is also one of Meta’s posters on the wall in our campuses) * Rushing to prove my value (whenever I switched roles or teams). * Not being able to articulate the “So what” well. Eg: I’ve launched this shiny new feature, so what? * Assuming everyone has the context (and motivations) that I have * Assuming everyone understands how I communicate (and my jargons) * Not stepping up soon enough to grab a new opportunity a.k.a feeling scared * Asking for permission * Getting comfortable in a role; growth & learning plateaus

It could be a combination of any of these things - * Look at data (dashboards, customer feedback channels, internal partner team feedback) to check progress (on product success, platform performance) -Take any actions necessary (filing bugs, resolving a SEV) * Supporting your cross functional team to deliver on roadmap projects -Brainstorm product and technical solutions. -Sprints, design reviews, code reviews -Removing blockers * Look at data to proactively surface opportunities, hot spots, technical bottlenecks etc * 360 communications often tailored meticulously for the target audience * A lot of meetings (Product reviews, Roadmap planning, Decision making etc) * Ideating and planning for the future (Strategy) * Upkeep or morale and motivation for team. TPMs often act as the glue for the entire team. * And ideally they are having loads of fun doing all these