Speaking with Software Developers and Product Managers (PMs) at a recent lunch we hosted, it’s clear that they’re both motivated by many of the same things: curiosity, a sense of accomplishment when solving puzzles, an enjoyment of building tangible products.
The product/development relationship in many companies isn’t always smooth sailing, however, despite this shared love of creation. In the rush to get products out the door and into customers’ hands in an agile environment, developers can feel like “short-order cooks” being told what to do and how fast to do it by PMs, rather than true co-creators (our team liked this piece by former Box principle engineer Nicholas Zakas that describes how this dynamic makes developers frustrated).
Here are three ways that developers and PMs can better collaborate so that developers feel like co-creators rather than short-order cooks when cooking up software products.
1. Involve developers in roadmap & customer discussions. Context is king!
Frequent and early involvement of developers in roadmap discussions and customer information meetings can build trust between developers and PMs (and the company as a whole). Benefits include demonstrating to developers that the company values technology as a core part of its product strategy, giving developers a chance to ask questions of decision-makers and buy into the future potential of the product, and allowing developers to contribute their technical acumen and contribute solutions that may have been overlooked by non-technical decision makers.
Involvement of developers in activities that illustrate context around a product can also lead to developers making more informed decisions when writing code. Developers in an agile environment are often required to make educated guesses while working on a product in order to maintain their productivity. If Product Managers include developers in roadmap discussions and customer information meetings, it can help developers grasp the context around requirements and features, creating a reference point that can guide their decision-making when they have to fill in the blanks during feature development.
2. Work together on more realistic estimates.
If PMs and developers collaborate to design chunks of work that are small enough, both sides benefit. Developers can give PMs more accurate estimates to integrate into the release plan, and PMs can give developers the peace of mind that even if estimates become hard deadlines (because of stakeholder or market pressure for example) they’ll be more attainable.
3. Negotiate technical debt around user value.
Dealing with technical debt is another common pain point of the product/development relationship. While technical debt doesn’t necessarily impact customers directly, it can slow down development and introduce unforeseen pain in the future. Developers need to give PMs an honest idea of the technical debt that comes from working with an existing codebase so that the debt can be taken into account in the product roadmap. Pressure to deliver, however, means that technical debt can’t always be dealt with immediately which can lead to developers feeling frustrated.
An effective way to negotiate working on technical debt is for PMs and developers to agree on the short-term and long-term user value of working on different aspects of technical debt and then prioritizing them together. For example, will working on a certain piece of debt improve performance of the product immediately? If so, then developers should consider it higher priority. Will it help the development team build features faster in the future, but result in only slight improvements for users today? This might be lower priority.
If speed of delivery to customers is crucial, pushing aside the ability to work on technical debt immediately, developers can help PMs understand when the debt needs to be dealt with in the future so that the product doesn’t run into significant technical limitations. Negotiating technical debt this way is an opportunity for Developers and PMs to gain trust in one another’s expertise, feel like true co-creators of a product, and encourage ownership and accountability over the final result.
Has your company come up with effective ways to build trust between product and development? We’d love to hear your thoughts.