AMA: Meta Director of Product Management, Maxime Prades on Building a Product Management Team

As a product leader, the single most important activity I prioritize is attempting to build an amazing team. A players attract A players and building incredibly diverse, smart and committed teams is the single most important job of a product leader. People come and people go, as a product leader you're always hiring. One of my former boss said to me once that once you team reaches a certain size (~10/12 people) you're always hiring. Something always happens, (internal/external mobility, reorgs, hiring spree, layoffs, performance management etc...) and you end up always hiring. So staying ahead of the curve, networking, always having your next hire in mind and keeping an active pipeline is key, but also ensuring your key players are properly incentivized, motivated, fulfilled and have room to grow and do what they do best is critical too. I know this isn't the original question but I can't help myself 😊 The second most important activity I prioritize as a product leader is keeping up with the product and keeping up my product knowledge. Staying close to the users, the sales teams, the detractors and understanding the ins and outs of your product will contribute to make you a strong product leader.

I have sometimes seen Product teams focus on impact instead of landed impact. And while there is a lot of nuance in that answer I think landed impact is often the most overlooked KPI or OKR or goal (however you like to call them). Teams will goal on number of users or shipping a feature rather than goal on the impact enabled by those metric. Take your typical B2B SaaS for instance. 200 active users of a feature on day 1 is an ok measure of success. But what really matters is what those 200 active users have achieved with your product. Or what those 200 active users have led to in terms of business impact. The visual below is a good illustration of what I mean: https://www.useronboard.com/imgs/posts/mario-water.png

This is a great question and one that happened to me as well a few years ago! Here is what I would consider doing (in no particular order) 1. Build trust, rapport and product knowledge: Become knowledgeable about the product, the sales cycle (if applicable: join sales reps on calls, meetings, trainings etc...), go do a few shifts of customer support tickets, join marketing and sales on a trade show etc... 2. Formalize the roadmap: Even if you're the first product hire there is probably already a roadmap. But it's probably not formalized, not formatted, not clear, not structured. that's the first most obvious measurable landed impact you can have. Gather it, structure it, tell a story around it, show past half or quarter or month impact and then look forward and build something the whole company will rally behind 3. Find "diamonds in the rough": There are often Product Managers "hidden" in the company. As you look to grow the team, go look in functions like Solutions Engineers or Engineering or Program managers for folks with a knack for solving problems and grow the product team organically 4. Figure out the biggest problems to solve: A high powered highly functioning engineering team might not immediately appear to "need" a product manager, but find the biggest problems they need solving and get to solving them

I don't 😬 Obviously it depends on the size and scale and the situation so take this answer with a grain of salt, but I am a firm believer that you shouldn't ship the org chart when it comes to product goals and KPIs and landed impact. You're one team, one unit. You build and ship together, marketing included. Of course you have different techniques and tactics and skillset but you should all goal towards the same KPIs and the same landed impact. Ultimately you should optimize for the same things and the breakdown of who does what should be pretty clear once you have agreed on the end goal. If it isn't I quite enjoy employing a very traditional framework called a "RACI framework" that helps clear roles and responsibilities in a very blunt way.

I don't believe there is one org structure that looks better than an other. so my answer here about my current team PM org structure is irrelevant but I can tell you a few things about it 1. My current org structure will change with various business priorities. And it could/will change a lot. And that's ok 2. Your last "reorg" isn't your last one. It's your most recent one. 3. Optimize your teams by problems they are solving, not by solutions they are providing So many more advice I would be happy to give that heavily depends on the level of maturity and size of the organization so i'll refrain from giving more until I hear more...!