Okr for product management

One of the challenges when defining Roadmaps for product development is that they are normally output-based instead of outcome-based([[literature/@cagan2018|@cagan2018]]). This means that product development teams have no way of understanding how to prioritize tasks and will often do it based on internal preferences instead of aligning with the overall business.

Implementing OKR for Product Management is a way of overcoming some of the problems. It is the role of leadership (and management overall) to define what are the business objectives that must be tackled, and let the product people decide what is the best course of action in that context.

Sometimes there are layers of strategy that are hard to convey across the organization. For example, sales can't ramp up if onboarding is too long. A clear objective is to lower the onboarding time, but its implementation is left to the product team to iron out.

A challenge of implementing OKR in a product-led company is that the original inception took into account a highly pyramidal structure. The company establishes some objectives and that trickles down to the individuals, via their managers, etc.

In product organizations, however, there may be a functional team (designers, engineers, quality control, etc.) and a product team (lead by a product manager, etc.)

Part of the product strategy can be regarded as part of an OKR system. However, individuals will struggle separating what belongs to the functional team and what to the product team. An objective of a functional team can be related to their specific role (moving from one vendor to another, digitizing a database, etc.) but that has nothing to do with the product itself and its objectives.

Therefore, product teams should trump over functional teams when defining their OKRs. Those, in the end, are the objectives that should count the most for the organization.