Reflections

Outcome Focus

“'Focus on outcomes not on the process” sounds like management wisdom, but it overlooks a more nuanced reality:

1. Single outcomes are always based on luck to a certain degree (somewhere between 0,01% and 99,99%).
   
2. Good processes can lead to both good or bad outcomes in any given circumstance.
   
3. Good outcomes can be based on good processes + bad luck or on bad processes + luck.
   
4. Over time, the only predictor of a continuity of good outcomes is a good process.
   
5. What is the best proxy for assessing process quality?
   
6. • Outcomes over time (assuming that the benchmark they are measured against are useful),
   • believability-weighted (expert-driven) process assessment.

Goals & Systems

Goals are good for planning progress, but systems are necessary for actually making progress.
‍
As tiny changes today will exponentially impact reality over time, most of our predictions of the future will be incredibly bad. Thus, instead of predicting the future, build a system that can signal when adjustments are needed.

If goals are not calibrated to the context within which we are setting them, they turn into arbitrary numbers. E.g., if the goal is to increase the conversion rate by 15%, the question is:

• What is the usual fluctuation around the average conversion rate? How strongly of an increase is 15% measured against that? Would it even be a signal to detect it or just noise?
• Is there a reason to assume an upper possible limit for the conversion rate given market mechanics? Based on what data do we assume a 15% increase is feasible?
• How does a goal of 15% vs. 5% vs. 25% impact the actions we need to take in the pursuit of this goal? Would we do anything differently if the goal was 5% or 25%?

The less we understand these things, the more goals will become arbitrary targets instead of anchors suited to assess performance quality.

Goal Setting

Goals should inspire good actions. If they don’t, they are more dreams than goals.

To make goals fully actionable, they need to come with an indication of risk that we are willing to take to achieve them.

1. Otherwise, it's like saying we want a 10% return on our investment, but set no boundaries on our investment strategy.
   
2. It’s easy to say what we want but not what we are willing to risk for it.
   

There’s a difference between goals that are based on what we think we:
A: should be able to achieve, and
B: what we need to achieve.

1. A is suited to assess performance, B is not.
   
2. A, ideally: “we know this is realistic, so we need someone good enough to get us there."
   
3. B, typically: “we need this, but we actually don’t know if anyone can get us there.”
   

OKRs

Strategy implementation and management is challenging. OKRs are a popular tool for that -- but also a tricky and often misused one.

1. Team Objectives should be set by the leadership team:
   
2. • It is the sole responsibility of leadership to decide which problems teams are working on (objectives) and why they should be working on them (context).
   • Team autonomy should lie in the creation of Key Results (solutions to problems), not in the picking of the most important problems.

OKRs only truly work if they are being seen as an empowerment tool for empowered product teams and not for feature teams where teams are given top-down roadmaps with features on them.

1. You only get true accountability for solutions from teams if they develop solutions themselves.
   
2. The best product managers and product designers will not (for long) work in setups where team autonomy lies solely in maximizing usability of top-down solutions.
   

OKR processes need to be adapted to the idiosyncratic character of the company. The maturity of the people, team structures, horizontal and vertical interdependencies, as well as the nature of the problems to be solved matter.