Marty Cagan’s SVPG has a good series on team objectives covering a broad range of topics related to product team goal-setting and execution.

As we work on implementing an OKR model internally, I’ve been thinking about how to understand the literature you read out there about various companies and their successes or failures with the framework. In my reading, I like the concept of OKRs for two primary reasons:

• Clarity & transparency across the entire team, with intertwined, connected goals and targets
• Using them as a forcing function to think about the road ahead to, most importantly, explicitly define the things you won’t focus on

This bit stuck out in the overview post:

It’s no secret that most of the leading tech product companies use the OKR technique, or one of the variants. And it’s also no secret how much success these companies have had.

Yet people are confusing correlation with causation.

Those successful companies aren’t successful because they use OKR’s. They use OKR’s because it is designed to leverage the empowered product team model.

Seems obvious that a system and set of acronyms doesn’t guarantee success, but it’s easy to gloss over that the real hard work is being thoughtful and explicit about your plans and focuses. An empowered team is a stronger one, able to get their hands around problems and define their own path.

I’m currently in the middle of The Phoenix Project, a novel about an IT department rebuilding their organization in response to business crisis (I know, it sounds weird, but it’s actually an excellent book). One of the best bits so far is the concept of “hidden work” that the characters have to overcome. Without proper transparency and commitment, hidden work runs amok. People asking for “quick favors” across teams, boring tasks, technical debt. There are plenty of these sorts of things in any company — sometimes important, sometimes not so much, and occasionally unavoidable — but if we can reduce, or at least expose the hidden work, we can something about it. It’s like churn in a SaaS business: a hole in the bucket draining out what you’re putting in. Only in most product development work, it’s often invisible.