Laurent Gibert

See question: “What are good OKRs for product management?” for a general introduction to the topic. To achieve high level of critical thinking, and remove many biases, it is particularly important to adopt strict scientific methodologies. Observe, formulate questions, make hypotheses, experiment and analyse data, formulates and communicate conclusions, and finally iterate. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs.

See question: “What are good OKRs for product management?” for a general introduction to the topic. I think the metric cost falls naturally into making a solid business case. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs. Now if the cost of implementing or tracking a metric is unusually high, this might result in wasting efforts, and losing stakeholders confidence. See question “What are some of the worst KPIs for Product Managers to commit to achieving?” for thoughts on “The (nearly) impossible to update number” pattern.

To build up the best Objectives and Key Results, I usually ask the Product teams to follow a yearly schedule of strategic planning (aligned on fiscal year, ideally also aligned on performance review cycles). This is aligned on the basic scientific methodology. Q1 define business hypotheses (observation, question, hypothesis) This exercise starts with refreshing our predictions about the long term state of the market based on ongoing trends. We then look at how to fund in the medium term our path to successfully get to the long term target. We do this by going over the categories of customer acquisition, retention, share of wallet, market shares, customer costs, customer success, customer satisfaction, brand value, and express targeted business hypotheses. This could be revenue, user behaviours, competition numbers, specific required features for the engine to serve evolving needs… Q1-Q2 validate/invalidate business hypotheses (experimentation, data collection, analysis) We spend the next phase of the fiscal year diving deeper in market research and data collection/analysis to try to validate or invalidate our business hypotheses. As we increase our confidence in identifying precise problems worth solving, we put together business cases to pitch strategic investment adjustments to senior leadership. Q3 define strategic initiatives (conclusions and communications) Going into this phase we start gathering support across senior leadership for the various business cases we built, find sponsors, and pitch those in the context of defining strategic initiatives for the next execution cycle. Those business case contain a clear set of success criteria in the form of metrics that meaningfully illustrate achieving the business outcomes of the business case. (See literature on outcomes vs outputs). Q4 adjust organizations for execution Once strategic planning is complete and senior leadership is aligned on those initiatives and their investment priorities, they usually design changes to the organization to set us up for successful execution. The Product Management team would at that point draft OKRs and start reviewing those with the updated leadership team. Those OKRs are most of the time Objectives representing the desired goal for the business outcomes described in the business case, and the Key Results are chosen for their ability to be realistic to collect and meaningfully represent progress. Rinse and repeat (iterations) At this point the organization is setup to execute with clear priorities and goals and Product Management can restart the cycle! See question: “What are good OKRs for product management?” for guidance on shaping good OKRs.

See question: “What are good OKRs for product management?” for a general introduction to the topic. Specifically when it comes to high level of uncertainty, it becomes particularly important to adopt strict scientific methodologies. Observe, formulate questions, make hypotheses, experiment and analyze data, formulates and communicate conclusions, and finally iterate. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs.

Since the question suggests “achievements”, I assume we want to reason about Key Results and not KPIs. See question: “What are good OKRs for product management?” for a general introduction to the topic. Good Key Results are often hard to come by, and we often fall into the trap of bad Key Results. Here are the common trouble maker patterns. The binary metric: Deliver [feature] by [date]. This metric is useless to understand progress since it often is 0% for the entirety of the execution, and becomes 100% usually at the last minute towards the target date. You can workaround the problem by finding a relatively predictable breakdown of the feature in phases or sub-deliveries of ideally equal sizes. Then each phase completed can be represented as a percentage update towards the completion. Opinion-based metric: Reach market-fit by [date]. This usually will look like a percentage that depends on a leader’s best guess of the progress towards a perceived state. Very bad situation since there is no way to realistically challenge that perception. This defeats the purpose of a Key Result in its role to raise a flag when execution goes off the rail. It also disempowers teams and can lead to dramatic disengagement or misalignment. A workaround is to find a proxy metric that indirectly represents progress towards the target. In the example above it could be an NPS (Net Promoter Score) score or a measurable customer segment adoption progress. Vanity metric: Reach [X] monthly active users by [date]. A vanity metric is usually a number that visibly goes up or down but does not correlate to meaningful business outcomes. This is often what happens when KPI (lagging metrics) are confused with KR (leading metric). The example above might be correct if the turn-around time during an execution period is so short we can immediately observe a market result at each reporting milestones (think a marketing campaign with immediate observable results). But often what would happen is that the KPI we look at represents results from actions taken several execution periods in the past (think delivering a feature in Q1 that impacts numbers in Q3). In that situation, the KR does not help track progress, might not even be directly correlate-able to specific actions, and the execution team might already be committed to new goals by the time you observe a need for corrective action. There is no workaround, such metric is not a useful Key Result. This said it could instead by useful as an input to strategic planning (macro market trends and intelligence). The (nearly) impossible to update number: Customers save [amount] by using [product feature]. Of course, this example might work in your case, it’s hard to find an absolute example that would work for all product context. But by choosing this example I wanted to point at the usual challenge of choosing a data point we cannot observe directly, and for which the collection of the data requires a third party contribution, or a significant effort like deep market research. In that situation we often observe that we get an update very early on as we’re committed to the OKR, and progressively as time go on, we encounter many good and bad excuses to miss to update the OKR. At that point, leadership and stakeholders will lose interest in the OKRs update and will request new data points that will force you to abandon the initial KR you wanted to track. Too much OKRs: "We're so data-driven we have more Key Results than employees!" One last important rule to remember: keep the number of OKRs under control! Too much data points will muddy the reporting, and waste data collection resources without significantly improve execution. OKRs should be chosen by how meaningful they are to represent progress towards the business outcomes you have described in your approved business case. A good rule of thumbs is 3 Objectives max for an organization, 2-3 Key Results per objective. It is ok and useful to create cascading OKRs depending on the size of the organization. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs.

