Product Management and Engineering

How to Effectively Communicate and Work Together

In classic Star Trek fashion (and Lower Decks is classic Star Trek), the Captain of the starship Cerritos accidentally touches a cursed ancient mask that then wreaks havoc on her ship, leading to weeks of clean up, mainly from the engineering teams. And it was the third time an ancient mask did that (“stop touching ancient masks!”).

So she orders a mandatory vacation and relaxation for her engineers. But as they go to a premier spa retreat, the entire engineering group continues to work on engineering problems, drawing solutions in the sand and even hacking their own relaxation monitoring bracelets, much to the frustration of the captain.

Of course, what Captain Freeman failed to consider was that 1) she needed the spa retreat and 2) the type of relaxation that her engineers needed was different than the type that she needed.

They were each speaking a different language. When she realized that her engineering team enjoyed solving problems and found different things relaxing, she had a different perspective. And when the engineering team realized it was really the captain who was in trouble, they quickly engineered a solution to help her relax.

---

While we’re not captaining starships or cleaning up the fallout from cursed ancient relics (unfortunately), product managers and engineers often encounter a similar problem: approaching problems from different perspectives.

Of course, this can be a great thing when we recognize it and work together effectively. But it can also lead to trouble.

Effective collaboration between product managers and engineers is crucial for the successful development and delivery of products. Open communication, trust, respect, and alignment of goals are key factors in establishing and maintaining this vital relationship.

While I’m a huge believer in the trifecta of Product, UX, and Engineering (and would never leave out our beloved UX counterparts), I want to focus here just on Product and Engineering, and how we can effectively communicate and work together.

Establish clear expectations

Setting clear expectations within the team from the beginning is vital for avoiding potential misunderstandings and working together effectively.

Ownership

At a high level, we usually have a lot of agreement on areas of ownership. For example, the table below shows some of the generally agreed upon key responsibilities for product managers and engineering teams:

The product manager traditionally owns the “why” of the product. This involves the key problems that the team is trying to solve and the goals or metrics for how it will impact users and the overall business.

The product manager also owns the “what” of the product. This deals primarily with the prioritization decisions that are fundamental in product management. What problems and goals are we focused on. What features are we prioritizing.

Engineering owns the “how” of the product. How do we build it. What will the architecture look like and how will we shape the solution. Engineering also owns the “who” of the product. Often a team will divvy up work based on expertise or workload or other considerations. And that is for the engineering team and manager to own.

Of course, the discussion of “when” inevitably involves a large amount of give and take. Since there may be some specific business needs and timelines, product and engineering will have to work together “what” can be delivered in the specific “when.”

The key to all of this is aligning as a team, product and engineering, on ownership and responsibilities.

Norms and ways of working

Establishing clear expectations goes beyond the high-level “who, what, why, when, and how” conversation, though. It’s critical to establish norms within the team as well.

When we work

Product managers are in meetings frequently, and often scattered throughout the day (which is less than ideal, but let’s just face reality). So establishing a cadence for the development team is important. Because having meetings scattered throughout the day for anyone is a terrible idea, but it is a productivity graveyard for engineers.

A few years ago I had a great conversation with Jens-Fabian Goetzmann about this topic:

In one organization, we established a loose team rule to avoid meetings in afternoons. That way, the engineering team could have large blocks of time dedicated to their work. In another organization, we specifically blocked off entire days from meetings for everyone (a truly amazing feeling if you can get there). So you could always depend on certain days in the week to be fully dedicated to heads-down work.

There is no right or wrong answer to establishing working norms, but it is incredibly helpful for the team and each individual to establish some norms around when you are working or having meetings.

How we work

How we work together varies from team to team as well. I’ve worked in many organizations and with many different development teams. No two teams have ever worked the same. And that is totally fine.

The key is establishing norms around how to work together.

In one organization, the development team hated the idea of having fully fleshed out documents from product, full of requirements and details. They much preferred to understand the high-level problems and then help work out all the details.

In another organization and with another team, this was the complete opposite. The team preferred to have most of the details sorted before discussing as a group or getting involved.

Every team is different. Again, there is no right or wrong no matter what anyone says. But establishing how you’ll work together is key. What does product need to bring to the table for engineering? At what point will engineering get involved? Who on the team wants to be involved with customer interviews (some engineers love it) and who wants the key takeaways along with requirements (some really good engineers prefer this as well).

Create a shared understanding

As product managers and engineers, we need to create a shared understanding.

Product strategy, business, and customers

Much of the onus for fostering a shared understanding of the product strategy, the business goals, and the customer needs falls on the product manager.

In most of my roles as a product manager, I’ve blocked time in most refinement meetings (or at least monthly) to review the current strategy, roadmap, and feedback. It can often feel redundant to talk so much about the strategy and roadmap, at least I’ve felt that way. But the feedback I’ve always received after these discussions has been extremely positive.

Remember, most of the team is not in the details of the roadmap and goals every day like you are as a product manager. So almost everyone appreciates hearing the updates on the strategy, the “why,” as frequently as you are able to give them.

Other ways to create a shared understanding involve similar themes. In other team meetings, can you review your goals and metrics? Is everything easily accessible to everyone to review regularly?

In another role, I also sent out a weekly update email. Now, this may be a bit much depending on your role or team, but in this instance, it was very effective. I recapped customer interviews, the roadmap, progress on goals/development, and what was coming next.

As someone once said (though I forget now where I heard it): you’ll know you’ve talked enough about your strategy, goals, and roadmap when everyone else can tell you about them from memory. So keep building up that shared understanding.

Technical

It’s also critical to create a shared understanding of the technical aspects of the product. Everything from the tech stack to the architecture to the strengths of individuals on the team.

Product managers don’t need a technical background to be effective product managers. But they need to understand as much about the technology as they can to be the most effective.

Engineers—you need to help your product managers understand the technology, the code, the deployment process, the tools, the constraints, the use cases, the technical debt, and everything else. These may seem like engineering specific concerns, but they have broader impacts. For example, often the deployment process can impact the go-to-market strategy, or affect other dependencies on the roadmap. So product managers need to understand. And maybe they can even help push to make broader improvements (another voice advocating never hurts).

Having a deep, shared understanding of the product from a technical side and from a business/customer perspective is critical for product management and engineering. The whole team is far less effective without this deep understanding.

Iterate together

Frequent and constructive feedback is crucial for maintaining a healthy working relationship between product managers and engineers.

Process

Implementing an iterative feedback process allows product managers and engineers to share their concerns, ideas, and progress updates regularly. We can do this through various channels, such as stand-up meetings, design reviews, code reviews, sprint retrospectives, or one-on-one check-ins.

One of the best places to evaluate and iterate is in regular team retrospectives. There are many great online tools you can use, many specifically designed for retros. They allow everyone to add their thoughts to what is going well and what isn’t. And then you can discuss as a group.

I’ve found it particularly important to leave these types of meetings with a short list of changes we want to make. If the list is too long, it becomes impossible to remember. But having a few items that everyone agrees on improving will allow you to focus. And then you can evaluate progress regularly and in the next retrospective.

On one team, we did these regularly. One item we decided to change was how we ran meetings. We felt like too many of our meetings were unfocused, and we wanted to make them more productive by having better agendas and ensuring that everyone came prepared. So we set a goal and began creating more structured meetings (myself included) and coming more prepared (everyone actually looking over the stories or the documents beforehand). And it was very effective. Not perfect, but really improved our meetings.

By providing ongoing feedback, we can address any issues or misalignments early in the process, leading to continuous improvement and better overall collaboration.

Build trust

Like any relationship, it is critical to continually build trust between product managers and engineers.

Building trust takes time and effort. In one organization, I remember watching an experienced product manager come into a team and try to implement a bunch of changes to processes and norms without taking much time to get to know the team or understand the dynamics. He assumed there would be mutual trust simply because of his role in the group. But he was wrong, and struggled for months.

Like any role, it takes time for a product manager to build trust with a development team. And it can also take time for the development team to gain the trust of the product manager. So you need to constantly work together, be open, and be a little vulnerable to establish and maintain trust as a group.

It’s important to be open to the feedback we discussed above. The more you can create a culture of psychological safety for everyone to express their thoughts, the more trust you can build as individuals and as a team.

At the end of the day, we’re all people. People working together to build things. We will have disagreements and different preferences. But those can help make the team and the product better when done right, with a spirit of collaboration.

So…

Product managers and engineers often come from different backgrounds and have different perspectives. We need this for great product development. But it can lead to misunderstandings. Like the starship Cerritos, different groups value different things. But we can work together to create the right outcomes.

It starts with understanding each other better, respecting the way we work and what we each bring to the group, and building on our shared goals.

By focusing on clear expectations, a shared understanding, an iterative feedback process, and building trust, product managers and engineers can foster a strong working relationship that drives successful product development and delivery.