Stakeholders Management

The team needs to talk about two critical areas before anything else: respect and writing.

Respect

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

There are times when the team 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 when the stakeholders are angry. Don’t get angry yourself. Instead, try to understand why they are angry and figure out how the team can help them.

Writing

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

When an individual writes to a stakeholder, they represent themself as a Product Manager, and they represent Nimble. Their written communication must be excellent regardless of the language that they’re using.

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

Single Point of Contact

While the team keeps communication transparent for the clients, they 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 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 the team follows when it comes to stakeholder management. While both are mandatory, their exact contents can vary depending on the client. The team also merges the two more often than not to minimize the number of meetings.

Sprint Review & Demo

The sprint review & demo is a time when the team updates the client on the progress and, when required, demonstrates the latest changes. It is usually where the team reminds 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.

Email Template

Subject: {Project name} - Sprint #{number} Review

Hi everyone,

Below is the summary of Sprint #{number} ({start_date} - {end_date}).

Please review it and let me know if you have any questions.

## Sprint #{number} Review ({start_date} - {end_date})

### What went well

List the accomplishments from this sprint in bullet points. Typically, they are the sprint goals.

- Epic name 1
- Epic name 2
- …

### What could be better

List the things that didn’t go as planned, e.g. the need for a hotfix or mid-sprint changes requested by the client.

## Release Summary {date}

Update the client product’s version number & release status. Below is an example:

- Android app: version `2.6.0` - under the app store's review
- iOS app: version `2.5.0` - ready for public

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 the team reviews 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 the team is 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.

Email Template

Subject: {Project name} - Sprint #{number} Goals

Hi everyone,

Below is the summary of Sprint #{number} Goals ({start_date} - {end_date}).

Please review it and let me know if you have any questions.

## Sprint #{number} Goals ({start_date} - {end_date})

The following features are listed in the order of priority.

- Epic name 1
- Epic name 2
- …

## Potential Issues

The Product Manager can optionally list what can affect the sprint goals and team performance, but not a blocker. For example, the API is not ready for testing; some design parts are still under discussion when we write this email, etc.

Remember that the blockers should be discussed immediately and separately from this email as they require the client's urgent attention.

## Additional Notes

The Product Manager can optionally use it to remind the client what will happen in the sprint and our planned actions. For example, (the following list is not exhaustive):

- Team leaves - date, time & replacement
- Public day off
- Changed sprint length or release date due to special reasons
- Changed team size

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 impossible to list every case that warrants an internal decision, there are easy cases that apply to all products that the team builds: decisions that are easily reverted, technical decisions, and UX decisions where the team usually has 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 when the Product Manager disagrees with a client’s decision. In those cases, they do not just give up; they negotiate. That’s part of the value-added from the Product Managers. They challenge the clients’ thoughts and ideas, intending to build a better product.

There are many cases where the clients eventually agreed to change their minds and trusted the team’s 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 disagreement, Product Managers have the duty to deliver what the clients expect from them. It’s okay to let the client know that they disagree and explain why, but it’s not okay to let their 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.