Template for tracking adoption of platform feature

Platform teams release features that should be adopted by feature teams and it's important to track the adoption

This might be a duty for a Product Manager. And maybe it is. Nevertheless, sometimes we have to track the adoption of a feature that we, as a Platform Team, delivered and should be adopted by a set of Feature Teams. You, as the owner of the initiative that should be covered across multiple Feature Teams, need to ensure success. This template can help you on this journey.

After trying several alternatives I’ve ended up with the one I use nowadays and, in today’s issue, I want to share it with you.

Screenshot of the template

Let me explain to you what each chapter means and how I use it successfully.

Summary

Nothing crazy. Just a concise summary of why a Feature Team ended up on this document. Important to indicate the expected outcome; usually, the adoption of the feature.

What needs to be done

Here it’s important that the Feature Team could understand “what” they will have to do, with links to technical documentation about how to adopt the feature (important: with examples).

Tracking

This section is the one that most usage will have once you kick off the initiative. Here the Feature Teams will have to fill in the table accordingly. Depending of the maturity of the company, you, as owner of the whole initiative, might have to fill it too.

The section starts with 2 legends.

• Status for the “issue analyzed?” column. With values YES, NO, and WIP. I go into details about the column later.

• Status column. With values ON TRACK, AT RISK, and BLOCKED, the Feature Teams will be able to indicate their current status.

Now, let’s jump into the description for each of the columns.

• Team. The Feature Team name. Straightforward.

• Tech Lead. The name of the Tech Lead (of Feature Owner) that will be accountable for the work to be done for that team.

• Issue Analyzed? This column will give you the vision about if each Feature Team already took a look at the page and if they are investigating the impact on their side.

• Status. Already mentioned the possible values above. For this column, my recommendation is that you put the status AT RISK if there are some unsolved uncertainties from the Feature Team side and, if so, add (in the column Action to Take) the task/s to dilute the uncertainty.

• Action to take? The list of tasks, links to Jira, etc for either the work to do, to resolve the uncertainties, or to unblock the work.

• Sprint/Release. Whether your company uses an Agile framework or not, you want to know when the Feature Team will have the work done on their side. It should be indicated here.

• Blockers. This is important because here there should be the blockers that the Feature Team has, so they are visible and can be tackled. If so, some magic questions to move forward are

  • “Who is the owner of <blocker-X>?“

  • “what <feature-team> team needs to unblock this?“

  • And my favorite “By when <feature-team> team will tackle the next step to unblock this?“

• Notes. Anything you or the Featute Teams might find relevant.

PRO-TIP: I would suggest keeping a weekly (or bi-weekly) meeting to follow up on the progress, especially if your team or company is not used to working asynchronously. As the owner of the change, it's your responsibility to ensure that the work progresses accordingly.

That’s it for today’s issue! I would love to hear your feedback on this template. How has your experience been using it? Your feedback is invaluable to me and will contribute to continuously enhancing this newsletter. Please share your thoughts and experiences with me!

Best,
Marcos.