This week, I'm monitoring the product roadmap closely
What does monitoring the product roadmap entail?
You’ve created a version of the roadmap for the first half of 2021 — an outline of the main initiatives that product and engineering will be working on. Cross functional meetings, customer feedback, scoping and estimation exercises have led to this point. Press play, and update your organization as key deadlines approach and things are ready to release on schedule!
Not exactly.
Some items on the roadmap may release on time. But it is common for releases to become delayed and priorities to shift. Below I have outlined example questions that have been discussed with my team recently as we monitor the product roadmap.
Based on our sprint velocity, how are we tracking?
Jira has a ton of reporting options to help teams stay on track. While Engineering is accountable for say:do ratios and having a good handle on what the team’s real velocity is, the process of evaluating if our releases are on track is a collaborative one. If the Q1 roadmap assumes 400 points being completed, and at the halfway mark of the quarter the team has completed 100, that likely means that work is behind schedule. Whether things are on track or not, it is on Product to communicate that out to stakeholders at the right time. If adjustments need to be made, there are certain strategies like the below that can ensue.
Is this particular feature still a high priority, or can it wait?
All things in life are subject to change, and product development is no different. For instance, when COVID-19 started, new priorities were introduced so roadmaps shifted. In an Agile team, that is to be expected. But even in normal times, what was a major pain point for internal stakeholders or customers at the start of Q4 might no longer the case in the middle of Q1 of the new year. Conversations with other departments can be helpful in revealing these things.
Let’s say you manage two product lines: A & B. If Product A, a newer product, is experiencing strong conversion and engagement metrics, maybe a short-term release to improve the feature is not totally necessary (product vision and company strategy will definitely influence this type of decision-making). Instead, it might make more sense to move a highly requested add-on feature to Product B up in the roadmap (perhaps CS is saying they are hearing requests about it left and right). These are common conversations on product teams and, again, changes to the roadmap are fine — as long as they are accompanied by sound logic and proper communication across departments.
Can we reduce a feature’s v1 scope and still hit a KPI?
If priorities are super clear and not much can really change on the roadmap, changing a feature’s scope is a possible course of action. One way to think through large projects and define what needs to be released and when is with a basic methodology like the below. It is especially helpful when building with an MVP approach. I’ve used this type of matrix in my role, where release versions are on the left and epics (which are split into smaller user stories) are at the top:
At the start of a project, core priorities are mapped out across epics (in this simplified example: Setup, Logic, and Notifications). The image illustrates what might happen if unexpected complexity during v1 development occurs, and coding C—>D logic is going to take more time than anticipated. If it’s not a necessity for v1 launch and we can reach our KPI goal (i.e. $1M in ARR) without it, then let’s push it to v2 and release it another time.
There is a lot that goes into crafting, monitoring, updating and communicating the product roadmap, but I hope this is a helpful walkthrough of how I’ve interacted with mine recently!
This post has been published on www.productschool.com communities.
