3 Signs Showing Your Engineering Organization and Product Management Team Are Out of Sync and How to Remediate?

Product management and engineering are two of the most critical functions in an organisation. Both roles play a vital part in the success of any product, service, or software-as-a-service (SaaS) business. Whether your organisation is just getting off the ground or you’ve grown so fast that things feel like they’re spinning out of control, keeping product management and software engineering aligned is essential for long-term growth and success. 

When these two teams work together effectively, they can be a solid foundation on which to build a successful company. But when their dynamic is off, it can throw everything out of whack. When these two teams are not working well together, your organisation won’t reach its potential. Here are some warning signs that your engineering and product management teams are out of sync and how you can remediate the situation.

Your engineering team is writing product requirements

The foundation of any successful product is its requirements. They specify what the product does, who it does it for, how it does it, and why. They establish the product’s scope. These are meant to be a living document that gets updated as the product evolves and grows along with customer feedback. These requirements are the foundation for discussions, debates, and product development. In a well-functioning engineering organisation, product requirements are consistently being written. This is critical because it helps build a foundation of consistency and alignment across the entire organisation. The product manager is responsible for writing product requirements. However, if this isn’t happening, the engineering team will write their own requirements. This is a bad sign because it means engineers are writing requirements according to their own sense of priority. This can lead to feature creep, which is when there are more features in the product than the team can feasibly complete or to the product gradually losing its touch with your market, which of course is a dreadful situation to be in.

How could you remediate with a Sprint Planning Dashboard?

Metrics can be used to track the success of your product requirements-gathering efforts. For example, in a software development context, you might want to eyeball Sprint Planning. In this case, you could get an overview of your team’s items in sprint and deep dive to see how it gets spread among the team. You can also review your team’s workflow and see how items are progressing in the development funnel. This is possible when data is consolidated across multiple stacks including the project management tool(s) and the git repository(ies).

This free Sprint Overview Dashboard helps you connect the dots and instantly access insights like Items in sprint, Sprint progress, Overdue items, Status and Development activity spreader by stage in the development cycle. 

Use the Sprint Overview Dashboard

Engineers are constantly frustrated because of scope changes

There are two flavors of product changes: good and bad. Good changes are those that are made because of market changes or customer feedback. These are changes that are meant to make the product better and serve a strategic purpose. Bad changes are those that are made out of convenience or because of internal politics, potentially harming your strategic positioning. If your engineering team is constantly frustrated by scope changes, it’s likely that bad changes are being made. This can be due to several reasons, but the main cause is that product requirements are not consistent. If product requirements are not consistent, engineering will constantly be frustrated because they can never get ahead. If requirements are constantly changing, it could be because there is no clear priority driving the product. Or, it could be because there is no clear vision for the product. These two situations put product management on the hot seat. If they are constantly changing requirements, it shows a clear lack of understanding of how to prioritise. If they don’t have a clear vision for the product, it shows that they don’t understand what the product is supposed to do. 

How could you remediate with regular user testing campaigns?

Regular user testing campaigns are a great way to improve product requirements. Also, no one internally will argue against  the voice of your customers (or targeted audience) being the most important one. This will kill the internal politics with facts. To implement this approach, you simply need to recruit a group of users or work with a network from specialised platforms to test your product. You can then observe how they use it and take note of any issues they encounter.

While user testing is often done in the early stages of development, it's important to keep an eye on your process throughout the entire lifecycle. By doing so, you can identify potential issues before they become problems.

This will ensure that you deliver the best possible product to your customers and enable a long term vision for your product. Your engineering team will be able to plan their work efficiently.

‍

Engineers and product managers are not communicating effectively

A product manager and an engineering manager are two people who must be able to communicate effectively and trust each other. If they can’t, the communication between their respective teams will be strained. This is never a good sign. If your team members cannot communicate effectively, there is likely a breakdown in trust. This is especially true if they are not working together directly. This is not to say that they have to work independently. But they should be talking regularly and be fully engaged in each other’s work. If they are not, it shows a lack of trust between the product manager and engineering manager. It shows that each team leader is prioritizing their own work over the general interest. 

 How could you remediate without getting into endless meetings?

There is nothing more frustrating than getting to a meeting with no agenda, no preparation or a 60 slide presentation without any direction. Sharing common goals and easy-to-digest content that will shorten a meeting is the way to go. 

The frequency of your meeting will depend on the team’s size, number of goals, organization and process type.

Here are a few good reasons to meet with your engineering team:

• Share user testing and customer usage and feedback in a consolidated view to inform the product roadmap
• Share product backlog defined from  the user testing, usage and feedback
• Agree on metrics / dashboards and collect the team’s insights on how the dashboards can be improved
• Adjust the goals and processes based on the observed metrics

Here are a few dashboard templates that could be used:

The software delivery dashboard which will help you track product velocity

The Development Assistant Dashboard which will help individual software engineers track their own progress against goals:

Conclusion

Successful engineering and product management teams are like the two sides of a scale. If one side is heavier than the other, the scale will tip. In order to keep your scale balanced, you need to make sure that the dynamic between these two teams is healthy. If your engineering team and product management team are out of sync, your organization will not reach its full potential. It will struggle to get products out the door. It will struggle to make money. And it will struggle to retain customers. That’s why it’s so important to address any warning signs that these teams are out of sync.

Share your tips on how you keep your product and engineering teams synchronized via Twitter!

‍