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

Quite technical, because you cannot have the requisite level of empathy for the target user, not to mention be credible with your engineering team if you aren't. Now, I do think that a mistake that PM hiring managers for devtools often make is trying to optimize for specific knowledge in a particular domain (e.g. if you're an observability company, trying to only find PMs that already know monitoring/observability). This is unnecessary. What I look for are transferable technical skills: have they been a software engineer/devops/SRE before? Or worked as a field engineer (sales, post-sales) for similar products? Knowledge of the domain can be acquired over time, but the candidate definitely has to have a basic aptitude for technical problem solving and not be scared of getting their hands dirty in touching the product. One way to evaluate this is to have them demo a technical product that they have familiarity with or worked on in the past.

It can vary from not-terribly-technical to quite technical. This depends on how complex your product is and how much the nuances of that complexity matter to the user's success with it. As an example, GitHub Actions has sophisticated features like matrix builds for parallelization, required and reusable workflows, and others where the design, down to the structure of the YAML, matters a lot to the end user. But even in Actions, these are corner cases. What's important is that developer product managers not be afraid to dive as deep as necessary into technical details. Now, 95% of the time, do they need to be reviewing engineering design documents with a fine-toothed comb? Largely not, assuming that their partnership with engineering has been going well, and also that engineering has enough empathy about the end-user to make the right call even at a low level of detail.

Lots of changes are happening, chiefly motivated by the end of free money (i.e. post-ZIRP era) and the rise of AI. I know everyone has probably heard these two themes a million times before so let me break it down specifically for this area. The end of free money has been talked about a lot on the vendor side but not so much on the buyer side. Startups are under pressure not just because VCs are a lot tighter with their funding rounds, but also because revenue is drying up for point solutions as buyers are tightening their belts & trying to consolidate spend onto a smaller number of platforms (exhibit 1: Datadog). Whereas in the ZIRP era, developer buyers had a lot more latitude to experiment with individual tools that might deliver small productivity gains (or were even of questionable value!) This does not mean that all point solution tools will die off -- not in the slightest. What it means is that point solutions who have been in business for >5 years are trying to move up market to the enterprise and/or build a platform (or get themselves acquired by a platform), which leads to a Cambrian explosion of new point solutions. However, these products will be more laser-focused on value as expressed in direct revenue, rather than "blitzscaling" to create massive adoption first and figure out the value/revenue later. How does this impact developer product management? It means the developer PM now needs to be focused not only on whether the feature is cool and shiny, but also become more financially literate: what is the ROI and time to realize that ROI. Financial literacy is even more critical in the era of AI, which promises to bring about a whole host of fundamental changes in human/computer interaction, yet at a very high cost today. It's critical that PMs keep abreast of macro trends in AI, but not to get distracted with the day-to-day minutiae of how this model outperforms that model (unless you are building a product solely in the AI domain for AI/ML developers, in which case, have at it.) Two things that developer PMs have to keep in mind in the AI era: 1) How do the innovations in AI change how developers specifically will interact with computers in the future & what interfaces/experiences are possible now that weren't possible before and 2) What is the cost of delay in prioritizing good AI ideas? Right now we are often seeing cost of delay as positive because the cost of AI computing infrastructure is coming down so rapidly but there can also be persuasive arguments to be made for accelerating certain features to market in areas where you don't have a good moat (you need to beat competitors to the punch).

We divide up the team by domain area and then map existing features and area-specific outcomes to them as much as possible. Obviously, it's not always possible to create a MECE (mutually exclusive, collectively exhaustive) division of areas of responsibility (AoRs) among all PMs, but I am constantly examining the current org structure and AoRs and discussing with my engineering leadership counterparts as to whether we need to make any changes. I should also mention that we also align engineering teams to domains, not technical services -- although in the fullness of time, your technical architecture should increasingly be domain-driven if you adopt this model. Setting up both the engineering and product org structure this way creates accountability for long-term outcomes in the area, rather than a project-oriented focus. Two books that are excellent for understanding the advantages of organizing teams in this way are <i>Team Topologies</i> by Matthew Skelton and Manuel Pais, and <i>Domain-Driven Design</i> by Eric Evans (the latter is more valuable for engineering leaders).

Quite a lot. But one has to be cautious in this and have PM exercise oversight, because not all developers are alike. Your developers may not accurately represent developers at your target customer. One can easily fall into the trap of assuming that the same pain points that your team experiences while using your product will be the same ones that customers prioritize. (By the way, it is very easy for PM to fall into the same trap.) There is one universal truth, though, and it is that developers everywhere are annoyed by papercuts; both the developers working on the product as well as developers we are selling to. Therefore, we empower our developers to "see something, say something, fix something" for small issues without having to ask permission. This comes with guardrails in the form of a timebox. The contract is that if such a fix is going to tie up a developer for more than a couple of days, engineering should discuss it with PM first.

I have a lot of opinions about open-source business models, many of which I am sure are not popular, but let's jump in anyway. :-) First, let's start by acknowledging that there is a basic tension between open-source software (OSS), which is fundamentally socialist, versus our capitalist economic system. It is a very tricky balancing act for a PM, particularly if you have inherited a number of substantial, imperfect dynamics about the business from the founding team who have walked through certain one-way doors already. One of those one-way doors is the decision about what should be open-source or not, so the whole notion of trying to "monetize open-source products" is in no small way an attempt to reverse through a one-way door. This is why so much blowback occurs when companies attempt this (exhibit 1: Hashicorp changing to a Business Source License). Very, very few firms are successful without massive impact to their brand and destruction developer trust. I can only think of three in recent memory (MongoDB, Elastic, and Docker) who have pulled it off, and MongoDB already had the controversial AGPL moat to start off on a better footing. (Tenable is one of the few who were able to relicense Nessus decades ago and lived to see another day as a company, but the world has changed and such a move, made today, would cause an enormous storm relative to that which it caused back then.) Assuming that the question is not about trying to force horses back into a barn after they've already escaped, the answer is that you have to figure out how to add commercial value on top of the open-source core, rather than trying to do a "take back" on the open-source by monetizing it just because you couldn't innovate on top of it. "Open core" business models are certainly controversial among the pure OSS types, but I would argue that they do work, except that you need to work twice as hard to create value on top of the OSS plus create a defensible moat. The best "open core" business models are ones that even the OSS zealots could live with: products that consume the data from OSS or make it better in some way (management interfaces, data analytics, etc.), but aren't directly exploiting the free labor of OSS contributors because there's a clear contract boundary between the OSS and the value-added product. The most problematic are ones where "core" is just a basic version of the enterprise product ("Community Edition" versus "Professional Edition") and the company is directly making money off all the free contributions from the OSS community.

"Push back" is a strong term. With developer tools, you can't just discount what your engineering team says out of the gate, since they already have a lot of built-in empathy for the target customer. So listen to them carefully but remember (and also tell them) that they are unlikely to be right 100% of the time. What you have to do in this situation is to elevate it to use cases. Developers paying for the product aren't just sitting around calling APIs for fun. They have an objective in mind as those API calls support something else they are trying to do. Bringing those common use cases to your engineering team ("here are the 15 customers I talked to in the last 4 weeks who are trying to paginate this way because of reason X") helps them to gain more empathy. Finally, it can also be very instructive, particularly for dev tools products, to have engineers sit on customer development calls. That way they can have an engineer-to-engineer discussion. As the PM, you just have to moderate, so that it does not devolve into a pissing match of who is the better engineer, which can sometimes happen when engineers get defensive about what they have built.