See question: “What are good OKRs for product management?” for a general introduction to the topic. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs. As part of this process, the fourth phase is about aligning organizations for execution excellence. At this point you should have alignment at senior leadership level on strategic priorities and related investments, plus an associated set of business outcomes to reach. This is then the right time to have an honest conversation with marketing leaders on go to market strengths and weaknesses. Perform a retrospective with the entire team, and try to identify the execution patterns that might get in the way of reaching the business outcomes, or represent a significant risk to go to market. Propose chosen numbers to marketing leadership that seem to represent a good illustration of goals to reach in terms of go to market efficiency, and then negotiate! This will be similar to sharing OKRs with other groups such as Engineering, Sales, Program Management, Quality…

See question: “What are good OKRs for product management?” for a general introduction to the topic. Being more data-driven is about the entire strategic planning methodology. It could feel natural to start with having execution KPI or KR, but those will only be good if you came up with those metrics in a scientific way. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs. To change the organization, you need to look into change management literature. This is a vast topic that wouldn’t fit in this AMA, but here is a framework I used successfully many times: the DICE scoring from the Boston Consulting Group. This puts emphasis on several key necessary elements of successful transformation: 1. Implementation iterations and milestones (shorter = better) 2. Available skills to embrace the change (training) 3. Commitment of senior leadership (classic area of failure: politics) 4. Account for additional efforts (changing efforts requires reducing usual workload)

This is the best question to start with! Objectives and Key Results are often praised because of the stakeholders’ expectation of clarity, alignment, and clear/standard reporting. OKRs are often hated by teams because of being badly defined, in a way that misrepresent success or progress, and get costly to update with little meaning. Before going into details it’s important to note that there is often confusion between Key Results (KR in OKR) and Key Performance Indicators (KPI). While both are meant to be a single meaningful number, KR express progress towards an objective, KPI express a behaviour of the business or market that might not be related to an objective (yet!). As such a KR is often a leading metric (progress toward a future state), KPI is often a lagging metric (observing the result of various past dynamics). For OKRs, Objectives are usually easy to come by, but the core of OKRs’ success are good Key Results. The best Key Results have those characteristics: * Concise to communicate succinctly and efficiently horizontally and vertically, * Reflect incremental progress (ideally evolves linearly from starting point to finish line), * Are leading metrics (can be updated as we progress towards the goal), * Meaningfully targets a successful milestones towards the Objective. Here are a few examples of Key Results I have been using in the past: * Example about fixing a situation expressed as a percentage from current number to future number: Bring quality issue resolution turn around time to matches [product] median [at target number] by [date] * Example about ensuring consistency expressed as a percentage of total delivery over the period: Deliver [product] roadmap updates to the community [at frequency] during [period] * Example about a single delivery broken down in somewhat equal phases or deliverable: Deliver sales enablement material for [product] for each [identified categories] by [date]. * Example of an exceptional case when a KPI has a lifecycle so short it can be used as a Key Result: Turn community sentiment towards [product] from [baseline] to [target] by [date]. See question “What are some of the worst KPIs for Product Managers to commit to achieving?” for patterns to avoid. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs.

See question: “What are good OKRs for product management?” for a general introduction to the topic. This questions highly depends on the context of the market, and the product we are talking about. I would refrain from making a general statement that would likely be inaccurate for your context, and instead highly recommend to execute a solid scientific methodology to come up with the new numbers you want to track as you pivot your product portfolio. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs.

See question: “What are good OKRs for product management?” for a general introduction to the topic. The Product Management responsibilities vary from one company to another, and from market segments to market segments. So my answer will be very biased to my experience in the interactive content tech industry. I usually require from my teams that they do not take on the role of Product Owners, but instead behave as the ultimate Product Owners. In the agile methodology, the Product Owner role is responsible for describing the tasks to execute in a sprint, ensure the backlog priorities are aligned to the strategic product goals. When the Product Managers are assigned to this role they usually prioritize team execution above strategic planning and market research, resulting in those two activities to be neglected. However, the Product Manager is accountable for proactively verifying the Product Owners are able to achieve those tasks, and the Product Manager might need to adjust their activities to focus on execution from time to time to help correct the situation when the Product Owners struggle to stay aligned to the organization goals. That’s what I mean by the “behaving as the ultimate Product Owners”. As such I usually make Product Managers accountable for the wider Product organization OKRs. This doesn’t mean they are responsible for driving the actions or collecting updates, but are accountable: they report on OKRs progress, interpret the state of the progress in the context of the product and the market, and proactively engage with roles responsible for each OKRs when progress falls behind. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs.