Product & Engineering Misalignment - Your Biggest Questions Answered

There are so many factors that contribute to bad communication. One or all of them can hit your team with a deadly blow. When your team cannot communicate effectively, productivity plummets and your product suffers.

In order for improvements to be made to your team’s productivity, communication lines between the sales, product management and technology leads need to be well choreographed. Also, their roles need to stay clearly defined and not become clouded. The product manager should provide product’s strategic direction, the tech lead should define the technology’s strategic direction and the business team should facilitate financial gains by working on strategy to bring in business.

Do not cloud your teams objectives

It’s very easy for product teams to be overwhelmed by taking on too many projects. When your team cannot clearly understand the goals and objectives and how it relates to creating customer satisfaction, then your team loses purpose and won’t be successful.

Generally speaking, people have different ways of interpreting goals. If the product owner cannot clearly speak to business value and customer satisfaction, project stakeholders will be confused, collaborate poorly and end up under-delivering on expectations.

Product Manager and Technical Lead need to be a strong force

Your dynamic duo must be aligned. Otherwise, product and engineering teams will miscalculate its ability to perform.

Tech leaders are there to provide direction regarding technical scope and assistance on simplifying architectural complexities. Moreover, tech leaders are there to support technical capabilities that increase engineering specific productivity. They have the capability to keep the technical discussions aligned with the company’s technology vision.

Product/Project Managers are there for direction on project scope and business value to the customer. They help the team move in the direction that is cohesive to the company’s roadmap. Most effectively, PMs facilitate effective conversations and speaks on behalf of the business.

Incompetent tech leads hurt overall quality of software, while blundering PMs slow down a project almost immediately .

Measure your product managers through engagement metrics such as engineering satisfaction. This will be a good indication on whether PMs are delivering on their promises, and this should hopefully be bringing business value discussions to the conversation. The fastest way to gauge this is through surveying the engineering team or evaluate documents from the last few retrospective meetings.

You can measure your tech leads performance through code quality reports. Code quality is broken down into a few key performance indicators (test coverage reports, quality assurance metrics, and code evaluation reports). All will provide a leading and lagging indication on team’s ability to be productive while implementing features.

Don’t let the business team demoralize project stakeholders

Demoralized product teams lose interest when the business team does not understand what it takes to release products. Organizations that have a sales culture can really weigh down on product and engineering teams. Naturally, there’s nothing wrong with a sales culture; it’s an amazing beast of its own. However, as an organization, you wouldn’t want sales dictating features and releases. The project stakeholders own that domain and works with existing customers and sales to measure value and solicit feedback.

This is fatal because the product team’s primary objective is to learn from their users. This information needs to be collected and synthesized by the team who is building the solution. Ideally, the creators of the product should go through appropriate design methodologies which encourages divergent and convergent design thinking. Meaning, thinking through unique or variant ideas, while seeking correct solutions to the relevant problem.

If not resolved, product development teams will have difficult time exploring alternative solutions to a given problem or worse, they will end up lacking creative freedom (which hurts innovation). Such a team would stop communicating more than what is necessary, leading to weak lines of communication. When business teams respect and trust product development, their project stakeholders become more creative, productive and alert.

Make sure your business team is educated on product development. When they are not experienced in that area, and the organization is dominated by a sales-oriented culture, it will be a challenge to shift perception of velocity and productivity.

When working with business teams, try the following approaches:

• Focus discussions around product and engineering and what the team is learning through continuous validation methods.
• Avoid feature discussions with business teams who persuade through heavy opinions and non factual justification.
• Use real world examples of how someone can benefit from a feature or product enhancement.

Communication breakdowns

I once had a product manager that had a very good understanding of Agile development. He knew that the engineering team had to be part of the discussion around refining designs and scope of work for a sprint. However, he struggled to apply Agile methodologies to a remote team.

This product manager was struggling with communication. Some of this was related to time zone differences and the very nature of the team not being physically present. The PM was not committed to adjusting his communication style based on the environmental circumstances.

The issue was how expectations were communicated. The PM handed engineers large general features with very little information or context. He expected the engineers to break those down into stories on their own. Conversely, the engineers wanted more guidance and frequent discussions around these features and how they relate to added value to the user. The lack of understanding user value and its relation to the general strategic roadmap created lack of context. The outcome was very low engagement from the engineers.

If you are a PM and are working with a team with certain communication restrictions, adjust your hours and work with your engineering team as often as possible until they no longer need your guidance. If you are not committed to building consistency and shared understanding, the process will break at a moment’s notice when you are not around.

Agile development is a framework, and not a process. You can apply this framework to physical or remote teams as long as you are committed to adjustments that work for your team’s environment. Far too often, Agile leads (inexperienced ones) are dogmatic on their static approach.

Engineers should be stern with their expectations. Stay concise, stay clear and don’t make decisions without getting a complete picture of expectations. Otherwise, you’ll be spinning in circles and wasting a lot of time. When you receive a request, try your best to understand the best way to fulfill it. This way you can move on to the next important thing.

No matter what your responsibility may be, the single most important thing you should ask yourself when dealing with communication challenges: How can I communicate more effectively and how can I better understand my fellow team members expectations of me?

Measuring your groups productivity through engagement is a fast and dirty way to gain insight on your team’s potential. Don’t ignore your team’s communication issues. Otherwise, velocity and productivity will very quickly slow down.

Far too often groups fall into bad behavior through normalization of deviance?—?the idea that over time we can become so accustomed to things being wrong that we start to accept them as being normal and not problematic. Don’t be that person; we have too many of them.