One thing you need to make sure you do as a product manager is keep your stakeholders appraised of what is going on with your product. To make things interesting you most likely have to adjust what you communicate and how you communicate it for different stakeholders.
Sometimes those differences in communication are based on their support for your product.
Sometimes those differences in communication are based on their level of interest and influence on your product.
Sometimes you need to communicate information relevant to different horizons depending on who you’re communicating to.
There is no one best way, so I thought I’d take a look at some criteria to consider when selecting your communication mechanism.
I also wanted to share some communication techniques I’ve found helpful for different horizons, using the horizons described in the Agile Extension to the Business Analysis Body of Knowledge (BABOK) as a starting point.
Success criteria for reporting mechanisms
When I’m trying to decide how to communicate with stakeholders about a product I’m working on, there are a set of criteria that I consider when structuring that communication. You can think of these criteria as questions to ask when deciding if a candidate communication mechanism will work.
Does this tell stakeholders what they need to know? Yes, I know this seems like a no brainer. Stick with me for a second. When someone asks for an update about your product, find out why they are asking and what they plan to do with that information.
Depending on your relationship with the requester, you can be extremely upfront with your question, or you may need to ask in a more subtle manner.
You want to know why they want the information and what they intend to do with it so you can provide them the right information structured in the right way. You may be able to identify a need for different information than they originally asked for.
You may identify someone who is opposed or hostile to your product that you hadn’t identified before. Of course people don’t usually come right out and say “I’m looking for this information so I can ruin your product!” but you may be able to read between the lines in their response.
I hope your organization isn’t one where that last case happens, but then again I’ve been enough organizations where it did happen to be cautiously pessimistic. Trust first – but verify – is probably a good way to operate.
Can stakeholders access this information when they need it without bothering someone? You want to find ways to keep people up to date that does not rely on you pushing them information all the time. It’s much better if they can access reasonably up to date information when they need it.
Yes, I know. You will still have people who are “too busy” to go look at an update you keep updated and expect to have it sent to them.
The key here is to have the information readily available for your stakeholders to look at it if they so choose so that you are being transparent. If they choose not to go look, you can take the opportunity when you’re sending it to them that it’s available for their perusal when they like.
Keep in mind that if you’re going to change behavior of your stakeholders, you can’t make it difficult on them. Asking them to go five layers deep in Jira is probably not a recipe to get a director in a business unit to go pull information.
Put your information somewhere that’s accessible and make sure it’s presented in a way that makes sense to them. That’s why you asked them what they wanted to do with the information, remember?
Does this add any work to the team? Ideally you want to provide information to your stakeholders without requiring any additional work from your team that they don’t find useful for some other purpose.
It’s easy to get unduly infatuated with work tracking software, but this is one place where it can come in handy. A word of warning here – most work tracking software was built to support project based thinking and so tends to report output based metrics. You may need to tweak some things to convey information that’s outcome based. The techniques I describe below all do that to some degree and can be accomplished with little extra work – although you may need to create some initial automation.
Is this useful for the team as well as stakeholders? I’d like to think that the information your stakeholders ask for is also valuable to your team so that they have incentive to do any work necessary to collect it (unless you are able to avoid work altogether per the last question).
There may be some metrics your stakeholders request that does not seem to have value for you or your team. That’s usually a signal that you need to dig deeper to understand why your stakeholder asked for the metric.
With that criteria in mind, here are some techniques I’ve found helpful for keeping stakeholders updated for three different horizons.
Strategy horizon progress
The strategy horizon is where you consider the needs of your customers in relation to your organization’s strategy to determine what initiatives you do and do not do.
The information you want to provide in this horizon is what outcomes you’re working on now, what outcomes you’re going to work on next, the outcomes you may get to later, and the outcomes you’re not going to work on.
A good tool for this is the product roadmap with an outcome rather than feature focus.
This picture is a representation of a roadmap I started putting together for Agile Alliance to report work on the website for quarterly board meetings. The roadmap shows specific outcomes we’re trying to deliver, often expressed in terms of an outcome based metric such as “increase the number of new membership and membership renewals per month by 10%”.
The Now column indicates the outcomes we’re focusing on at the moment.
The Next column indicates the outcomes we think we’ll tackle in the near future. There’s a bit of uncertainty surrounding which of these items we’ll move to the Now column next, and it’s possible we won’t do some of them if conditions change.
The Later column indicates the outcomes we’ve identified we think might be worth tackling at some point. There’s a great deal of uncertainty about these items and it’s likely there will be a lot of changes in this column. Still, it’s good to indicate options.
The Never column is a handy place to show the things we’re not going to work on at all. Sometimes it can be handy to explicitly state what is out of scope.
The color coding identifies which of Agile Alliance’s value dials the outcome aligns with. Agile Alliance expresses it’s strategy in terms of value dials:
- Deliver value to members
- Build an inclusive global community
- Advance the breadth and depth of agile
- Build Agile Alliance brand awareness
These are the key decision filters that Agile Alliance uses to decide whether to undertake activities or not. When we consider some action that’s fairly significant we run it through these decision filters (ie “Will this help us deliver value to members?) if it does not pass through any of the decision filters, we won’t do it.
Overall, this roadmap provides a good overview of what outcomes your organization is focusing on right now, and gives you some insight into what problems you may want to tackle next.
Expressing the items on the roadmap as outcomes rather than features helps to prevent output based thinking and allows you to focus on what problems you want to solve next.
Your stakeholders are more than likely going to want to know more specifics, so you can then go to ways to show progress for a given initiative that’s tackling a specific outcome. I describe to different ways to communicate progress for an initiative in the next section.
Initiative horizon progress
The initiative horizon focuses on how your team selects the solution to satisfy a need and whether it’s worth proceeding once you select that solution.
The best way to track and communicate progress of your initiative is to show the change in the outcome based metric you’re trying to influence. This of course assumes that you’re starting with an outcome based metric in the first place.
Once you’ve established the metric you’re targeting keep track of the actual value of that metric when you started your effort (that should be the baseline shown in the example above) and then note the new value of your metric after any significant delivery you make in an attempt to influence that metric.
Here’s a simple way to track the change in the metric. The key is to note what change you made and the resulting value of metric. You may also find it helpful to note what you decided to do as a result.
New and renewed memberships/month
| Action | Value | Notes |
| Baseline | 250 | |
| Three months of curated emails featuring member only content | 261 | Discussions with members indicated they appreciated finding out about resources they weren’t aware of before. |
| Revised website layout to stress what how Agile Alliance serves members and provide stories from current members (Social proof) | 310 | Feedback from members indicated they appreciated having a clear idea of all the services Agile Alliance provided |
If you’re looking for a more formalized way to guide your work based on moving a metric, take a look at Melissa Perri’s description of the product kata.
If you’re working on a large initiative where it’s difficult to get rapid feedback on your target outcome, or you do not have a firm outcome based metric, you may find the parking lot diagram helpful to communicate progress to your stakeholders.
While the parking lot diagram is not strictly outcome based, it does convey what aspects of your product you are working on that bear some tie to the outcome you’re trying to reach. It provides some context to what your team has built compared to a burn up or burn down chart which just shows some measure of output without identifying which outputs they were.
These two views of the overall initiative may be sufficient for most stakeholders, but you may have some who want to know specifics. Keeping my criteria for good communication mechanisms in mind, I’d recommend introducing those stakeholders to the boards your team uses to track it’s day to day work, which I describe in the next section.
Delivery horizon progress
The delivery horizon focuses on the specific things your team does to build and deliver a specific solution.
The best way to communicate the discrete things your team is working on right now and will be working on soon to satisfy a specific outcome is to make whatever they use to track work accessible.
The mechanisms I generally like to use for that are the discovery board and delivery board.
The discovery board is a way to graphically represent your backlog refinement process.
It shows how your product backlog items are progressing toward getting ready. It provides a clear layout of the process you use to get stories ready and it gives people a view of what’s most likely going to be built next.
The delivery board shows what your team is currently working on so they can see what is already done and ready to look at and what things are still in progress.
The nice things about both of these boards is that the team is hopefully already using them, so there’s no extra work necessary to make them available to stakeholders outside the team who are interested. Especially if you’re keeping the boards updated in a tool. I’ve created discovery and delivery boards in Jira with considerable success. Let me know if you’re interested in getting more information about how I created a discovery board in Jira.
How do you communicate with your stakeholders?
When you need to communicate status with stakeholders, make sure you understand what they’d like to use the information for and what level of detail they need. Then, pick the appropriate means of communicating that information for the context you’re in.
I’ve shared some of the techniques I use, but would be curious to hear what you do. Share your experiences in the comments.