Product Managers, Engineering, and Stakeholder Communication

You’ll often be the connection between other stakeholders and engineering, managing the connections both in and out. If engineering needs support from design, you’ll make that happen. If marketing has a feature request for engineering, you’ll prioritize it and bring it to them.

You act as the nerve center. You will know the most information about everything going on with and around your project. If communication needs to happen, it will come through you and you’ll know the best person to route it to–or you’ll find that person. Much of your job will be spent communicating across functions.

Sometimes, though, a decision needs to be made and opinions are split. If necessary, rather than a week of back and forth, getting your TL in a room with someone for 30 minutes can make everyone’s lives easier.

Communicating Outward

The technical decisions made about your product can have implications for all stakeholders. Marketing may want the ability to target certain users, or Policy may need to understand how data is being collected. As part of your job, you’ll be explaining these decisions to them.

In many cases, the technical details won’t actually matter to them. You instead need to explain to stakeholders what’s relevant to them. You’ll have to take your system and extract what’s important to the party you’re communicating with.

Case Example

You're the PM for Analytics on a consumer software product. In order to support a number of requests from client teams, your engineers are making changes to your pipeline to process data more quickly and are expanding the capabilities of your instrumentation. You are doing this in a way that minimizes impact to existing workflows, but some will be impacted.

There are a number of stakeholders here. The way you explain the changes to them will depend on their roles and their needs. Here are some examples and major points they might care about.

Front-end Engineers - They'll need to know about the new instrumentation methods and the fields that are available. They'll need to know about any instrumentation that will be deprecated and what the new alternatives are.

PMs - They'll care that data is available more quickly. They'll care about what new metrics can be measured with the expanded instrumentation.

Business Analysts - They'll care that data is available more quickly. If any methods for calculating metrics are changed, they'll need to know what's different and how to compare with old values.

Marketing - If the additional metrics lead to new ways to target & segment users, marketing will care about that.

Policy - If there are new types of data being collected, your Policy team will need to know what those are and how they'll be stored. They'll need to make sure your new processing pipeline & storage is compliant with regulations.

Most of these stakeholders don't care what actually changed in the pipeline. They care about the effects of those changes. Of course, for anyone else who will care about the technical details, you can make sure your engineers present the changes and technical documentation is written up.

Communicating Inward

Stakeholders will have many requests and demands. There’s an important balance & relationship to be maintained with all of them, but as the PM, you’ll have to decide whether these requests are worth supporting.

During planning, this can be much easier. Identify important stakeholders and bring them into the fold early enough that the product doesn’t need major changes to accommodate their needs.

Once you’re already executing, this can be a major source of pain. Decide if it’s important enough to be prioritized over ongoing efforts. If not, say no or push it to your next iteration. Make sure to talk to your TL, as they may be able to do it fairly easily or with a simple alternate solution.

If you are going to make a change, the TL will plan the work with the engineer. Make sure they understand the desired outcome clearly, and update any documentation as needed.