How to update internal stakeholders on a weekly basis

Its a typical hot, dry Christmas weekend in Sydney, Australia. What better time to write a blog post about product management?  This topic has been bugging me for a while. So thought I’d write this to you whilst in my (too) cold air-conditioned living room.

A common question I get asked is how do I update people in my organisation on a product I’m working on. I’ve been asked 3 times in the past 3 weeks, so obviously there’s something here that others want to know. I get asked by:

* Founders / CXO’s wanting to know how to get their teams to report to them

* Product managers on how to report up to management or other stakeholders in their org.

I’ll discuss why we provide updates, principles, cadence and a template that you can use. This is a format I’ve been using for the past 5 months. I would like to detail how I do it and hopefully it can provide you some insights that can help you!

Why give updates?

I give updates to show the following:

* How we are tracking towards our goals

* Summary of problems / wins that stakeholders need to be aware of

Reporting is useful where other teams are relying on you and management can see your progress. In addition, we want to be pro-active rather than reactive. When I first started as a product manager, often stakeholders wanted to know what was happening. By reporting on a regular basis, we’re on the front foot and highlighting issues in advance. I really like this weekly format which Im going to share with you.

Principles

I want to highlight some general principles that I use in my report:

1. Goals over activity: In the past, I summarised all the activity that was going on. This is not useful information to stakeholders. They can see that you are busy and it takes time to parse. What they care about is how you are progressing towards your goals.

2. Focus on 1 – 3 key goals: Personally, I like to focus on 1 OKR (Objective & Key Result) and report on that. The objective is your goal and key result is your metric. Focus young padawan! What you have 3 goals or 5 goals, which one do you focus on? Sometimes these are competing as well. I’ll show you how to report on your goals.

3. Converting knowledge into wisdom

You really have to think about who the audience is which in my case would be management (head of mobile, head of product, management team of mobile, other mobile teams, heads of other products). Similar to the above, we want to turn all the knowledge/activity that we have into useful insights to these stakeholders. They don’t have time to parse through everything that is going on. What key takeaways do we have? We want to show what we have learnt.

4. Be concise & crisp

One of the hardest things I have learnt is to be concise. Get to the point. If you have any additional info, you can link out to it so they can read it. I use bullet points and condense it down to 1 line (or 2 max).

5. Report on what’s changed

If I’m a stakeholder, my general assumption is that things are on track. You don’t need to tell me that we’re on track. It doesn’t add any value. It is the delta that I am interested in. I want to know these type of things:

• If a delivery date has changed and been pushed out
• We’re off course with a key result
• There’s a blocker

6. Provide dates

If its less than 3 months out, I provide a specific date. It doesn’t matter that its not 100% accurate, I’m giving an indication when it will roughly land. Since I’m updating it weekly, I can adjust it as new information comes out. If its greater than 3 months out, I’ll provide a month when it will drop.

Cadence

The cadence I previously used was every two weeks. A few months ago we switched to a weekly basis. I like the weekly reporting cadence because it ensures I check my key metrics on a weekly basis at a minimum.

Once you know the format and general principles, it becomes easy to update. It does take a while to get into the weekly cadence and how to do it efficiently. But I’ve come to like it as it keeps me accountable and I can raise issues on a timely basis if needed.

Format

The 1 page format I’ve been using is detailed below.

1. Summary: High level points that stakeholders need to know about. This may be the only part that they read.

2. Metrics: I report on 1 OKR. It shows the key result we are targeting, the weekly metric and the % change week on week.

3. Delivered: What has been delivered in the past week.

4. In progress: What we are working on.

5. Coming off the backlog: Things we are planning to do in the next 2 weeks to 2 months. Stakeholders can provide feedback on these items e.g. they have a different priority.

Here is the 1 page template I have created in google drive. You can find it here. I had to screenshot it as 2 images below.

Multiple teams reporting

You could have each team do this report. Another method is to get all the streams to condense it down to 1 report. This is what we have been doing in our teams. So each team or stream adds a subheading within each section. Its a rollup of the streams that are related.

Last words

So this concludes how I report weekly to stakeholders. I would like to give credit to my current and former managers, Joff Redfern and Jonathan Zazove for introducing this reporting format and helping me become a world class product manager.

I hope this helps you in your journey. Feel free to copy the template and make it your own!

I’m out like the bitcoin price drop,

Matt Ho