How Product Managers can communicate better with Developers
As the CTO of a successful 3D Printing Software company, I have experienced the company grow from 5 to 75 employees. At the beginning, I was both a developer and a product manager. I could make product decisions efficiently because the communication with the development team was taking place in my head.
Over time we have built out strong development and product teams. Communication between them is an ongoing challenge that we’re working on optimising and perfecting.
This guide is intended for product managers, it offers 10 tips on how to communicate better with developers — not (only) to make the developers happy, but mainly to provide value to customers in an efficient and sustainable way.
While reading the tips, keep in mind that we are discussing the workflow for B2B enterprise software. An environment in which customers communicate feature requests and in which the software developers don’t have a direct grasp on the customer’s problems.
1. Negotiate about Details
Many prioritisation frameworks focus on 2 aspects: Development Effort and Business Value. What I often observe is that the business value is determined first. The estimation of development effort only takes place when the feature and its scope is already worked out and well defined.
This is inefficient. Maybe there are unimportant details that are hard to develop? Maybe parts can be reused if it’s done slightly differently? Maybe developers have ideas on how to solve the problem in a much simpler way?
When the product team involves developers at the initial stages of defining a feature’s scope, they can better understand which parts of it are complex and what parts are simple. This helps make user stories that are as atomic as possible and can be estimated separately.
2. Make a Glossary
How things are named is super-duper important — also for developers. Variable names, classes and the API will be named according to what is told to the programmers. Those names are hard or even impossible to change later. If the product team decides to rename an input field, the old name in the code might stay forever and create technical debt, which makes the code harder to understand for newcomers.
To overcome this, we start each Confluence page with a Glossary of all terms that are important in the scope of a new feature to make sure that everyone is on the same page.
3. Chunk Features
It is important that Product Managers try to keep changes as small and simple as possible. This helps developers concentrate on one thing at a time.
Try to bring changes as fast as possible into production. Hide unfinished changes behind a feature toggle. (That can be as simple as not listing new features in the navigation or hiding a button). Ideally the first chunk can already provide some value for some customers.
Work together with the developers to define the scope of the chunks. Each chunk should be a compromise between provided value and the order that developers would prefer.
4. Have KickOffs with the Whole Team
When starting something big, you need to put all important stakeholders into a room. For smaller things, you can use rituals like a sprint review or planning meeting. But the bigger a plan is, the more people need to be aligned and the more important the kickoff meeting becomes.
You may also want to involve not only developers but also other stakeholders like marketing, sales, support or operations. It is worth a lot, not only to know about the plan but to know in advance that everyone else also knows about it.
Plan the kickoff well. You need to explain what is planned and how it will be executed. Avoid uncertainty (unless researching is part of the plan).
5. Minimise Changing Requirements
Before the development of something new starts, it should be crystal-clear what needs to be developed. Nothing is worse than “changing requirements”. It is important to have a good source of truth. This can be an issue description, a prototype, a confluence page or a drawing on a whiteboard.
Whatever you use, it’s important that developers have no doubt about how a feature is supposed to function and appear before starting development. In my experience, user stories alone are often not sufficient to convey the above.
But even if you do a great job, changing requirements is often inevitable, as the details only become clear over time, or as new problems emerge — which they almost always do. 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. It is also helpful to 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.
6. Sync with other Product Managers and Designers
Another source of inefficiency is when different product managers are giving contradicting information to developers. Make sure that you are aligned with your colleagues. Set up policies and responsibilities. In smaller teams talking might be more efficient than writing things down. Make sure that your colleges take part in your KickOffs and notify them when something essential has changed.
7. Avoid Maintaining a Backlog of Ideas
Having a big list of ideas, feature-requests or low-priority bugs might sound like a good idea. However those lists are often hard to maintain. The really important requests/ideas will pop-up anyway again and again.
In growing teams those lists may become increasingly necessary because verbal communication among many stakeholders is inefficient and is a source for too many debates.
If you need such a backlog, make sure that it is not part of the daily development work. It defocuses and makes things messy. Your job is to help developers to focus on their tasks.
8. Highlight the Problem that you want to Solve
Developers are much more motivated if they know why a feature or improvement is needed. After all, the teams job is to provide value for the customer. Make sure that developers understand what kind of value they are providing. As already noted above, developers often have an idea how to solve the problem in a less complex way.
If there is a non-obvious reason why a certain feature was prioritised (e.g. to win a customer), make sure to also communicate that to the developers. (We also understand business decisions)
9. Communicate the Future
The product vision and roadmap are good to know and should be used as a motivator.
Developers need to know the answer to essential related questions:
How could the feature that is about to be developed change in the future? What aspects of it may become more complex or would need to get integrated with other parts of the product? What parts of the feature are experiments and might get removed? Is there a similar feature planned so that parts could be reused?
You should also collect the developers feedback regarding all of these questions, because the inner-workings of the product is something they are intimately familiar with.
Developers can often design features in a generic or non-generic way. If it’s designed to be more generic, it is more complex, takes longer but is better reusable or extendable.
Often it is the case that developers tend to make features more generic than they need to be (“Overengineering”). Later, it turns out that the added complexity is either not needed or designed with wrong assumptions.
By understanding where the ship is headed, you help the programmers make those decisions well.
10. Identify Low-Hanging Fruits
Sometimes, high valued features or improvements just take a couple of lines of code. It’s sometimes not worth having repeating discussions over effort and value if the actual implementation is not too hard. The time discussing can better be used putting the feature into place.
However, only people who know the codebase should confirm that those are actual low-hanging fruits. Avoid false assumptions.
Final Words
Improving the communication between product and development teams pays off in terms of development speed, efficiency and team satisfaction. I hope that my tips inspire you.
Most important is that you stay agile — not only with your product but also with your processes. There is always room for improvement.