The Pyramid of Stakeholders πŸ”Ί

And how to communicate project status effectively

A few weeks ago I run into this great list by Camille Fournier. It is about soft skills every senior engineer needs, and I joked it was so good I had to turn each item into a newsletter article.

It turns out it was no joke β€” this week I wrote about #13, that is how to communicate project status to stakeholders.

I love this topic because keeping stakeholders in the loop is probably the single most important factor for any project's success. And it is often overlooked, as many people are more comfortable working head-down until results are supposedly delivered.

Or are they?

Communicating with stakeholders often and effectively makes sure we stay on the course and are able to adjust when we drift away from it.

So let's start with the basics β€” what is really a stakeholder? πŸ‘‡

Behold, the Stakeholders! πŸ“’

Stakeholder is one of the most abused words in product and engineering. It is a very generic term that refers to any person who has an interest in the project β€” at any title.

The abuse comes from the fact that these interests can be so different, that there are very few situations where it makes sense to group them together and use stakeholder as an actionable word.

The same mistake is often made in communication: by considering stakeholders as a cohesive group, we are tempted to keep everyone in the loop in the same way. This is bound to fail, for two main reasons:

  • πŸ” Different interests β€” people are interested in different kinds of status updates.

  • πŸ—£οΈ Different languages β€” people have a different level of understanding of what's going on.

Good communication entirely depends on your capability of tailoring the right message to the right interlocutor, which in turn depends on your understanding of:

  1. What they want to hear from you (interest)

  2. How you can say that effectively (language)

To get both right, let's split stakeholders into a few categories, and give to each their own πŸ‘‡

The Pyramid of Stakeholders πŸ”Ί

In my experience, there are three major categories of stakeholders for a product:

  • 🎽 Team Members β€” people who develop the product.

  • πŸ‘€ Users β€” people who use the product.

  • πŸ’Ό Business Stakeholders β€” people who want the product's success.

These categories are interested in radically different things, and communication should adjust accordingly.

They form a sort of pyramid that goes from the lowest, operational level, where the most interaction is needed (team members), to the highest, strategic one, where sparse and concise updates are enough (business).

Let's have a look at each category πŸ‘‡

🎽 Team Members

Team Members are those involved in product development. They include, for instance, Engineers, Designers and Product Managers.

These people need to stay in the loop of development activities, down to the details of what needs to be done.

Communication should be structured around some kind of production cycle (e.g. a weekly or bi-weekly sprint) where features are planned, developed and reviewed.

This is the lowest level of granularity for communication β€” as people need to coordinate every day about things to do.

πŸ‘€ Users

Users are those interested in using the product β€” they benefit from its value proposition.

Communication with them is about getting feedback on what has been developed and ideas on what to develop next.

How do you get feedback from users? Here are the two effective ways:

  • πŸ” Involve them in demos and reviews β€” have a few representative users participate in periodic meetings (e.g. Sprint Review if you do Scrum) where you present them new product features, and let them give you detailed feedback. Make sure you do this regularly, as a ceremony. Here is an example of how to run these sessions online.

  • πŸ€— Create a community around your product β€” build a dedicated Slack/Discord space for users of your product where they can suggest features, report bugs, and comment new releases. Several companies do this today β€” I particularly like the Obsidian approach, that puts community front and center on the product website πŸ‘‡

It is also crucial how you communicate such features in a way that is comprehensible. If you track your work on a development tool (e.g. Jira, Clubhouse) chances are tasks there have a lower granularity than what Users need to know.

Users are only interested in the headlines, not the implementation details or how you split the work with your teammates.

To keep communication clear and separate from what you do in the trenches, consider these approaches:

  • πŸ—ΊοΈ Setup a dedicated space for displaying your roadmap β€” this might be as simple as a Trello board, or something that allows for user interaction, like Canny. It should contain the high level items of what you are going to release, written in a way that is understandable by non-technical users.

  • πŸ“¬ Deliver periodic release notes β€” deliver release notes for each relevant update. You can do this via email, on a dedicated page, and even with notifications inside the product itself. There are several tools that help you with this, like ReleaseNotes, or Canny itself.

  • πŸ“£ Leverage the community β€” if you went for the community route, you can announce new features there in a dedicated channel. This is my favorite option β€” it gives you more feedback and keeps engagement high. Check out below another example from Obsidian itself.

πŸ’Ό Business Stakeholders

Business Stakeholders are mostly interested in the business outcome of product usage. They don't necessarily care about single features, but keep the pulse of high level KPIs.

To keep them updated properly, and make sure their expectations are met, you should get two things right:

  • 🎯 KPIs + Targets β€” make sure you have a definition of success everyone agrees with. This includes what metrics to track and what targets should be met.

  • ⏱️ Cadence to review KPIs β€” schedule periodic moments to review KPIs, get feedback and discuss the status of the project. A common mistake is to set goals and then let months pass without anyone knowing how things are going.

πŸ“š Resources

  • πŸ“‘ How To Design a Communication Architecture β€” this is a broader take I wrote about communication and responsibilities in a project. It makes use of the RACI matrix to understand the role of the various stakeholders.

  • πŸ“‘ How To Run a Sprint Review Online β€” by Barry Overeem. Barry articulates how to run a Sprint Review that includes feedback from real users, and how to do it online in a structured fashion. I loved this take as it takes the review very seriously (as it should) and builds a small workshop around it.

  • πŸ“‘ Skills Senior Engineers Need, Beyond Coding β€” by Camille Fournier. When Camille writes something it is often a source of inspiration, and this makes no exception. Check out this funny and insightful list.

  • πŸ”¨ ReleaseNotes.io β€” we started using this tool at Translated to communicate product releases to our Users. It is really flexible and easy to use β€” it allows to send emails, host a dedicated page, send updates on a Slack channel, and fire a popup inside the product itself.

  • πŸ”¨ Canny β€” it is an all-in-one tool to collect product feedback from users, organize it, build roadmaps, and deliver release notes. Highly recommended!

⭐ Weekly Featured Jobs

Here are the jobs featured this week!

Browse many more open roles (or add your own) on the full board πŸ‘‡

Check out all Refactoring Jobs


Hey, I am Luca πŸ‘‹ thank you for reading this far!

Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.

Subscribe below to receive a new essay every Thursday and put your own growth on autopilot!