OKRs

Let’s start with one that might not seem exciting but is essential—OKRs. Many are familiar with Google’s use of OKRs, often dismissing them as old news. After seven years at Google, I had learned, written, and presented OKRs numerous times.

However, this training served as a crucial reminder of how to craft effective OKRs with clear objectives (O's) and genuine key results (KRs) that go beyond vague goals.

This realization sparked a significant overhaul in how our leadership team approached OKR creation and the standards we established for our triads—the cross-functional leadership teams in our organization.

Takeaway: Even if you think you’re proficient with OKRs, you might not be doing them correctly. Revisit the fundamentals (or check out Itamar’s insights) to improve your OKR writing, and it will make a difference!

North Star Metric and Metrics Tree

Next up is the North Star Metric (NSM). Although I had heard of this concept several times, I had never seen it in action or understood how to apply it strategically.

The introduction of the Metrics Tree was particularly eye-opening. It connects and aligns multiple teams/projects/products, providing each with a relevant metric that contributes to the overarching NSM of the organization—this can even extend to the entire company.

Learning about this allowed our Triad—which included myself, the product manager (PM), the user experience (UX) lead, and the program manager (PgM) lead—to implement it for the first time in our careers.

Takeaway: Establishing a shared language through collective learning is vital for driving change, even if it means investing time from multiple team members.

Outcome (not output) Based Roadmaps (OBRs)

These roadmaps concentrate on user problems/goals and metrics. Rather than constructing a system for “Googlers to book rooms,” the focus shifts to “Helping Googlers find meeting spaces.”

The first approach might lead to a room booking system, while the second opens the door to innovative solutions such as identifying underutilized rooms or suggesting alternative spaces.

OBRs employ a goal and metrics at the top, with experiments, launches, and ideas listed beneath. This structure helps organizations concentrate on user needs and company objectives rather than merely rolling out features for the sake of it.

Takeaway: Focusing on outcomes over outputs is essential, and OBRs provide a practical method to facilitate this shift.

Wide Spectrum Validation

As a tech leader, I'm familiar with various validation methods, from usability testing to user surveys and production A/B testing. I particularly enjoyed the “fake button test” and “person behind the curtain” approach.

However, Itamar’s validation slide made me realize that we hadn’t utilized several other methods. The visual representation clarified that we were “leaving money on the table” by not exploring more testing avenues before launching a product.

This realization hit hard. Google engineers are eager to produce high-quality code, but what if the solution is incorrect? I don't want to wait six months to find out, especially after investing time in developing a scalable product.

This visual became a key reference in discussions about testing and development, encouraging our team to adopt a leaner approach while gaining confidence in our solutions.

Takeaway: Emphasize testing before building; there are more validation methods available than you might be using.

Impact Confidence Ease (ICE) Scoring

Impact: What potential effect could this feature, product, or idea have on the company?

Confidence: How sure are we about that impact? This is gauged using the Confidence Meter.

Ease: How straightforward is it to execute this idea (usually measured in weeks)?

ICE introduced a simple framework for prioritizing and choosing from a range of options. Despite the existence of other prioritization methods, none had been consistently applied in my extensive experience managing software organizations.

Moreover, it emphasized the necessity of testing multiple ideas simultaneously. I often witnessed teams ideating and selecting one option based on initial positive feedback, neglecting to explore potentially superior alternatives.

Takeaway: To discover the best solution, test multiple ideas concurrently. Relying on a single idea may not yield the desired results.

Confidence Meter

This was a novel concept for me. Itamar introduced a calculator called the confidence meter to tackle a long-standing challenge I faced.

During a demo session at our first COVID-19-triggered hackathon, each team presented with statements like, “I need four engineers, one PM, one UX, and nine months to build this.”

This exemplified how investment decisions were typically made in my experience. While some may claim, “This is how things are done at Google,” it’s more accurate to say, “This is how my organization operates.”

My leadership often based decisions on product strategy presentations. If the proposal resonated with decision-makers, it would be approved, allowing teams to work on it for over a year before any tangible results emerged.

This lengthy timeline can be costly.

The confidence meter operates on a logarithmic scale from 0 to 10, indicating the evidence available for making build decisions. The goal is to rely more on real user data rather than subjective opinions, leading to better-informed choices.

Takeaway: Transition from opinion-based decisions to data-driven choices through rigorous testing and validation.