“Delight customers in hard-to-copy, margin-enhancing ways.”

— Gibson Biddle

In Chapter 1 I described my approach to strategic planning and provided a framework for identifying behavior-based key results for objectives and key results (OKRs) so for this article, I’ll stay high level and discuss the context needed to enable empowered teams to be successful.

I’m a fan of empowered teams using continuous discovery and participatory design approaches to solve problems in ways that, as former VP Product of Netflix Gib Biddle says, “delight customers in hard-to-copy, margin enhancing ways.”

I learned the benefits of empowered teams using continuous discovery approaches in the Navy and later at Google, Electronic Arts, Groupon, and Coursera. However, over my multi-decade career across multiple industries, I’ve found it challenging to transform a team or organization from a command-and-control (C&C) model to an empowered model.

That hasn’t stopped me from trying. Part of the issue is articulating to C&C model teams how to work in an empowered, continuous discovery way. Marty Cagan’s Inspired and Empowered and Teresa Torres’ Continuous Discovery Habits go a long way to providing context. Based on my experience and their writing, here is the iterative approach I’m working through now.

From Strategy to Objectives

This section articulates how I approach working across and within organizations and teams to identify and prioritize objectives, rather than projects. Objectives are easier to calculate ROI/NPV for than projects because they have key results that are tied to business impact, such as increasing daily active use of a productivity tool is likely to lead to retention, and retained users generate monthly recurring revenue. There is any number of projects a team might complete to increase daily active users. Your model and the accuracy of the metrics will depend on your business and the sophistication of your data science program.

Each of these is an ongoing area of focus for their respective leaders - at the org or team level - meaning every section is cyclical, negotiated with the impacted teams, and can be changed when new information presents itself warranting a direction change.

Strategy

Starting with a clear and simple strategy based on evidence from user and market research, company purpose, vision, and business goals, the leadership team partner with finance to determine and articulate the most important business performance metrics that need attention in a given timeframe. I then use a top-down and bottom-up hybrid approach to setting team OKRs.

Top-Down Objectives

To identify the initial list of objectives leadership works with all departments to identify and prioritize possible objectives to meet the goals of the target audience and business. The executive team then downselects all possible objectives through whatever methodology best suits their business. To keep things simple I start with impact to revenue, gross margins, and profit margins as the three main criteria to prioritize against. Each of those can be broken out into separate metrics depending on your business model. I create a rough scoring guide for each business metric, score each objective for impact to those business metrics, add the scores, and multiply by urgency or importance to provide some weighting to even the scores out some. It’s imperfect but serves as a helpful tool to downselect objectives.

Bottom-Up Objectives

Once the objectives are drafted, leadership works with department heads and directors to align teams to objectives. These teams will own the objective until it’s complete, as measured by key results. Because the teams have more context for possible opportunities, each team adjusts the objective language based on their understanding of the desired user and business outcome. This negotiation is crucial in providing the teams with ownership over the objectives and ensuring expectations are set for what business measures are likely to be impacted by when to help with budgeting and forecasts.

Key Results

The next negotiation is over the key results (KRs). The teams must identify, decide on, and have full autonomous ownership over the key results they will be held accountable for. For customer-facing teams, these KRs can be summed up in the HEART metrics framework, including happiness, engagement, adoption, retention, and task success, which I wrote about previously.

Key result metrics are crucial to figuring out what types of projects a team will undertake, so it is important for teams to create a hypothesis for what behaviors in the product lead to expected business results. Without knowing what specific behaviors will help a customer realize value from the product or service and continuously tracking and reporting on those key metrics, a team will have to start from scratch every time objectives change.

Discovery

Once leadership and the teams have negotiated and agreed on the objectives and key results, the teams begin discovery. By team here I mean the cross-functional group brought together for an extended period, usually at least a year, who have the context for and autonomy to solve the problems and opportunities they own. For product development teams that might be a product manager, tech lead, and design lead. The team will need time to identify opportunities to develop solutions. Some members of the team will participate in discovery, while some may be working on maintenance, bug fixes, UI updates, infrastructure enhancements, process improvements, etc.

As Marty Cagan writes in Inspired, the purpose of discovery is to find solutions to user problems that also benefit the business. Is the solution valuable to the customer, viable for the business, delightful and usable for the customer, and feasible to build or support? To find solutions to selected opportunities, teams repeatedly move through the same basic process: assess the current situation, identify gaps, determine solutions to close the gaps, test solutions against each other in the lowest cost highest information way possible, invest in the best solution, repeat. That is the basic concept of going from objectives to results.

