As a product manager, you’ll probably need to write some form of status report.
In larger companies, the format may be provided to you – whereas in smaller companies you may have to create something.
To ensure a product status report is valuable to the reader, you can ask a couple of questions:
- Who is the status report for?
- What are they looking to see in it?
Broadly, the answer is likely to be that your stakeholders want to see it, and they want to find out when the things that matter to them will be available in the product.
However, it’s still worth asking the question. Otherwise, you may be diligently writing updates that nobody reads.
Why is a product status report needed?
Ideally, regular updates wouldn’t be needed. Stakeholders could look at your project management tool or issue tracker, and see what’s going on there.
However, this can be too detailed. The tracker often includes lots of component parts of stories – and not a bird’s eye view.
How often should you write a product status report?
Establishing a regular pattern gives predictability, so is a good place to start. This could be aligned with your sprints, or could be every 1-2 weeks.
It’s important that the reports are regular enough so stakeholders aren’t left wondering what’s going on – but not so frequent that you have little to report, or you end up getting very detailed.
What should you include?
The simplest form of status report is to share which tickets have been completed since the last update. However, this rarely adds value without context, and is a good reason why status reports do not get looked at.
It’s also better to include things of substance – and less of the “our team is working hard”. Which is nice and all that, but doesn’t tell you much.
Things to include:
- Key metrics: Headline stats that matter to your product. Daily active users, new signups, revenue. It’s important to understand which metrics are important – not all metrics matter to every product.
- OKRs: A reminder of your objectives along with any changes to these, and progress against key results.
- Research and experiments: Recent discovery work, any outcomes, and how you might act on this in your product. Data is key.
- Product development: Any notable additions or changes to the product – they can be any size, but should be impactful, and backed up by data from recent experiments. For instance, we streamlined the signup journey to reduce drop-offs at the 2nd stage. We’ll monitor this for 2-4 weeks to gather real data and see if this change leads to the outcome we hope for.
- Progress against larger initiatives: If there are big projects going on, giving updates on these can be helpful – e.g. we are 25% of the way through the build phase of supporting a new type of customer. Again, backed up with metrics – we did outreach with 100 people with 25% conversion, suggesting this could be a valuable niche that we’ve not tapped into.
It’s not all about features
You don’t need to release lots of new features every week. It’s far better to release 1 or 2 of the right features than 5 or 6 just to show progress.
You can also make good progress with small quality of life changes, such as usability tweaks.
Watch your metrics, and look for areas to focus on next. It’s better to look for weaknesses or opportunities in your product, than wait for stakeholders to ask for the next item on their wishlist.
Photo by No Revisions on Unsplash
