AMA: Chainguard Sr. Director of Product Management and Design, Julian Dunn on Building a Product Management Team

Rare is the engineering leader today who has never worked with product managers. The issue is that sometimes they misunderstand what modern product management looks like: it's not (primarily) about project management, it's not about prioritizing every single thing that engineering is working on, and it certainly isn't about being accountable for engineering's own delivery accuracy. These values and beliefs may be a surprise to some engineering leaders, and it's natural for them to push back if they have never encountered a product operating model (Marty Cagan's term). How I convince them is that I appeal to what they care about as engineering leaders. If they want their teams to be more happy and connected to the direction and goals of the business, and if they want engineers to be able to execute well without being told exactly what to do every day --- constrained autonomy -- product management can help. Then I can explain how the product operating model works, how it can help improve engineering happiness, and finally end on how it creates higher operating velocity and innovation in a company.

To me, this is less a question of literally number of PM bodies to engineering bodies; that depends on the company, its context, the complexity of its products, and many other factors. Instead, the way I think about this problem is mapping PMs to the number of logical domains within a company's product. A senior+ PM should be able to own a single domain, with its own KPIs, goals, and product strategy. Typically, this aligns a PM with an engineering manager over that domain, and underneath that EM can be multiple teams -- perhaps 2 or 3 pizza teams. Then, what my engineering director/VP counterpart and I watch for is how the domains are scaling, and when they need to be subdivided because they are getting too complicated for a single PM/EM pair to handle. I do not make arbitrary staffing changes in PM without discussing it with my engineering peer, because otherwise it creates chaos and confusion.

In these situations, I hope you've aligned with leadership on the reasons for them to hire a PM (sometimes their first PM) before you join the team, whether that's as an internal transfer or an external hire. If you aren't on the same page about the problems they are trying to solve by hiring you, and also how much autonomy/decision-making they are going to let you have once you get there, it's going to be a bad time: leadership is going to be frustrated when you start asking a lot of questions about both execution and strategy, and trying to make changes. This alignment before you get on board is going to be the biggest determinant of your success. Assuming your leadership team understands why they are hiring you, and they agree and are willing to (in theory) give you the latitude to introduce some better product management practices, the first thing to do is to observe how things are working for a little while and take private notes on current condition vs. target condition (your opinion). Then see where you can immediately lean in to make some basic changes that will help the team save time, money, toil, etc. For example, can you kill some meetings that aren't delivering value and replace them with something else (or maybe just get rid of them entirely)? Can you start meeting with customers or sales teams and bringing insights to the engineering team that they haven't heard before, and give more direction and meaning to what engineering is working on? Can you take a "yes, and" approach to ideas that engineering has, to explain to lead engineers that you believe in their technical ideas (if you do) but that success will arise from a whole bunch of other factors rather than just the coolness of their mousetrap? etc. Don't try to change too many things at a time. Focus on a couple of areas where you can get a win, and calibrate that to how resistant the team (including leadership) is to change. Good luck!

Just as the art of product management involves ruthlessness in making strategic choices or answering requests from customers, so it goes when there is too much surface area to cover with the PM headcount on hand. If you can't do everything, focus on the areas that are the most promising. Your rubric for deciding what needs to be covered can vary, but I use factors like: * how much is the product area evolving vs. just dealing with incremental requests from customers * what is its current revenue and potential for growth * where is the product in its lifecycle * how competitive is it versus other products * how much ambiguity is there in what needs to be delivered, or would engineering generally be fine if they made their own execution choices * what is the management team's thesis about whether the product area has potential for growth (or recovery, if it is behind) and so on. Then you've got to sell your leadership on doing a few things well rather than trying to do a multitude of things poorly, and ensure they are aligned with your analysis and rationale for dropping PM coverage of certain areas. I will also analyze where PMs are spending their time. Complex features in and of themselves do not necessarily mean that PM needs to spend a lot of time there, especially if the product isn't changing that much. When this becomes an issue is when sales doesn't know how to sell the product that's on the truck, and resorts to pressing the "PM easy button" to close their deals. I will work with sales leaders and sales enablement teams to get PMs out of taking these meetings, unless PM is also going to learn something.

There is not one, uniform KPI that I think product teams completely miss. What I see sometimes is the lack of a value thesis: product managers wave around metrics they want to collect, but they don't have a hypothesis about the target for that metric and on what timeline after feature delivery they expect to see that target achieved. Now, being mindful of Goodhart's Law, I usually tell PMs that I'm unlikely to hold them accountable to these targets if they have a good explanation for why they were off (assuming they didn't know those things a priori) but I want them to think through numerically what good looks like before they launch. I don't want or need exact numbers, but just a SWAG or order of magnitude is good enough. With this framework in place, what I've found is that (a) PMs are likely to pick targets that are reasonable to hit and usually not sandbagging; (b) the selection of a target is incredibly motivating for an engineering team and also gives engineers a sense of how good a feature needs to be at launch.