“Empowered teams serve customers in ways that meet the needs of the business.”

— Marty Cagan

From Objectives to Results

There is no right way to get from strategy to seeing business results. Just like there is no right way to get from Los Angeles to New York - how you get there depends on your needs and interests. If you want to see the sights along the way you’ll probably drive or take a train. If you want to get there quickly for a business meeting you may want to fly. To know which travel solution to select you first have to start with your objectives and determine how you’ll measure if you accomplished your objectives. Most people do this somewhat naturally in their personal lives. If want to own my own home (objective) my first key results might be the percent toward a downpayment, the percent saved up for any renovations or furnishing I might want to do, and an income metric that ensures I can afford the cost of ownership once I do own a home. Now that I have a goal and target metrics to help me determine what success looks like I can spend my time finding opportunities to impact my key metrics. I do this through continuous discovery and delivery.

Path from objectives to solutions using continuous discovery and delivery

Outcomes & OKRs

Picking up where we left off in the prior section, the team now has their assigned outcomes, articulated as objectives that will be measured by demonstrating movement in metrics known as key results. Leadership continues to provide any needed context for the objective while the team leads continue speaking with customers to identify opportunities specific to the outcomes they are held accountable for.

Opportunities

If teams are constantly talking to their customers they will likely have many more opportunities to solve than they have time for. For product development teams the product manager is responsible for prioritizing opportunities using whatever methods are best suited to their skills, the team needs, and the sophistication level of the data science program.

User research has a strategic role to play here as they help product teams uncover the opportunities that align with the customer behaviors the team is trying to improve. It is critical to identify the most important and solvable opportunities so I advise teams to take their time with this work or split it off from ongoing maintenance and tech or design debt paydown work.

This is also a handy way to make sure the development teams have time to do the ongoing work that often gets deprioritized in project-based or C&C model teams where teams work from project to project rather than owning outcomes and maintenance. In other words, don’t forget to vacuum, do the dishes, and dust while saving up the downpayment for your home purchase.

Sometimes a team will uncover opportunities that don’t match the outcomes they’re trying to achieve. If they believe the opportunity presents more potential value to the customer and business, they renegotiate with leadership to change course. Otherwise, they put the opportunities in a backlog to pick back up again later.

Solutions

With opportunities in mind, design and engineering (for product teams) work on solutions. The modern approach is to use participatory design - include your customers in the design process to develop better solutions. Teams generate as many solutions as possible and, as Teresa Torres puts it, sets up “compare and contrast” decisions between the solutions. Some of these decisions can be made in design or product reviews, some can be made when looking at feasibility, and some can be made when looking at what value customers get or the business will receive from the solution being implemented.

Experiments

However, it’s difficult to know what will work by just looking at it. Participatory design helps teams with experiments that enable customers to guide the decision. This can be through user research with prototypes or by launching unscalable changes to test the hypothesis before implementing a more scalable version later. Experiments help us understand if the solution addresses the opportunity and desired outcomes, if the solution is usable, feasible, valuable, and viable, and can even uncover if the opportunity itself is addressing a real pain point, need, or desire.

Example

Objectives and Key Results

Here is a realistic example for a software business that serves videos to a niche audience. I’m using an internal-facing team to show how this approach works for more than customer-facing product teams.

Imagine the finance team has noticed pressure on gross margins and in exploring why we determine storage costs are growing at an unsustainable rate. The leadership team identifies an objective to reduce the rate of growth of storage costs and assigns a team the objective.

The main key result, or north star metric, is the rate of growth of storage costs. That metric is tied to a few specific ways storage is being used and the storage vendor contract, so the team assigned the objective identifies 2-4 key metrics they can impact that impact the growth rate.

Opportunities

The team examines the current code and identifies three opportunities: places where things aren’t working as expected, where something was missed in developing a prior feature, and where the vendor is making a mistake.

Solutions & Experiments

The team prioritizes opportunities based on how much impact they are likely to have and begins digging into the code to find a way to fix bugs, seeing an easy way to save some money through that path. They do research (or spikes, in agile-speak) to identify and experiment with solutions, then complete work on the most promising solutions, regularly reviewing and reporting progress with their key results.