I spent 3.5hrs writing the 1st draft of the Product Operations Playbook for my team. I have mixed emotions because I'd rather teams collaborate vs. writing detailed instructions on how to work. I've been rethinking this. So why now?
It's pretty simple - when what gets built isn't what the PMs wanted, there's too much stress, frustration, and lost time. Should we ship and make concessions? Do we need to add more work before we ship? How did this happen? Wasn't it obvious?
My honest reflection is that my team has a lot of control over this. And the path to taking more control is through more structured Product Operations. 3 things I've been rethinking:
1. Process vs. judgment: The best work happens when people have autonomy. This means giving space to show judgment. Adding process where judgment should be enough feels like it limits autonomy. But, in teams where people have varying skills and experience. they need more structure. The structure should provide guidance so teams can still make judgement calls.
2. Repeatability: I'm pushing more decision-making and ownership to various teams. For teams with fewer repetitions, it's easy to get lost in 'how'. The Product Ops Playbook should provide the right guidance and guardrails to make it smooth to get work done. This should also create more autonomy, not erode it.
3. Reducing ambiguity: "Obvious to me isn't obvious." This applies everywhere in life, including Product. My ops approach sets higher standards for capturing and communicating requirements, with detailed acceptance criteria, clear definitions of done, checklists for readiness, and outlines of tools and frameworks. The more I can reduce ambiguity, the better and faster we can ship, with fewer misses.
I believe adding too much process ends up treating people like an assembly line. I've been putting off writing the playbook because of that fear. In my reflection, I've let a lot of risk come into our work by avoiding it. Now I see more upside.