Vasanth Arunachalam

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

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.

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 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'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

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

I’m assuming the question is about setting a ‘team’ vision/mission and one doesn’t exist yet. The mission statement is the “What” and the vision statement is an ambitious future state of what the world might look like when you accomplish your mission. A crisp vision/mission statement serves as a strong identity for your team and guides them during critical moments of decision making, gaining alignment, prioritizing resources etc. Here is a framework that I’ve leveraged in the past to arrive at a vision/mission statement for my teams, collaborating with our cross-functional partners. Have each person in the working group articulate the following in once sentence. * Understand our role * Why do we exist? * What is our purpose? * What principles drive our product building? * Understand our customers * What does research tell us? * What problems do they have? * How are we helping them? * Understand how the future looks like * What’ll happen if we didn’t exist? * What does success look like? Next, create the vision and mission statements based on common themes and ensure it aligns with the company’s vision & mission. These statements should typically be short, start with a verb, strive to be aspirational and endure the test of time. Once the working group of cross functional partners align, socialize with key stakeholders and the broader org. You might want to consider doing a branding splash (new logo, ordering swags) to get people excited about the new vision & mission.

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 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 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.