AMA: Anima Chief Product Officer, Orit Golowinski on Developer Product Management

I work very closely with developers, but the nature of this collaboration has evolved depending on my role. When I was a Senior Product Manager responsible for the roadmap of a specific product line or set of features, I met regularly with each developer on the team. I spent significant time explaining the vision, roadmap, and user stories, as well as reviewing the implementation details to ensure alignment with our goals. As I moved into leadership roles, my collaboration with developers shifted to working closely with development counterparts at various levels. While I continued to communicate the vision, roadmap, and the rationale behind our development efforts to the extended team, my direct interactions with individual developers became more strategic. Working on development tools, it was imperative to maintain a close relationship with developers for several reasons beyond fostering collaboration and a healthy working environment. I wanted to understand the developer persona better, so I frequently interviewed them to uncover their pain points. Often, these conversations yielded great ideas that we could incorporate into our roadmap. In the developer tool industry, dogfooding—using our own products internally—is a common practice. Listening to developers who use the product and are part of the team provided a valuable source of feedback. These developers deeply care about the product and the company, making their insights particularly relevant. Plus, it's more convenient to follow up with internal developers for additional questions than it is to gather user feedback from external customers and prospects. Overall, my close collaboration with developers has been essential in ensuring that we build products that truly meet their needs and enhance their workflows.

Open source is fundamentally built around the developer community, where passionate developers find value in using the open-source project. They actively use it, document bugs, and contribute fixes, ideas, and additional functionality to the tool in their spare time. When open-source projects decide to monetize, they typically continue to offer the open-source project for free while introducing paid features on top of it. However, there are several common mistakes that teams make in this process: 1. Neglecting the Open Source Project: One of the biggest mistakes is neglecting the open-source project and shifting all resources to monetization features. This can cause disappointment and anger within the community, especially among active contributors who do not receive adequate responses to their contributions. Loyal users may also slowly stop using the tool if it stops updating and providing value. 2. Adding Paid Features Without Distinct Value: Another mistake is adding paid features that don't offer distinct value. If the open-source offering already provides enough value, users may not see the need to upgrade to the paid version. This can hinder the ability to maintain the open-source project without long-term funding. It's crucial to have a clear roadmap for the paid offering that distinctly differs from the open-source features. 3. Changing Free Features to Paid: Changing existing free features to paid ones without transparency, warning, and explanation causes distrust, confusion, and annoyance within the community. It's important to handle such transitions with clear communication and respect for the users who have supported the project. Successful monetization of open-source projects requires maintaining a strong commitment to the community, ensuring paid features offer distinct and significant value, and managing changes with transparency and clear communication. Balancing these aspects can help in building a sustainable model without alienating the core user base.

The developers have a seat at the table when discussing potential features and aspects being considered for the roadmap. It is the role of the product manager to listen to the diverse opinions from various stakeholders, including the developers, and then decide on the priority and roadmap of what will be delivered and when. Developers are always welcome to voice their opinions and explain why they are passionate about specific features. However, the product manager needs to look at the big picture, considering different personas, the buyer, the market, the competition, and how proposed features fit into the overall strategy and impact. Developers play a crucial role in identifying technological challenges, such as migrations, security risks, and performance improvements. These are areas where product managers often rely on the expertise of the engineering team to flag issues that need prioritization. This ensures that these technical considerations are appropriately balanced against other roadmap features. Ongoing communication and collaboration between product managers and developers are essential throughout the development process. Regular meetings, updates, and feedback loops help ensure that the roadmap remains aligned with both user needs and technical feasibility. For example, there have been instances where developer input has led to significant improvements in our product's performance and security, which might not have been prioritized without their insights. These continuous feedback loops allow us to refine our roadmap dynamically and respond effectively to emerging challenges and opportunities. While the product manager is responsible for the final decision-making regarding the roadmap, the input from the engineering team is invaluable. Their insights help ensure that the product is not only innovative and competitive but also technically sound and secure.

In the last few years, I have noticed three main shifts in the field of developer product management: 1. Developer Experience (DevX): Developer experience is becoming a top priority. With dev tools being adopted in companies from the bottom up, developers are gaining more responsibility and autonomy, including the choice of their development tools. Although the individual developer is often the user rather than the buyer, their opinion is crucial. If developers do not like a tool, they will easily replace it, and it may not be renewed. Therefore, it is essential to provide an excellent developer experience and ensure that your tool integrates seamlessly into their daily practices rather than being yet another source of context switching. 2. Shift from Product-Led Growth (PLG) to Product-Led Sales (PLS): While IT spending is on the rise, economic turbulence has made it more challenging to justify expenses. Enterprises are less likely to simply insert a credit card to fulfill the wants and needs of their engineering teams. They need a person to talk to from the vendor who can reassure them about security and privacy concerns and facilitate a procurement agreement. While PLS begins with the product "selling itself," to close the deal, a salesperson is often needed. As a result, there is a growing shift towards PLS. 3. AI and Large Language Models (LLMs): To put it simply—be there or be square. AI and generative AI have been significant boosters in productivity and expanding product capabilities, not to mention the hottest buzz and trend. Companies that don't adopt this technology will be left behind, unable to leverage the benefits and keep up with the pace. There are many considerations to address before implementing AI in products, such as cost, security, privacy, ethics, and more. However, I encourage every product manager to learn how to utilize AI and boost their skills.

I have never worked for a company that didn't have product managers. However, if I were in a position where I needed to convey the importance of product management to engineering leaders unfamiliar with the role, I would focus on a few key points. First, I would explain the role of the product manager as the person responsible for the vision and roadmap of the product. While developer tools benefit greatly from the hands-on experience and insights of engineers, the product manager looks at the product from a broader perspective. They integrate feedback from developers, but they also ensure that the product aligns with the needs of all stakeholders, including users, business goals, and the market. The product manager is also responsible for understanding and enhancing the user experience. They work to ensure that the product is not only functional but also intuitive and user-friendly. This holistic approach helps to create a product that not only meets technical requirements but also delights users. Additionally, product managers keep a close eye on competitors and market trends. They analyze how similar products are evolving, identify gaps and opportunities in the market, and use this information to guide the product's strategic direction. This market awareness ensures that the product remains competitive and relevant. Product managers act as a bridge between engineering, design, marketing, and sales, ensuring that all departments work towards a common goal. This cross-functional collaboration helps streamline development processes and reduces the risk of misalignment between different teams. After explaining what the PM does, I would make it a priority to form strong relationships with the developers by establishing a regular cadence for meetings. This includes hearing their ideas, presenting the roadmap, and involving them in sprint planning and other ceremonies. Building trust through open communication and collaboration helps engineers understand and appreciate the value of product management. It also ensures that they feel their input is valued and that the product is in good hands.