AMA: Chainguard Senior Director of Product Management, Julian Dunn on Product Management Career Path

To pivot into product management from partnerships/bizdev, you first want to think about performing a role in partnerships that requires you to work closely with product management, and then determine what the title is. There are three main focus areas for partnerships that I commonly see: SI (system integrators/implementation partners); channel (resellers/marketplaces); and technology partners. As you can probably imagine, the latter is where you will have the most touch points with product, so landing a job in partnerships doing something along those lines is the best. (By the way, my background is B2B; B2C partnerships are a totally different ballgame.) Titles that I've seen are along the lines of technology alliances manager, technology partnerships manager, etc. The more technical you are in the role, the more valuable you are -- though I would stay away from purely partner integration roles where you are essentially a sales engineer. Once you land that role, figure out how you can add value to product management. If the product requires a robust ecosystem of very similar integrations, for example, help out a product manager by bringing your knowledge & experience to help them prioritize which partners to tackle first. PMs not only need to know the difficulty of the integration (that's often straightforward to figure out) but also the friendliness of that partner -- how easy they are to work with, what competitive/co-opetitive dynamics look like, etc., which you are uniquely positioned to provide. And always keep your eye out for partnerships that could turn into a more formal alliance, or even M&A. Good luck!

After the many rounds of layoffs in both big and small tech over the last few years, PMs are being asked to become more well-rounded business leaders -- not just be the interface to engineering. This isn't a question of "doing more with less" (I really hate that expression) but about doing the work that uniquely creates the most leverage for the organization. It's not sufficient to know how to write PRDs or user stories anymore; you have to understand how to run your product or domain as a business. In practice, this means there are three areas that most PMs need to uplevel their skills in: * Positioning and messaging. You can't just expect your marketing/PMM counterpart to do this for you; your ability to do this for your current product, or when proposing new features, is going to be critical for your success. Figuring out how to describe a problem and solution space as concisely as possible, with strong written arguments, is a make-or-break for what gets funded in a resource-limited environment. * Quantitative business case development. Gone are the days when PM could simply tell a story, hand-wave over ROI, and get their initiatives funded. While it's true that in the world of PM -- and specifically, in new product development -- much of the data is unavailable or untrustworthy, you still have to take a swing at ROI. For big digs, I ask all of my PMs to create a back-of-the-napkin NPV (net present value) analysis based on what they know. Is the model going to be accurate? No way. But the point is to get them to start thinking about the drivers of both revenue and costs, how long it will take for an initiative to make its investment back, how the cost profile of the initiative will impact pricing & packaging, etc. * Written and oral communication. I alluded to this previously, but the ability to concisely, clearly and confidently express yourself in both written deliverables and presentations -- especially to senior/executive management -- is the number one determinant not only of your management team's confidence in you, but a predictor of your likelihood to get a promotion. Gone are the days when your director or GPM will cover for you; they don't have time to rewrite your memos or presentations to make them comprehensible for senior management. If you know you are weak in this area, or if your manager has told you this, there are many resources available out there. The most important one is simply to practice a lot until you get better. Hope that you enjoy your career break and that you use some of the time to invest in yourself before coming back to PM!

I'll be blunt: because of the huge number of PMs on the market right now, you need to either have or find a connection into the company where you want to work. Simply optimizing your resume or cover letter isn't going to cut it; nothing beats a personal referral, or a warm intro, even if it is a few steps removed. Figure out how to use your LinkedIn 2nd or 3rd degree connections to get you to someone who's even proximate to the hiring manager for the position, and you will be miles ahead.

Congratulations -- you are already a PM, so you're starting from a position of strength. Regardless of whether you are an internal PM, platform PM, B2B PM, B2C PM, etc. there are always common PM skills across these areas, so think about what is transferable and what is not, and emphasize those. For example, if I am hiring for a customer-facing PM role and I have an internal PM candidate in front of me who is trying to make the case that they are the best candidate for that, I have to be convinced that they can do customer discovery with paying customers who aren't going to be as nice/straightforward/cogent/etc. as their previous customers (i.e. their internal team co-workers who really can't fire them). Emphasizing how your experiences from your originating domain will apply to the target domain is key. Beyond that, there are plenty of tactics and resources like courses on Maven, Reforge, etc. to teach you how to do a different PM field. One last piece of advice: set your promotion/career growth expectations appropriately. For example, if you are currently a growth PM and on-track to get promoted in a year, don't expect that if you make the transition to an external B2B PM that you're going to necessarily be promoted on that same timeline. You need to spend some time to get up to speed on the area, develop your skills, leverage what you know and learn what you don't, etc.

Being a manager of PMs is a completely different job, with substantially different performance indicators than being an IC PM. For example, there is no way I can be the deepest expert in all areas of the product or customer personas; my utility on these matters is limited to sniffing out what I suspect might be the ground truth on something and helping folks to optimize their research/understanding along the lines of that suspicion. If I am effectively doing my job as a director of PM, there should be three characteristics of my team that I see: * Autonomy in execution: PMs that work for me are decisive in making decisions in their area, and they have a good sense of what decisions I'll want to review but which ones they can make on their own. The latter should comprise about 80-90% and are largely routine, two-way-door (reversible) decisions. Now, this doesn't mean PMs won't consult me for advice about their area, but I always make it clear: they own the decisions for their areas but with that autonomy comes also living with the consequences. * Culture of innovation: We should have a robust ideas backlog that doesn't just comprise ideas originated from myself or the executive team. PM's workloads should be a mix of short-term things they're executing on, plus Horizon 2 or Horizon 3 projects they are researching. * Team is delivering outcomes, not just outputs: Almost the only thing I can do scalably and repeatably is to coach the team and unblock them where I can; execution is up to them. My KPIs are essentially their KPIs; if they have picked realistic yet aggressive outcome-based measures for their work, and are hitting them post-launch, then all of my coaching and advice has been successful.

Hopefully you have a senior/executive management team that believes in data-informed decision making. Data, by the way, is not just quantitative data (e.g. # of customers asking and their ARR) but qualitative counts for a lot, too, especially in B2B. If you don't have such a team, then this is job one, otherwise it doesn't matter what framework you have; prioritization decisions are going to be made by executive team opinion or pontification rather than examination of ideas through that framework. But, assuming you have a management team like that, and largely agrees to let you prioritize based on a framework, then yes, you need one. I wouldn't recommend going crazy here. Effectively all you need to adjudicate whether an idea is worth pursuing is the old effort vs. impact measures. Now, there are many ways to come about this (t-shirt size, 1-10 scoring, etc.) but the most important thing is not the absolute score but the ability to compare ideas against one another. Why are we investing in this versus that? Sometimes the differences are small but meaningful. Last point on these prioritization frameworks: place a few big bets (high effort but high reward) but don't forget to fill the jar with "sand" also (low reward/low effort).

PM I/II/III is primarily about execution. Someone else comes up with an idea/initiative and a PM at this level largely takes direction, writes briefs/PRDs assuming that the business case is a go, since their manager told them to do it. Because these initiatives are rarely risky big digs, most of the debate is about scope, implementation details and sequencing (should we do this now or later, or should the v1 have feature X in it versus the v2). To get to Senior PM, I need to see that PMs aren't just doing things because I think it's a good idea; the PM himself/herself needs to be strongly convicted. Often, this means either (a) I get pushed back on by the PM (in a healthy way!) about why they're going about something differently, or more often, (b) they are coming up with their own ideas and selling me on them. Senior PM moves more into the area of why versus just what and it is the step in the career ladder where the PM will also start to develop more business acumen and skills beyond just interfacing with engineering.