TL;DR: building and adopting a trusted model for prioritizing work is critical to the organization, focus and ultimately success of a platform team.
I’m a Platform Product Manager on Mobile, and we recently jammed around how to optimize efficiency of our workload. There are many ways to tackle this: the 10:20:70 rule, the 50:50 rule, et al. I like, and have proven to find most useful, the 60:20:20 rule:
*Foundations → KTLO: You can think of Foundations as opportunities to help reduce KTLO load. Foundational projects upheaves many of the menial manual labor induced by supporting toolings that requires 24/7 up-time.
**KTLO vs. One-off: Often times, these are misused; one-offs are usually toolings or infras that require continual support and constitute KTLO-ing. Others you can reason out pushing off as they are distractions and don’t align with team goals. The danger of mixing up here is a de-prioritization (as exemplified in the image) that consequently severs the progression of the team strategy, which relies on Foundations & Initiatives.
• • •
Platform teams are not only innovators of next generation technologies and tech stacks often demoed at dev conferences and such – they’re also the gatekeepers for your application(s) and codebase. Their operating mode is often initially trapped in a scenario that looks like the left-hand breakdown image above (FYI: example not representative of my team at Dropbox today whatsoever). However, you want to move into a world that looks like the right-hand.
Why this is important is because if teams aren’t trained to have the mindset and muscle memory of prioritizing their work evenly, they will be faced with the challenge of forgoing major project ownerships and long-term, missing strategic objectives. You can avoid this by means of a very principled approach to prioritization - a habit that requires meticulous iterations and constant engineering feedback.
Of course, there are many ways to approach this problem with different kinds frameworks. It may even apply to non-platform teams faced with hundreds of daunting support or feature requests daily. I suggest trial and error-ing with your engineers and retrospecting thereafter on a quarterly basis, in order to find the model that strikes the right balance for your team.
FYI: this is the first of many posts I plan to make! As part of a personal brand refresh, I’m working on this new personalized blog, and will share (hopefully) useful insights around a) product management tips that are practical or applicable to case scenarios, b) product insight/ideas or commentary on favorite applications, or c) miscellaneous banter on other things tech-focused, including venture capital.
If you find this helpful, or are simply down for coffee, ping me at firstname.lastname@example.org or @dcliem. Subscribe to my newsletter below!