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

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 ...Read More

"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 ...Read More

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 ...Read More

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 certa ...Read More

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 the ...Read More

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 m ...Read More

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 ...Read More