Technical Product Management

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.

The biggest challenge for any tech product manager (or program manager) will remain your ability to influence. You need to influence members at all levels of the organization on whom you have little authority.  The way to overcome this is ensuring your have a clear understanding of why your work/request is important. You would also need to ensure that the recipient finds these important and it is aligned with some goal of their own.

In a word, abstraction. A technical PM is usually NOT the most advanced technical person on a team. However, they are able to break through sufficient tech layers to be able to contextualize the tech in the overall product development. They are able to draw the bigger picture of how components fit together, what technology elements are critical. And how to think about investment in each technical area - sucvh as build/buy/partner. In this way, they're not competing with others on technical know-how, but using it as an essential area of overlap to allow easier communication and collaboration...

In my opinion, you can be successful in any role by not having the expertise if you recognize it and are willing to learn. The product manager is generally not the most technically advanced person on the team, but they bring in other expertise and experience to the team (e.g., customer data, market insights, etc). What has helped me is identifying key experts in the organization and leaning into them. I've usually not found a single technically "advanced" person on any of my teams. Different members of the team might have expertise in different areas. PMs with the expertise to identify the...

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

To me, the best part of being a Product Manager is that there is no typical day. There is a mix of working with your engineering partners, talking to customers, partnering with other organizations, and sharing info with executives or dealing with escalations. A day to day also differs greatly depending on the phase of your product.

To be clear, I don't believe a technical-PM is always a better PM. It comes down to what attributes, passion and curiosity you posess and the direction you want to go. A good technical PM is strongly curious about technology and how it's used to solve the problem. They think of the problem, as well as the soluton, in terms of technology. They are better able to understand abstractions of technology - tech stack, componentization, APIs - etc in the context of product development. Other non-technical PMs may similarly be more focused and passionate about product economics, pricing and positio...

If you mean technical product manager vs product manager, that depends on your technical expertise and interest towards technical products. If you mean program vs product, I don't have program manager experience. I'm only basing my response on my observations. I would say a PM cares more about ensuring the right product is being built while a program manager cares more about the execution and timelines. There are lot of other aspects (customer focus vs ability to stay organization and identify risks) but there are plenty of experts who have written about the differences between these roles...

I would not say I had a single point where I made this decision. I had the opportunity to lead a few PMs which I initially picked. I transitioned back to IC from this role a couple of times based on my interest in the product goals. My final (or I should say current since I could transition back to IC someday) decision was when I realized I was happier seeing success of my PMs than the success of the products. The slow transition helped me prepare both with the help of my mentors and advisors, and through "learn by doing". 

I don't think I've had a single surprise across my various tech product management roles.  In general, I would say my most surprising aspects when I moved to a product role has been the amount of work that goes into non-engineering aspects. For example, how much influence marketing or finance can bring into the success of a product. Partnering with these organizations taught me a lot since I came from an engineering background.

First, ensure you have the right data to backup any claims or decisions you want to make. Second, focus on the goals you want from that audience. Third is to make sure that the content is clear and crisp with the right level of detail. Occasionally, I have to re-write a document for a different audience (e.g., CEO). However, in general ensuring there is a clear summary for anyone without assumptions of previous context and the decisions (or requirements) are clearly articulated in your doc/email/presentation. Include details for anyone who might want to dig in the subsequent paragraphs or ...

If your question was about Tech Product Management, it is a solid understanding of the product vision and direction. A tech PM is able to be the voice of the customer in front of engineering or the voice of engineering in front of marketing.  They are able to represent the best interest for the product in front of any audience.

Two constant challenges for me in any product role has been finding the right way to say no. This could be to your customers asking for a particular feature or your organization that has decided to prioritize certain aspects differently.  The best way to overcome this challenge is by having your facts and data clear. For example, it is easy to convince leadership about your prioritization rationale if you have data to back up your claims, whether it is potential revenue or customer impact.

If you are already working in an organization with an opportunity for such a role, that is the easiest way to transition. If not, look at how your current strengths can be used in the new role.  In general, you want to show potential employers that you aren't new to all aspects of the job. For example, product (or engineering or program if those are the roles) skillset, domain knowledge and culture fit could be the top requirements for a role. If product skillset is the only one you lack, and you can show side projects/college projects were you demonstrated these skills that would help. Yo...