Tips for Product Managers to Communicate Better with Developers
Every software product managers need to understand deeply the pillars of a healthy and successful cooperation with the software developers (she) is working with, from her team, or another. Not only it will help you provide value to customers more efficiently and sustainably, but it will also make developers happy and improve the ambiance across the team.
Introduction
The benefits of good communication between PM and developers is largely amplified in the context of teams building and operating B2B enterprise software because that’s where software developers may not have a direct grasp on the customer’s problems. Effective communication thus becomes essential to fill the gaps and enable proper decision-making.
Bring data on the table
No product manager worth their salt would dare make an argument without having data to back it up. Even though it can be tough to get your hands on that data when you need it, developers tend to be rational kind of people and easier to convince when shown some data.
Know how to obtain, extract, and analyze the data you need to prove a hypothesis. It will encourage developers to trust you better, and reassure them that they won’t be doing things to undo them later, just because you were wrong about some gut feeling or your guesstimates on what the customers want.
Identify the low-hanging fruits
Sometimes, it’s possible to add a lot of value for customers with simple features or improvements that just take a couple of lines of code. Long discussions and negotiations are not even needed when the added value largely overweight the effort to implement something.
Only people who know the codebase, though, should confirm that those are actual low-hanging fruits. Avoid false assumptions.
Involve developers early & negotiate about details
Many prioritization frameworks focus on 2 aspects: Development Effort and Business Value.
Often, the business value is determined at first, then, only after the feature and its scope have been worked out and well defined, the estimation of development effort takes place. Sadly, this is inefficient and fosters a culture where the development team in no more than a feature factory.
What if there are unimportant details that are hard to develop? What if certain existing parts could be reused if slightly adjusted?
Instead, the product team should involve developers at the initial stages of defining a feature’s scope so : Do developers have ideas on how to solve the problem in a much simpler way? Developers can better understand which parts of it are complex and what parts are simple. Developers can help create user stories that are as atomic as possible and can be estimated separately.
Mind the terminology
How things are named is more important than it seems, and it deserves some thoughts. Variable names, classes and the API will be named according to what is told to the programmers. If the product team decides to rename certain things to adapt to changing requirements, the old name in the code might induce a technical debt and makes the code harder to understand for newcomers. To overcome this, you can ensure that all the terms that are important in the scope of a new feature are reported in a glossary and that everyone is on the same page.
Break features down to releasable chunks
Good product managers give seek to minimize the amount of work needed to deliver a certain outcome. They try to keep every change as small and as simple as possible.
They work with developers to break down a large feature lists into manageable chunks, with a clearly defined scope. Each chunk should be a compromise between provided value and the order that developers would prefer.
It helps developers concentrate on one thing at a time (it’s good for software quality), and encourages them to roll out changes as fast as possible to production. Ideally, the first chunk can already provide some value for some customers. If not, unfinished changes are easily hidden behind a feature toggle or omitted in the navigation.
Everything that can go wrong in a deployment change to production will go wrong. It’s Murphy’s law. Pushing often helps identify issues earlier, when fewer code modifications were done.
As a PM, developers will appreciate any of your efforts to help them to work with more agility because this often makes their life easier.
Have kickoffs with the whole team
The bigger a plan is, the more people need to be aligned and the more important the kickoff meeting becomes. For small plans, rituals such as the sprint review or planning meeting will be enough, but when starting something bigger, you might need to put all important stakeholders into the same room. Best is to involve not only the developers but also other stakeholders (like marketing, sales, support or operations) that are playing a part in the project (product, feature, etc…). It is essential that everyone else also knows what is planned and how it will be executed.
Minimise changing requirements and misunderstandings
Needless to say, good planning matters. Before anything is developed, should be crystal-clear what needs to be developed.
Ever-changing requirements are something that annoys developers and for good reason. Now, the truth is that even with the greatest effort, changing requirements is often unavoidable. This is the very nature of software and the complexity it involves as no ambiguity is permitted. Details only become clear over time, or as new problems emerge.
Introducing agility in software product development is how we cope with that, fostering inspection, transparency, and adjustment.
First, show the developers that you try hard to plan features well, but also prepare them that things may change. Make sure that they understand what parts are ironed out and what parts may change or are not yet completely planned. If you write down your plans, you could mark uncertain parts in red.
Second, have regular points in the development process to re-sync the team about why the changes are needed and what effect it has on the project scope.
Third, to convey the requirements, don’t rely upon user stories alone. They are often not sufficient to convey the above. User stories are a reminder to start a conversation, that will help identify gaps in shared understanding and fill them.
Fourth, ensure you have a good source of truth for the requirements. This can be : an issue description, a prototype, a Google doc, a confluence page or the photo of a drawing on a whiteboard, attached in a JIRA or Trello card.
Sync with other PM and Designers
Different product managers might be giving contradicting information to developers, which is confusing and hindering productivity.
To avoid that, make sure, as a PM, that you are aligned with your colleagues.
Writing things down help align people. Also, make sure that your colleges take part in your kickoff meetings and notify them when something essential has changed so that developers won’t be pressed in between different parts of the organizations.
Avoid exposing a messy backlog of ideas
Even though it might sound like a great idea, having a big list of ideas, feature-requests or low-priority bugs is very hard to maintain. The fact is that if there are really important requests/ideas, they will pop-up again and again.
Though, it’s sometimes a good idea to have one whenever verbal communication among many stakeholders is inefficient and is a source for too many debates. Anyways, such a backlog must not be part of the daily development work because it defocuses everyone and makes things messy.
Don’t forget, your job is to help developers to focus on their tasks. Even better, it’s to maximize the value of their work.
Emphasize the problem the team is solving
The team’s job is to provide value for the customer. Unsurprisingly, developers are more motivated when they connect their work with the customer problem and fully understand why a feature or improvement is needed.
Make sure they are clear what kind of value they are providing through the software.
Developers are rational and smart. They often have an idea of how to solve the problem in a less complex way. Sometimes, it’s excellent ideas, sometimes, it highlights gaps in their understanding of the customer’s problem and context. It’s your job to fill these gaps.
Communicate the product vision
A product manager is expected to share abundantly about the product vision and product roadmap. It is in the best interest of software developers to know well about the product direction because it helps them make daily decisions concerning the software architecture of the product and features, to minimize technical debt and maximize code maintainability.
Communicating with developers about the product vision will help them anticipate many things, by answering a few essential questions such as: How the feature we are about to develop may change in the future? What aspects of this feature may evolve to become more complex and how this feature’s code may need to communicate with other parts of the software’s code? What parts of the feature are experiments and might get removed? Is there a similar feature planned in the future to justify some abstraction so that parts could be reused? Communicating proactively the product vision to developers will benefit the product manager greatly. You might collect their feedback regarding the inner-workings of the product to plan better on non-trivial and unexpected dependencies that the team will need to tackle to deliver on the vision.
Developers can design features in a generic or non-generic way. “More generic” is more complex due to superior abstraction, so it takes longer but is more easily reusable or extendable than “non-generic”.
Without enough insights into the product vision, it happens often that developers over-engineer features as a framework, making them more generic than they need to because this added complexity is either not needed or designed with wrong assumptions.
By building with developers a shared understanding of where the product is heading, you help them make better decisions. That’s simple.
Wrapping up
As a product manager, you are fighting to deliver the best solutions to your product’s customers. Improving the communication between the product managers and development teams pays off handsomely in terms of development speed, efficiency, and team satisfaction. Be proactive and work every day to engage better and improve your relationship with developers.