Measure What Matters · John Doerr · 2017

Key Highlights

• Ideas are easy. Execution is everything.
• OKRs are a management methodology that helps ensure the company focuses efforts on the same important issues throughout the organisation.
• The Objective is simply WHAT is to be achieved, no more and no less. They should be significant, concrete, action-oriented, and inspirational. They act as a vaccine against fuzzy thinking and execution.
• The Key Results benchmark and monitor HOW we get to the objective. They should be specific, time-bound, aggressive (yet realistic), measurable, and verifiable.
• Assess at the end of the period, mark key results as completed or not (there shouldn’t be ambiguity). If all are completed the objective is necessarily achieved. If not all are complete - if they are still important, rollover and evolve to reflect current progress.
• OKR Superpowers:
1. Create focus and commitment to priorities
2. Align and connect teams
3. Track results for accountability
4. Stretch ambition
• Edwin Locke's theory:
1. Hard goals drive performance more effectively than easy goals.
2. Specific hard goals 'produce a higher level of output' than vaguely worded ones.
• OKRs are simple - but they demand rigor, commitment, clear thinking, and intentional communication.
• At Intel, the focus wasn't on what you knew, but on your effectiveness in translating that knowledge into actual results. Accomplishment > Credentials.
• Output is the key to productivity, not activity (that's the activity trap).
1. Hard goals drive performance more effectively than easy goals.
2. Specific hard goals ‘produce a higher level of output’ than vaguely worded ones
• OKR Hygiene tips:
• Less is more.
• Set goals from the bottom up.
• Stay flexible.
• No dictating (negotiate - they're a social contract).
• It's a tool, not a weapon.
• Be patient, be resolute (it'll take time to implement them well).
• Measuring what matters begins with simple questions:
• What is most important for the next 3, 6, or 12 months?
• Where should people concentrate their efforts?
• Successful organisations focus on a handful of initiatives, and leaders commit to them.
• YouTube wrote down a 6-month OKR to improve the login experience. Larry liked it and made it company-wide but shortened the timeline to 3 months.
• What is most important for the next 3, 6 or 12 months?
• Where should people concentrate their efforts?
• The Ying and Yang of OKRs
• Objectives: Principle, Vision, Inspiration
• Key Results: Practice, Execution, Earthbound, Metric driven
• A well-framed objective usually requires just 3-5 KRs to reach it.
• Too many KRs will dilute focus and obscure progress. Less is more. Innovation means saying no to a thousand things (Steve Jobs).
• If you're certain you're going to nail an OKR, then you're not trying hard enough.
• A 3-month time horizon curbs procrastination → It also makes feedback loops faster and more relevant. But the best OKR cadence is the one that fits the context of your business.
• If you’re certain you’re going to nail an OKR - then you’re not trying hard enough
• A key risk of OKRs is that specific challenging goals will be met but at the expense of other important aspects that were not specified (safety, ethics, reputation).Pair key results with non-goals or quality goals to avoid gaming of the system
• “At any given time, some significant % of people are working on the wrong things. The challenge is knowing which ones.” Aaron Levie.
• OKRs expose redundant efforts and save time and money
• Relying on top down cascading can:
• Reduce agility (everyone waits for them)
• Reduce flexibility (the effort to do them puts people off revising them mid-cycle)
• Marginalised contributors (shut out input from frontline employees)
• One dimensional alignment (works for vertical, but what about horizontal)
• Healthy OKRs strike a balance between alignment and autonomy.
• Unacknowledged dependencies remain the number one cause of project slippage. Transparency helps horizontal collaboration - the management tax is zero. Be careful of teams (like engineering) getting caught between OKRs → you need to make dependencies explicit.
• OKRs should be living and breathing organisms. Your options at any point in the cycle:
• Continue - if in the green zone
• Update - if in the yellow zone, modify
• Start - launch something new
• Stop - when in the red zone, it’s not useful anymore
• If you change an OKR mid-cycle, notify everyone
• Tell them what changed / what you learned
• AND what you'll do differently in the future
• Satisfaction = set aggressive goals → achieve most of them → reflect on the achievement
• Reflection questions:
• Did I accomplish all of the objectives? What contributed to success?
• If not, what obstacles did I encounter?
• If I were to rewrite a goal to achieve in full, what would I change?
• What have I learned that might alter my approach to the next cycle?
• Google uses two OKR types: Committed (achieved every time in full) and Aspirational (40% completion)
• You may need to fix your culture before you implement OKRs. You need to be ready for openness and accountability.
• Tell them what changed / what you learnt
• AND what you’ll do differently in future

Full Book Summary · Amazon

Subscribe Button 

In the News

This week Twitter open-sourced it’s chatbot (Grok). Which got me thinking, when is it a good idea to open source technology?

As product leaders, protecting core intellectual property is paramount. Your proprietary innovations differentiate your offerings and drive competitive advantage. However, there are scenarios where selectively open sourcing certain technologies can create strategic upsides that compound back to your business.

Imagine you've invested in developing a robust internal tool or component that streamlines operations, boosts productivity, or provides auxiliary capabilities valuable to your company. It's proven, tailored to your needs, and significantly beneficial. But it's not a product you'll ever directly commercialise or build an entire offering around. In this situation, open sourcing can potentially unlock immense value.

By taking that technology open source, you're giving it a broader stage for advancement beyond what your internal teams can provide. An open source community can contribute enhancements, additions, real-world hardening, and scaling that a closed internal project likely cannot match. The more external contributions, the more that ancillary tool grows in functionality and utility - benefiting your use of it.

You're not exposing core crown jewel assets, but allowing components advantageous to your business to receive complementary outside work and attention. This force-multiplies your initial investment. It can turn internal tools into robust industry solutions, while showcasing your technical leadership.

There is strategic consideration and effort required to properly open source technologies. But for non-differentiating components that still provide operational value, harnessing an open source model can be a savvy way to cost-effectively amplify impact. You're allowing eminently useful capabilities to expand their worth under the community's compounding efforts.

Quick Links

Emerging UX patterns in generative AI · Article

How luxury products defy all traditional marketing laws · Tweet

A theory of adoption and diffusion · Paper

Reality of Freemium in SaaS · Paper

Viral marketing on the internet · Paper

On creating a user insights knowledge base · Article

New Netflix paper on the dangers of using cosine similarity · Paper

What Jane Austin has learn about product management · Article

Does optimising planning for anti-fragility make sense? · Article

A breakdown of Claude 3’s system prompt · Thread

Microsoft Artificial Intelligence Controller Interface (AICI) · Article

Principled Negotiation · Fisher & Ury · 1981

Negotiations commonly follow a process of "positional bargaining," a win-lose paradigm where each party begins with their stance on an issue, and through bargaining from separate opening positions, an agreement is reached. This is typically seen in price haggling, where each party has a bottom line figure in mind. Fisher and Ury argue that positional bargaining often fails to produce beneficial agreements due to its inefficiency in reaching agreements, neglect for the other party's interests, involvement of ego, and encouragement of stubbornness, consequently damaging the parties' relationship.

The authors define principled negotiation an effective way to negotiate and lay out 4 principles to follow:

1. Separate the people from the problem
2. Focus on interests not positions
3. Invent options for mutual gain
4. Insist on using objective criteria

View the Paper

Book Highlights

Ease is the measure of the time and resources needed to run the experiment. Ideas such as substantially redesigning the new user experience or revamping the shopping cart in the checkout process might be high impact, but they are usually not easy undertakings, requiring weeks or months of work to launch. The ease score both provides the growth team a reality check about overly ambitious ideas and helps identify some “low-hanging-fruit” tests to run each time through the growth hacking process. Morgan Brown and Sean Ellis · Hacking Growth

As long as research data is stored as tacit knowledge in people's minds or buried in interview transcripts, teams will experience difficulty synthesizing what has been observed and learned. Bruce Hanington and Bella Martin · Universal Methods of Design

The product manager is not there to “gather requirements” from stakeholders, but the product manager is also not there to dictate solutions to stakeholders. Rather, the strong product manager understands that each stakeholder is responsible for some key aspect of the business, and they are a key partner in helping to come up with a solution that works. Marty Cagan · Empowered

Best of X

Do not place your faith in playbooks

Take this from a lover and writer of playbooks: they can never teach you how to do something hard.

There are 4 reasons you should be suspicious of the teachings of any playbook or framework:

1) It’s much easier to write a playbook than it is to do a hard thing. 2) The ability to know something and the ability to explain it well are two different skills 3) True knowledge of how to do something hard is too rich in depth and nuance to transfer to another person. 4) Your exact context will be different and something the framework author probably does not have firsthand experience of.

Julie Zhuo