Can’t we all just get along? Unfortunately, it would seem that in the fast paced world of building technology, tensions between Product Managers and Developers are pretty common and a lot of the time, it’s the Product Manager who is at fault. A little bit of healthy debate won’t hurt anyone but when relationships become frayed to the point of breaking, it can really impact the quality and success of your Product.
Below are the 3 biggest mistakes that Product Managers make when working with developers and tips on how to overcome them:
1. Not knowing where and when to be involved:
As a Product Manager, you need to know which parts of a developer’s work need your involvement, and which don’t. Involving yourself in minute technical decisions which make no difference to the end user’s experience and where you have no valuable input is a waste of everyone’s time. For example, whether your company’s internal API should use a SOAP or REST protocol is not something a Product Manager needs to involve him/herself in
On the other hand, there are some decisions that absolutely need your involvement. My general framework for involvement in technical decisions is as follows.
Product Managers should be involved in anything that:
A. will be hard to change later:
These decisions could be for example, around choosing your tech stack. Deciding whether to build your website on Shopify vs a custom build vs a different 3rd party, though not an irreversible decision, would be very difficult to change later on, therefore this is something you and your development team should discuss in great detail before a decision is made.
B. impacts the end user’s experience:
For example, if you are deciding between building a native or a hybrid app for your Product. Native functionality differs greatly from hybrid, and so a Developer will need you to think carefully about what type of experience you want to present to your users before making a decision.
C. impacts your ability to do your job as a Product Manager:
An example of this is data structure. If your data is structured in a way that makes it difficult for you to analyze it, you will struggle to measure the impact of certain features. A good way to steer clear of this problem is by telling your developers what type of data and insights you will be looking to gather once the feature or product goes live, and they can then design the schema accordingly. As a Product Manager, you should make sure that you thoroughly review and approve the schema before it goes into the implementation phase, which means you need to be thinking about how you will measure the success of what you’re building well before it’s built.
Bonus tip:
It’s equally important to know when to involve developers in your work! The general consensus is that it’s best to involve developers as early as possible in the software development lifecycle, even as early as the ideation phase. Not only will a developer’s perspective be important in relation to feasibility, it will also ensure that they feel valued and that they understand the business case. Understanding the ‘why’ will be crucial for them in their decision-making later on.
2. Telling developers ‘how’, rather than the ‘what’ and ‘why’
Your job as a Product Manager is to explain the ‘what’ and ‘why’ to your developers and leave the ‘how’ to them. This is especially important if you come from a technical/engineering background, wherein it may be tempting for you to step in on technical decisions or even writing code yourself. Even if you have a strong grasp of technical concepts, unless you’re actually doing the day-to-day technical work, it’s best to leave out your strong opinions on how to accomplish certain features.
Instead, focus your time and energy on being as detailed as possible on the ‘what’, with your User Stories and Acceptance Criteria and the ‘why’ which is giving the developers as much as evidence for why the feature/product will create user or business value. Every Product Requirements document should start off with explaining the business case and what you hope to accomplish with the feature/product. This will empower developers to make decisions while always keeping the product’s goal at the forefront. Moreover, the more detailed your User Stories and Acceptance Criteria are, the less ambiguity and uncertainty you leave for the development team, which means they can focus all their attention and effort on writing code that works. Make sure that you cover edge cases and error states. Developers work best when they are able to focus deeply and there is nothing more annoying for a developer than having to stop what they’re doing in order to ask you how to handle a particular error state.
3. Ignoring technical debt
As a Product Manager, there are many instances in which you will have to prioritize speed and agility when building or testing new features, and this almost always comes at the cost of quality code. However, most developers are very familiar with the ‘move fast, break things’ approach and will perfectly understand the need to not spend an unnecessary amount of time on features that are still being tested. They will understand that having technical debt is a normal part of the software development process.
The problem occurs when technical debt is ignored completely. Unmanaged technical debt is one of the biggest causes of low morale1 amongst engineering teams. It can cause developers to lose confidence in their decision-making abilities and can cause a general decline in productivity.If that’s not bad enough, studies have shown that technical debt massively impacts a company’s ability to innovate2.
So how should you as a Product Manager, strike the correct balance between agility and managing technical debt and in doing so, help to support the morale of your Development team?
The number one tip is to build in technical debt management into your estimates and resourcing plans. A general guideline is that 20-30% of sprint capacity should be reserved for clearing technical debt but the actual capacity you reserve is highly dependent on what stage your business is at. 30% could be too much at an early stage startup, however as soon as your product reaches some sort of maturity and stability, you can start raising that number upwards from 0. Regardless, slowly chipping away at technical debt week after week ensures that it never reaches the state where it becomes overwhelming and severely prohibitive to productivity and innovation.This ‘give and take’ between Product Managers is essential because it will show developers that you understand how frustrating and demotivating it is to work with poor quality code.
Other parts of the process that you can impact as a Product Manager, which will take away from your short-term agility, but will definitely improve it over the long term by minimizing the amount of technical debt you create to begin with is code reviews. Ensure that code is reviewed by several pairs of eyes before it goes live and encourage the use of tools and automations that can help speed up the code review process, like SonarCloud.
Another tip is to remind developers of your shared goal, which is whatever impact you are trying to create for the user or the business. If you involve developers early on from the ideation stage, they will better understand what you’re trying to achieve and why, and will then be more likely to focus on achieving those goals, rather than on writing perfect code.
Conclusion
In general, building a healthy relationship with your Development team is all about building trust. Involving them and yourself in the right moments, ensuring that they understand the business case and the ‘why’ behind your product strategy and helping them to keep technical debt at manageable levels will all help to build trust between you and your Development team. Once they see that you have theirs and the company’s best interests at heart, they will be willing to go above and beyond to help you achieve the company’s goals.
_________________________________________________________________
What do you think are the top mistakes that Product Managers make when collaborating with Development teams? Have I covered the major ones or are there any others? Let me know what you think in the comments below!
Leave a Reply