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

For the first part of the question -

  • I stared my career as an Individual contributor IC) and as you know that is all about specific product/platform strategy and top notch execution. I talked about the day to day of an IC in my previous AMA.
  • When I transitioned to a manager role with a small sized team, it was all about scaling myself through my team. I was still accountable for a specific product area (M&A, Backend services for an OTT platform, Business Integrity Enforcement etc) but it included a bunch of products/services that required me to expand my expertise into. I still acted as a subject matter expert, providing guidance to my team on a day to day basis. Ensuring tighter alignment of my team’s goals was relatively easy and I had greater visibility into the progress my team made. Every day we’d be laser focused on solving our customer problems, there was lot of room to gets hands on.
  • When I grew into an org leader with a team size of 35 to 40 people, my role gradually changed. I became the functional lead representing Technical PMs in my org’s leadership circle. My role spans 5 to 6 major product areas with ~1000 people cross functional teams. I need to be able to get a perspective on all aspects of the business (some areas where my team might not be staffed) and often rely on my own team leads to provide all the context. I spend most of my day today on the following (among many other things) -
    • Setting and articulating the org level goals & priorities. Ensuring our teams understood how their work fit into the bigger puzzle
    • Ensuring those goals (and any dependencies) are well understood by other cross functional teams (Eng, Design, Data Science etc) so that we can build strong relationships and collaborate well to achieve desired business outcomes
    • Regular product/platform reviews with the teams to keep myself and the rest of the leadership informed on progress and ensuring alignment with org level goals
    • Solving for any blockers on behalf of my team and the org
    • Supporting my team well to ensure people’s skills are matched with the right opportunities (and priorities)
    • Hiring and ensuring the new people on the team are set up for success

For the second part of the question, I’ll respond from an org/team lead perspective and focus on one trait that makes such programs successful. Since I work in Integrity (a.k.a Trust & Safety) there is a constant need to reprioritize my team’s resources to tackle new challenges and emerging risks that come our way. I ensure such trade offs are well understood by everyone. And often those challenges require us to set up large scale programs with significant east-west collaboration. When dealing with new or unknown problems, I’ve seen that strong Technical PMs typically get up to speed in a new or unknown area pretty quickly. While managing a program in such a problem area, my teams spends a lot of time communicating, with extreme clarity (context, problem, goals, solution, timeline, risks etc). That is the single most important aspect of managing such technical programs IMO.

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