Jeremy Glassenberg

I assume by "Developer Product Manager" you mean a Product Manager who is focused on developer-facing Products, like APIs or infrastructure tools. I've worked in the API space for many years, and have trained people from a variety of backgrounds to become PMs in the API space. I find that these roles should require more technical knowledge than the average PM. In general, PMs need to have some skill in design, some skill in business, and some technical skills, in order to be effective (design a usable product, align plans to business needs and work with Sales/Marketing/etc to launch, and work with Engineering to build your products). It's beneficial to also stand out in one of those 3 areas, like being great at design to work on customer-facing interfaces, or on technical to handle developer-facing products or integrations. For a developer-facing product, I require more technical skills simply due to the importance of customer empathy. If your customer is a developer, to have strong empathy, you have to understand the real challenges they face as developers. I myself have a Computer Science degree, and while I've been in Product for 16+ years, I still write code to maintain developer-empathy. I continue to write code even after having become a people manager a while ago. That said, many of those I trained to become successful "Developer Product Managers" didn't have technical backgrounds. I often hired them into other roles where they could interact with our developer community, while teaching general Product Management principles, and encouraging/obtaining a subsidy for coursework in programming. A good programming course (no need for a degree or even a bootcamp), combined with on-the-job experience in Developer Support or Developer Relations to interact directly with developers, can provide enough experience and technical chops to do the job well.

I encountered this and similar scenarios with numerous teams, with successes and lessons learned. As others echo, successful public APIs (I’ll define success as achieving adoption externally with positive feedback) have APIs designed based on validated use cases for external developers (commonly termed “Design-Driven APIs”), rather than publishing what’s used internally. Sometimes it's a simple matter of explaining Design-Driven API principles with examples, but often it's more complicated. To make the case for a design-driven approach effectively, it’s important to first listen to others and understand their perspective, then make your case with love and data. That also means not looking at this as about “pushing back.” Firstly, I've come to understand a spectrum of opinions on this topic by those who don’t support design-driven principles, including but not limited to: * A belief that building separate external APIs is inefficient, and already built APIs should work. * Engineers who look forward to collaborating with PMs on APIs, but want to be involved in their designs, and perhaps feel left out. * A more territorial, political motivation, to maintain ownership of a product area. For the first case, a genuine opinion that “I’m the user,” the matter can be handled as I would with a very junior PM who’s acting on gut rather than validated feedback. It may be easily handled by listening, then sharing stories that show how another developer may have a different use case. Or, perhaps an engineer has a specific idea based on their experience, in which case you can 1) make sure they feel that their idea has been heard and 2) encourage them to gather data or talk with an external developer to validate that their idea will work with others. Perhaps offer to help them conduct this research. They can experience Product process and see for themselves the need for validation, and also see exactly why their ideas may not work for a public API. For the second case, which I’ve commonly seen, it’s up to the PM to change their perception and process. Rather than designing APIs and assigning tasks to Engineering to implement them, bring your Engineering team into the design process. I like to share the feedback I gather and work together on the API design itself. The third case is the most challenging. I’d first emphasize not to try to win with facts. It’s not about what’s in the company’s interest in this case. Sometimes you can build rapport, if not with a primary opposition still with other stakeholders. I’d also categorize this as more a politics problem that PMs commonly have to deal with, for which I can recommend several books. It’s out of scope for this question.