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

I think I intuitively knew this, but the amount of time one ends up spending on trying to improve communication between different individuals and teams in the organization increases dramatically as you become a more senior leader. Much of this work happens behind the scenes and is hidden from ICs. It can involve anything from the coaching that you do with your team to improve their communication to the cajoling (and yes, sometimes threatening) that you need to conduct with other functions like engineering, design or marketing, or even other PM teams to improve their interactions with your team. Spending a lot of time thinking about organization design, what work to delegate to whom and for what reason, constantly evaluating your own team and their strengths & weaknesses -- if you don't enjoy doing these things and seeing your impact chiefly through other people, you probably won't enjoy being a leader of PMs.

Just like there are a million ways to segment the market, there are also a million ways to segment PMs. :-) Here are a couple of ways I like to think about PM segmentation: * B2B versus B2C. This is probably the most obvious. In B2B, there is a smaller pool of customers, so you truly get to know them and build long-term relationships with individuals at those customers. The drawback is that you're always fighting against the "whales" (folks paying you a lot of money) skewing your roadmap in their favor rather than what you want to do as a PM which is to build for a market. In B2C, you need to be much more data-oriented, since a minor change can impact millions or even billions of users and materially move the needle. The downside is that the job can be very impersonal, particularly for a mature B2C product, as you're spending a lot of time trying to optimize for a 0.01% gain. * Domain-specific versus domain-independent. There are PM roles that require deep technical knowledge in a domain, and there are those that don't. An example of the latter (and maybe these folks are going to hate me for saying this) is growth. The skills of a growth PM can be easily transferable between domains, as they are essentially about creating great onboarding and upsell journeys in-product, and the tactics are often very similar no matter what the type of product is. The downside is that growth is frequently one step removed from the actual customer problems i.e. JTBD that a customer is hiring the product for in the first place -- some other PM works on that. * External versus internal, or another way of saying revenue-facing versus not. I used to say this was customer-facing or not, but this is inaccurate because every PM has a customer. The distinction is whether that customer is external (paying your company money) or internal (some other constituent inside your organization). An internal PM would be someone who works on, say, data systems or billing systems. These jobs can be very secure and valued, but there can be limited growth prospects because the level of ambiguity is very low. One other way of saying this is whether you work for a profit center or a cost center. To the second part of the question -- there's often no way to know a priori when you're starting out in PM what you are going to like or not like. You likely have intuition (a hypothesis) of your preferences but you don't know until you get there. The best thing you can do is apply good PM skills to your own career: stay curious, ask yourself the "five whys" of why you do or don't like something in your job, don't stick around too long if you're not growing or you truly are hating something, and challenge yourself to get out of your comfort zone and try something that scares you.

In my opinion, it's best to land a customer-facing role (support, customer success, expert services, pre-sales/sales, etc.) and then try to make a lateral move into PM, at the same company if possible. That's because customer empathy -- or even more important than that, unique customer insights and a point of view about the customer and the market -- are the most critical skills I look for as a foundation for whether someone new to PM is likely going to succeed. While it's not impossible to start with a technical job like engineering and then move into PM, it's more difficult because there are fewer reusable skills (and frankly, there's an implicit bias in the industry that technical folks don't know how to talk or empathize with customers).

The answer to this is going to be different for each person, because it depends on so much on the intersection of your own values and what you're trying to achieve in life. Personally, I look at these factors: * The domain of the company and the domain I'd be working in at that company. Could I stand to work in that domain for 3-5 years or even longer, taking into account the market dynamics of that sector? It's why I don't want to work in health care or FinTech, but obviously, many other folks have no problems with these domains. * The size of the company. Honestly, I wish someone had told me to pay attention to this early in my career so that I didn't get stuck in the enterprise for far too long waiting for the underlying dynamics to change (they won't). But a Series A company versus a Series B company versus an established company -- these are all going to have massively different dynamics and it would behoove you to figure out where your sweet spot is as quickly as possible. * The growth prospects of the company. Obviously, you cannot see into the future, and though lack of hypergrowth is not necessarily bad (and may not fit your preference/personality), if you are ambitious, you probably do not want to get stuck somewhere that is not growing, even though stagnant products still need PMs. * The level of autonomy I expect to be given. I see product management as largely a strategic function, and that includes being able to define and then be held accountable to the execution of a business and product strategy. If the company or team seems unwilling to trust PM to drive strategy, preferring to treat it as purely an execution role (foreman role over a bunch of workers) then it's going to be boring. * The strength of supporting functions. Immaturity in other supporting functions is not necessarily a deal-breaker, as it's common (especially at a startup) for there to be massive gaps in maturity. But if there are no cross-functional partners that I can engage with at a strategic level, that means the deck is already stacked against me and it'll be difficult-to-impossible for PM to eke out a win. PM doesn't win alone. You'll notice I didn't get to compensation at all. For me personally, that comes much later as a consideration i.e. when we get to the offer stage (although I want to know early on if we're at least in the same ballpark, otherwise we are wasting each other's time). If we don't have fit as I articulated above, then compensation isn't going to matter.

I'm heartened to see that as product management has matured as a discipline, the IC track has begun to carry as much weight as the management track. Engineering figured this out earlier than PM did, by having staff/principal/distinguished IC levels, and PM is finally adopting such levels. What this frees ICs to do (who want to remain ICs rather than people managers) is to gain larger and larger scope, coupled with deep domain knowledge, to reach these levels -- and means that managers of PMs no longer have to be both great managers and the most knowledgeable product experts in the room. However, if you do pursue the management track, once you are at director or above, you are expected to be a business leader first and a product leader second. That is, you need to understand how to define business (not just product) KPIs and run your business according to them, which also means that not every business problem is going to be solved by building more product. You will need to have at least a basic facility in other functions that touch PM, such as marketing (specifically, product marketing), sales, customer success and finance; not enough to be an expert in these functions, of course, but enough to have empathy for those experts, speak their language and have an opinion about those areas.