An Operating Framework for Platform PMs

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:

(these representative states by no means reflect the state that my current employer is in)

• [60% Effort] Foundations & Initiatives: defines quarterly “OKRs” (Objective Key Results – a team performance grading convention derived by Google) – composed of multiple projects that achieves a team’s overall narrative and strategy. Each is owned by specific sub-teams within the same team I call "Tribes";​​

​​

1. Foundations*: project areas that help overall developer efficiency and enhances the existing technology stack. E.G.: moving servers to VMs, migrating from gradle → buck build system, et al..
2. Initiatives: larger “Big Rock” focus area projects requiring quarter-long, multi-sprint execution. E.G.: adding dependency injections, modularization of the codebase, et al..

 

• [20% Effort] KTLO* (Keep-the-Lights-On): existing tools and infra that enables the particular application to keep running. This is often supported by what’s called an “On-call Engineer” – one who drops all project duties and is dedicated to KTLO items for a duration of time. This is owned by everyone on the team. E.G.: release management, fixing broken pipelines (outages needing hotfixes), et al..

 

• [20% Effort] One-offs**: unplanned support or features requests coming from customers. This is owned by everyone on the team. E.G.: one-off bugs consistently breaking build compiles, speeding up compile time etc.

*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 hi@danielcliem.com or @dcliem. Subscribe to my newsletter below!

Read Next