Stakeholders Management

Hero image for Stakeholders Management

We need to talk about two critical areas before anything else: respect and writing.

Respect

There are times when the stakeholders might not know what you do, and understanding each other is difficult. That’s why they hire Nimble; to fill a knowledge gap. Be patient.

There are times when you will disagree with a stakeholder. Never stop proposing ideas and solutions, even if the stakeholders don’t always agree. The debate is healthy as long as it’s respectful.

There are times where the stakeholders are angry. Don’t get angry yourself. Instead, try to understand why they are angry and figure out how you can help them.

Writing

Lots of communication with stakeholders will be in written form—either email, Slack, Jira, Clubhouse, or else.

When you write to a stakeholder, you represent yourself as a Product Manager, and you represent Nimble. Your written communication must be excellent regardless of the language that you’re using.

For English, if you’re not already a Grammarly user, you need to become one. Communications with typos and basic mistakes are not acceptable.

Single Point of Contact

While we keep communication transparent for the clients, we must follow the single point of contact principle.

Having one clear point of contact on both sides (client and Nimble) provides many benefits:

  • Clarity on who to talk to in any situation,
  • Talking to someone who knows the project,
  • Having one person (on each side) responsible for keeping their respective teams up-to-date,
  • Facilitating the conversations about complex and technical topics. The Product Manager is responsible for “translating” business (the client) into technical (the development team) and the other way around.

Rituals

There are two rituals that we follow when it comes to stakeholder management. While both are mandatory, their exact contents can vary depending on the client. We also merge the two more often than not to minimize the number of meetings.

Sprint Review & Demo

The sprint review & demo is a time where we update the client on the progress and, when required, demo the latest changes. It is usually where we remind the client to take the time to test the product on their own and to report any issues that they may find. The client must stay involved and active during the product development phase.

Sprint Planning

Sprint planning is a bit different than the one held with the development team. It’s a more strategic conversation with the client where we review the upcoming features development, bugs, and chores.

It’s also the perfect time to discuss long-term plans, events (e.g., marketing campaigns, promotions), and business alignment. Product Managers use this time to ensure that we are still aligned with their goals and expectations.

Should there be any changes, whether technical or strategic, the Product Manager will work with the stakeholders to understand those changes and help the client make them happen.

Product Decisions

Being a Product Manager building products for external clients can be a confusing position to be in, especially when it comes to decision making.

In-House Decisions

There are times when the development team, or the product itself, requires decisions to be made. Not everything needs to be run by the client. Some decisions can and should be taken internally.

While it is not possible to list down every single case which warrants an internal decision, there are easy cases that apply to all products that we build. Decisions that are easily reverted; technical decisions; UX decisions where we have usually more experience than the client.

In-house decision making is ultimately very dependent on the client. Not all clients give the same latitude, and not all clients like to be bothered for small things. Finding the right balance between making an in-house decision and checking-in with the client requires knowing the client and understanding their needs. It is a very personal aspect of Product Management for clients.

Negotiate & Agree

There will be times where the Product Manager disagrees with a client’s decision. In those cases, we don’t just give up; we negotiate. That’s part of the value-added from our Product Managers. They challenge the clients’ thoughts and ideas intending to build a better product.

Don’t confuse negotiating with arguing. Negotiating means trying to get the client to agree with a different idea by explaining its benefits. It can’t be a hard disagreement without any justification.

There are many cases where our clients eventually agreed to change their mind and trusted our experience with UI, UX, tech, and more. The golden rule is always to push what is in the client’s best interest. Ego can’t get in the way.

Negotiate, Disagree, Commit

Clients don’t always agree with Product Managers, and that’s okay. In cases where the two are in a disagreement, we have the duty to deliver what our clients expect from us. It’s okay to let the client know that we disagree and explain why, but it’s not okay to let our judgment affect product development or the client’s relationship.

When disagreeing, Product Managers must always figure out how to make the best of any decision and commit to delivering what’s expected.

Meeting Minutes

Taking notes during meetings and sharing those notes with all parties involved is essential. It will help track action points and their owner, and it will help with recovering important talking points and decisions made during meetings.

It is critical that any decision made with or by the client be documented and shared in meeting minutes.