Product Goals: Using Objectives and Key Results (OKRs) for Agile Teams
Published: Mar 7, 2016 | Last updated: Jan 20, 2021 | 19 min read
This is my complete guide to Product Goals in 2021.
In this all-new guide you’ll learn:
- What Product Goals are and why they matter
- The difference between Outcome and Output Product Goals
- How to combine Objectives and Key Results (OKRs) with Agile practices like Theme-based Roadmaps, Product Discovery, or Scrum
- Proven techniques to set Product Goals
- Lots of advanced tips, strategies, and tactics
If you’re asking yourself how you can connect Product Strategy and your Product Discovery/Delivery efforts through outcome-oriented goals, you’ve come to the right place.
Let’s get started.
Don’t have time to read the whole guide right now?
No worries. Let me send you a copy so you can read it when it’s convenient for you. Just let me know where to send it (takes 5 seconds):
Does your team ask, “How do we know that we’re on track?”Besides knowing what success might look like “in the end,” it can be even more important to know how your activities and progress match your ambitions while you’re moving ahead.
And that doesn’t just depend on the type, quality, and choice of your defined Product Goals, but even more on how you use them. If you set a goal with a specific ship date, that probably won’t help you organize your everyday activities.
Product Teams certainly spend a significant amount of time with their heads down, focussing on Product Discovery or Delivery. But when they look up, to seek guidance for their next move, they shouldn't just be presented with a list of features and release dates.
That’s what differentiates effective Product Goals from setting arbitrary milestones.
A Primer on Product Goals
In this Chapter I want to introduce the basic concept of Product Goals by answering some fundamental questions.
What are Product Goals?
Obviously, it’s hard to squeeze a generic term like goals into a one-size-fits-all definition. So, instead of trying to define what exactly Product Goals ARE, I will focus on what they DO—at least when used properly.
The main thing Product Goals should DO for Product Teams and your organization is to make your strategic direction more tangible. While the strategic direction for the next three to twelve months provides high-level orientation, Product Goals help to make sure that more tactical decisions are also in-line with that direction.
And while Product Strategy can also include high-level numbers to express a certain strategic priority, Product Goals become more effective when they exclusively focus on measurable progress. Product Goals can incorporate more aspects of building a product than just pure performance. We’ll talk about the combination of qualitative and quantitative goal setting later.
But be careful. Because Product Goals are meant to connect Product Strategy and Product Execution, it’s easy to confuse these three terms.
With these things in mind, let’s settle on a working definition for moving through the rest of this article.
Product Goals Definition
Product Goals are a set of tangible and measurable expressions of what success looks like for a product. Product Goals connect Product Strategy and Product Execution by providing teams with a concrete and holistic set of metrics, so they know if they are moving in the right direction and can adjust their actions if needed.
How are Product Goals different from Product Strategy?
Without going into too much detail about Product Strategy, here are the main questions every (good) Product Strategy should be able to answer:
- What are the essential problems your product is solving for your users and which ones do you want to address in the future?
- What alternatives could your users use to solve that problem (ie. direct and indirect competitors)?
- What are the core value propositions that define your product?
- What makes your product unique compared to those direct and indirect competitors?
I like to visualize the answers to these questions using the Product Field framework to have the (constantly evolving) pillars guiding Product Discovery efforts constantly visible.
Product Strategy is the starting point for Product Discovery. But Product Teams shouldn't blame it on their manager or the C-level if the Product Strategy isn’t clear. Instead, I encourage them to create clarity about their strategic direction themselves. By utilizing collaborative frameworks like the Product Field, you can outline the strategic direction of your product and identify the existing blind spots pretty easily.
The point is not to create a McKinsey-level company strategy. But something to refer to when you have to make trade-off decisions as you navigate through the problem space of a discovery mission.
In general, I like to differentiate the main disciplines of Product Management into three flight levels.
- Product Purpose/Vision/Mission and Product Strategy
- Product Goals and Product Roadmaps
- Product Discovery and Product Delivery
So, instead of treating these six disciplines as siloed activities, I believe in a more connected perspective:
Not only are the disciplines within one flight level connected, but the insights and experiences from one discipline flow up or down to inform the other flight levels. Because of that, the quality of every of these six disciplines radically influences how well one of the others can be implemented. When Product Strategy isn’t clear, many teams struggle when asked to “define goals for the quarter.”
Arriving at the “right” set of Product Goals is a journey that requires iteration—often both within and between goal cycles. But it can get a lot easier when teams have the right strategy to begin with.
How to identify Product Goals?
Product Discovery entails creating alignment around which problem space to pursue and diving deep into the challenges your users, customers, or stakeholders face.
After all, you want to make sure you have understood what the actual (and often underlying) problem is and if it's worth solving. But once you have identified and structured your findings in the forms of user behaviors worth changing, teams often get lost.
Now, user problems are rarely suited to be used as goals right away. Instead, we have to think about how you could measure your success. To set tangible Product Goals you must boil down the gathered qualitative and quantitative insights from your user research to determine HOW to change your user segments' behavior.
Let's look at a b2b example first. Assume you're building analytics software and your strategic priority is to increase revenue from agency customers. Through research, you might identify specific problems your target audience faces.
For example, account managers may be struggling with how long it takes to report results to their clients, and IT administrators need constant updates on data compliance. So, if you focus on the identified outcome for account managers, the “How might we…?” (HMW) challenge based on their core problem might read like this:
"How might we speed up the client reporting process of results for account managers?"
And even though this provides lots of context for ideation and prototype creation, you need to be more specific.
If you're shipping a solution for that problem, you want to know what success looks like. Rarely can you tie one product release to a high-level metric like company revenue. This means the team should think about specific metrics that express what "speeding up" would look like for account managers.
From a qualitative perspective, you might utilize a modified Customer Effort Score on-site survey to see how the perceived speed has changed: you could set a Product Goal like "Customer-Effort-Score of 4.5 for the report generation process."
From a quantitative perspective, you could look at metrics like "time spent" in this product area or the number of reports created. Both metrics could tell you how the behavior has changed.
Defining a Product Goal that works for the solution you have settled on should be a cross-functional effort. The analytics manager might help you with what's possible. The UX designer might bring a new user perspective to defining "what success" looks like.
The way you transition identified user problems into measurable Product Goals should be aligned with the way you utilize goals in general at your company. Make sure to adjust this process if you're using something like Objectives & Key Results (OKRs), the North Star Framework, or the Balanced Scorecard.
Another important, yet often overlooked aspect of identifying and choosing Product Goals that are actionable is the difference between leading and lagging indicators to measure the progress of OKRs.
Using Objectives and Key Results (OKRs) for Product Goals
OKRs are a very effective way to set, track, and review Product Goals. In this Chapter, I will outline the structure of OKRs, as well as the difference in using Output and Outcome OKRs.
What are Objectives and Key Results (OKRs)?
OKRs stands for Objectives and Key Results. In short, OKRs combine the best aspects of goal setting into one framework: A highly-inspiring qualitative vision with concise and measurable metrics to determine success or failure.
An Objective is like a mission statement, only for a shorter period. A great Objective inspires the team, is hard (but not impossible) to do in a set time frame, and can be done by the person or people who have set it, independently. An Objective should typically be:
- Qualitative and inspirational
- Difficult but not impossible to achieve
- Actionable by the team independently
Key Results take all that inspirational language and quantify it. You create them by asking a couple of simple questions: How would we know if we met our Objective? What numbers would change? A company should have two to five Key Results per Objective. In general, Key Results can be based on anything you can measure.
Objectives and Key Results (OKRs) Definition
OKRs combine the best aspects of goal setting into one framework: A highly-inspiring qualitative vision with concise and measurable metrics to determine success or failure. Key Results take all that inspirational language and quantify it through 2-5 holistic measuring criteria.
If you select your KRs wisely, you can balance forces like growth and performance, or revenue and quality, by making sure you have both the potentially opposing forces represented.
The 'invention' of OKRs is often credited to Andy Grove during his time at Intel. Later on, it got popularized through wide-spread implementation by Silicon Valley companies like Google. While many people admire the improvements Google made in employee performance management, OKRs have evolved to become much more.
Here’s an example of an OKR set:
- Objective: We are an integrated and mature platform solution
- Key Result 1: Our Enterprise client satisfaction rate is >75%
- Key Result 2: No sales pitch is lost through “immaturity of the product”
- Key Result 3: 100% of interviewees associate our website with the terms “enterprise,” “trustworthy,” and “capable”
Nowadays the appeal of OKRs for agile product teams lies in its core promise for improving the way we work:
- More focus
- More autonomy
- More alignment
A typical cycle for OKRs is a quarter. Smaller companies could combine that with a yearly OKR to let every Objective aim at something beyond the next three months.
Also, while it's standard (and ok) to set up to three OKRs for a team per quarter, this already poses a drastic improvement in terms of being able to focus on a few key initiatives. While some stakeholders confuse 'Agile' with changing their mind every two weeks just in time for the Sprint Planning, OKRs provide a continuous path to pursue throughout the entire quarter.
Moreover, even though OKRs don't necessarily need to cover ALL of your work (everybody knows some maintenance work can be critical), they should reflect what's most important for your team.
Don’t have time to read the whole guide right now?
No worries. Let me send you a copy so you can read it when it’s convenient for you. Just let me know where to send it (takes 5 seconds):
By design, effective Outcome-OKRs don't talk about features. Instead, they shift the conversation to the impact a team should seek to make, as opposed to measuring the number of released features.
For your stakeholder environment this means they will delay talking to you about their feature wish list, but instead agree on a set of outcome metrics first. We’ll talk about Outcome goals later.
For teams, it means focusing on the (most critical) problems first to reach their (ambitious) Key Results.
The process of defining OKRs should involve all levels of a company. While it's natural that a leadership team sets the company-level OKR, the next step is to get the rest of the company on board. That’s how a single team gets inspired by the overall direction of the company to define their contribution in the form of a matching OKR. Making the OKR definition and review a focussed effort for the entire company at the beginning/end of a quarter reduces misunderstandings across teams significantly.
The way you implement OKRs should be set through an OKR System, that is derived from the desired benefits your team or company expects from adopting Objectives & Key Results.
Outcome OKRs vs. Output OKRs
Many product teams are looking for ways to shift their way of working and thinking towards outcomes. Whether that's through theme-based roadmaps, Impact Mapping, or...Objectives and Key Results (OKRs).
However, there's a common misbelief that OKRs come with "built-in" outcomes. Setting goals this way will automatically limit your discussion to fewer solutions - ie. Outputs.
Now, before we go further, let’s go over what I mean when I talk about Outcomes and Outputs.
To me, an Outcome describes a measurable change in behavior that contributes to an Impact. (This definition is inspired by Josh Seiden’s excellent book “Outcomes over Outputs.”)
An Output, on the other hand, is an artifact that has been delivered through activities. It's one way of creating this change in behavior, whether for customers, users, or internal stakeholders.
OKRs can work with either Outcomes or Outputs. As with every framework, the benefits of OKRs highly depend on how you use them. It's certainly possible to set some or all of your Key Results as Outputs. In some instances, this might even be a better way to get started. Some teams get stuck in the Key Results definition process because they try to turn everything into an outcome—just for the sake of it.
Here’s a practical example of how Outcome OKR and Output OKR sets might differ:
But there’s more to shifting to Outcome-based Product Goals in your organization than to define more “Outcome-ish” Key Results.
Putting Outcomes into practice requires changes to your processes beyond defining OKRs. My upcoming course “Outcome OKRs for Product Teams” helps you learn which levers to focus on and shares practical advice on how to shift your team’s focus from Outputs to Outcomes.
Combining (OKRs) and Agile Product Management
This Chapter will shine some light on how teams can effectively combine the strengths of OKRs with existing Agile practices like Product Discovery, Product Roadmaps, and Scrum.
Building digital products can often seem to be all about pushing tickets and releasing code. Instead, I want to broaden your horizon for the three levels of a sustainable Agile product management process:
- Product Roadmaps
- Product Discovery
- Product Delivery (ie. using Scrum)
Agile Product Teams experience the biggest additional value from using Objectives and Key Results if they are able to focus their Key Results on Outcomes and integrate OKRs into existing tools, practices, and routines.
Defining their OKRs helps Product Teams align and commit to goals. But they still need an additional session to pick specific initiatives and next steps. A dedicated session to prioritize Epics and Initiatives is necessary to get a team into the Product Discovery phase of a Problem Space or the Delivery of a (previously discovered) solution. But how can you structure it?
Using Impact Mapping to select Epics after the OKR Definition Workshop
Let’s shine some light on how Impact Mapping helps Product Teams during this Epic Selection session.
As a quick recap, here are my five levels of Impact Mapping:
- WHY - The Impact-level goal that matters to the whole company/department.
- WHO - The (internal and external) user segments (Actors) who contribute to the Impact.
- HOW - The change in behavior the team seeks to create for the Actors.
- WHAT - The potential solutions (Outputs) a team could pursue to create a change in behavior.
- WHETHER - The experiments the Product Team is running to determine if the output is worth pursuing.
If you work with company-level OKRs, chances are that these Key Results can be candidates for your Impact as the starting point. This represents the quantitative measurement of success for the company from a quarterly or yearly perspective.
The Actor level should be clear from previous research efforts. If not, schedule additional research for the quarter.
If your team has established Outcome-oriented Key Results, those can now serve as input for the HOW level. Ideally, your Impact Map has informed your OKR definition process, so there's no gap between the two perspectives.
Because you (hopefully) know which Outcomes in the form of your Key Results are a priority, you can now transition into the solution space. If those Outcomes are based on existing Product Discovery work, one of your next actions should be structured ideation to come up with feature ideas.
These ideas (along with the following experimentation) could have already happened in a previous quarter to inform the Delivery work you now want to focus on. Because, after all, you will probably only achieve those Key Results through shipped solutions.
Communicate Epics and Initiatives using Theme-based Roadmaps
Sadly, most businesses still plan product development up to 12 months into the future by relying on time-based roadmaps following a Gantt chart style visualization. While this approach may have worked for the static waterfall planning we used to do 'back in the days,' it's hardly suited for agile and iterative methods, which embrace uncertainty instead of trying to fight it with deadlines.
A more fitting approach for planning your efforts is based on so-called Theme-Based Roadmaps. They enable you to prioritize broader initiatives, rather than fixed feature sets, and acknowledge increasing uncertainty as you look into the future.
You can also compare themes as the parent element of specific Epics. A theme represents a more significant user or business problem you draw on to discover a solution (ie. Epic) to reach your goals.
The three categories of a typical Theme-Based Roadmap can be differentiated like this:
- NOW - Ideas that have been validated, specified in more detail, and are currently implemented.
- NEXT - A prioritized list of the strategic priorities Product Teams will explore using Product Discovery.
- LATER - Ideas that might fit current strategic priorities, but have not been committed for Discovery or Delivery work.
Examples for a theme could be things like 'User Growth,' 'Revenue,' 'Churn,' or 'Enterprise.' Corresponding Epics could then be 'Referral Mechanism,' 'Free Trial, ‘Self-Service Help Center’, or 'Single Sign On.'
C. Todd Lombardo delivered a great presentation on this modern approach to building roadmaps at the Mind the Product San Francisco Conference in 2018:
OKR and Theme-Based Roadmaps play nicely together right after you have committed and aligned OKR sets, e.g.quarterly. You don't have to turn Key Results into release dates and Gantt charts right away. Instead, the themes from the roadmap inform your OKR priorities and vice versa.
But it's not about choosing between themes OR Epics at this point. A Theme-Based Roadmap also incorporates the Epics (IF identified through Product Discovery).
But what if you haven’t done the work to decide which Epic to pursue? Then there's little to no point in using Outcome OKRs in the first place. You could have just tasked teams with building "this thing."
There's a time and place for date-based release plans.But communicating chosen Epics coming straight from the OKR definition workshop is not one of them.
Combining OKRs and Product Discovery
Product Discovery describes the iterative way of collaboratively answering two key questions:
- Is this a problem worth solving?
- Is this a solution worth pursuing?
Just as with Objectives and Key Results (OKRs), I prefer to help teams find their own way of using Product Discovery techniques in a way that works for them, instead of prescribing a given process. As a result, I have developed the Adaptable Product Discovery approach, that guides teams through the non-linear process of reducing uncertainty around the problem space of a given mission.
As mentioned, Product Discovery works great in combination with Theme-Based Roadmaps, as it encourages your Product Team to think about Outcome instead of settling on detailed feature ideas right from the start.
But there are also challenges when using OKRs in Product Discovery. For one, there's the aspect of timing: When you have defined your OKR at the beginning of the quarter, then embark on a (typical) 6-week Discovery phase, you have hardly enough time left to make an impact with what you're building. Remember that shipped features sometimes need weeks in the hands of customers before they cause a change in behavior and thereby metrics.
On the other hand, how should you decide on which area to focus on, if you don't know the goals for the next quarter yet? Here's where the concept of the Theme-Based Roadmap comes in handy.
Because you have a rough understanding of which areas your team wants and needs to work on 'Later,' you can define a Product Discovery OKR for the current quarter. This might include Key Results like 'Understand the key needs of 10 Enterprise product prospects' as the ‘Enterprise’ themes for the following quarter.
This way, the Dual Track efforts of an Agile team can be organized using OKRs, and the Product Manager has clarity about what to focus her Product Discovery efforts on:
While Product Discovery focuses on the problem space, a lot of Key Results focus on Delivery and business results (which is another discussion by itself). The biggest problem here is that this draws the attention away from the Discovery activities of a team. By agreeing on, and regularly revisiting, a dedicated Discovery OKR, teams can raise the awareness for this (often unseen) part of their work.
If your company agrees on the fact that OKRs should reflect the top priorities, that’s an even bigger argument for utilizing a dedicated set of Product Discovery OKRs. After all, Product Discovery should be one of your priorities. A separate OKR set can help establish a shared understanding of that.
In my opinion, one of the most significant additional benefits of OKR for Agile environments is the (continuous) connection to everyday tasks. So, when you spend 20-30% of your daily activity on Discovery, I believe that there should be an overarching goal in place for those tasks.
Effective OKRs enable a holistic perspective. So, besides business results (a performance aspect), it's worth incorporating things like product quality or process improvements. A Product Discovery OKR can help establish alignment across individuals and teams to focus on essential practices. Alternatively, you can also establish specific Discovery aspects as an individual Key Result, instead of dedicating an entire set to it.
Please keep in mind that the primary job of a Product Discovery OKR is to make Product Discovery work a visible priority for your team. It doesn't have to be the perfect incarnation of existing OKR blueprints.
How to combine OKRs and Scrum?
When it comes to Product Delivery, you need to make sure that as many items as possible in your product backlog can be associated with an OKR. That is the only way to connect your team’s everyday tasks with the higher goals of the organization. If you're using JIRA for managing your user stories and agile processes, you can easily integrate this OKR connection through a set of custom fields.
The built-in dashboards then give you a concise overview of how much work a team has dedicated to reaching an OKR:
Next, you can also link each of your Agile routines to your goals by tying your activities to questions about their relevance:
- Bi-weekly Sprint Planning: What are the next priorities to make progress with our OKR?
- Bi-weekly Review: Which output AND outcome did we achieve?
- Bi-weekly Retrospective: How did our collaboration hold up to our norms?
In my talk “OKR – 3 Letters for Effective Product Organisations” at the 2019 Product Management Festival Europe, I shared more insights on how Product Teams can utilize OKRs for their daily work:
Product Goal Examples
Whether you’re using OKRs to set Product Goals or are facing specific challenges based on your industry, this Chapter will deliver practical examples to inspire your next goal cycle.
Besides some generic metrics like Page Views, Conversion Rate, Customer Satisfaction, or Churn, I want to address some domain-specific product goal examples in this section.
Product Goals for SaaS Product Management
SaaS products mostly use subscription revenues to monetize their offerings. Which means that in the short- to mid-term, Product Managers need to focus on more tangible leading indicators than the actual churn event.
From a Product Strategy perspective, it might make sense to prioritize the reduction of the churn rate as an overarching priority for the company. But for measuring the success of ongoing product work, teams need to look somewhere else.
Here some example metrics Product Managers can adopt for that:
- Completion rate of onboarding steps
- Number of key metrics (like number of connections, collected research insights, set up integrations) achieved in the first 30d that mirror an aha! moment for your users
- Usage frequency, while keeping in mind the natural usage patterns of your product
On a mid- to long-term level, other metrics like ARR, Number of Logos, or Annual Contract Value can be used as well, to make a strategic direction (Growth vs. Monetization vs. Retention) more tangible.
“Some products should be analyzed in a 7 day timeframe – like SaaS/productivity – and others on 30 days:
Another flavor of the Power User Curve is a histogram of users’ engagement for a 7-day period, also commonly called L7. The 7 day Power User Curve shows weekly actives, not monthly actives. Plotting this version can make sense if your product naturally follows a weekly cycle, for instance, if it’s a productivity/work-related product that users engage with Monday through Friday. B2B SaaS products will often find it useful to show this version, as they want to drive usage during the work week.”
Product Goals for Enterprise Product Management
When it comes to building a product for the Enterprise, many Product Managers will grow frustrated with the lack of quantitative data.
After all, whether you achieve 70 or 75 page views of that new product area, is often insignificant. Yet, it’s the reality of building a problem for a limited number of companies, with an even more limited number of users per account.
But this doesn’t mean that goals become obsolete. Instead, you have to double-down on qualitative metrics and internal process excellence.
Here are some examples:
- Number of live bugs reported by customers
- Feature usage frequency per customer (properly segmented!)
- Customer Effort Score (ie. per newly released feature)
Product Management OKR Examples
Product Delivery OKR Examples
- Objective: Satisfy existing enterprise clients to lay the foundation for contract renewals
- Key Result 1: 0 major incidents (like blocker bugs or data-loss) per client
- Key Result 2: Every requested and implemented feature gets used by the respective client at least once
- Key Result 3: Establish a feedback process for enterprise clients with the average feedback being "satisfied"
- Objective: Successfully launch version 3 of our main product
- Key Result 1: Get published product reviews in over 15 publications
- Key Result 2: Get 10.000 new signups
- Key Result 3: Achieve trial to paid ratio of over 50%
Product Discovery OKR Examples
- Objective: Our users are excited about what we‘re building next.
- Key Result 1: JIRA integration User Research, Ideation, and Validation of most promising ideas.
- Key Result 2: Test three new research techniques which capture user excitement.
- Objective: Activate user-testing of our product
- Key Result 1: Conduct 21 face to face user testing & interview sessions
- Key Result 2: Receive 15 video interviews from Usertesting.com
Product Goals Resources
Here are some additional resources that have either inspired my own work over the years or are great deep dives into some specific areas of setting Product Goals.
Why the secret to success is setting the right goals by John Doerr
How Ambitious Should your OKRs Be? by Felipe Castro
“Think of stretch goals as goals that are so hard that make the team rethink the way they work, ask hard questions and have the difficult conversations that have been avoided. Stretch goals make teams wonder how far they can go. In fact, in a meta study of 35 years of empirical research, goal-setting theory pioneers Edwin Locke and Gary Latham found scientific evidence that shows that “the highest or most difficult goals produced the highest levels of effort and performance.”"
Don't Let Your North Star Metric Deceive You by Brian Balfour, Shaun Clowes, & Casey Winters
“The search for one key metric for a complex ecosystem like Pinterest over-simplifies how the ecosystem works and prevents anyone from focusing on understanding the different elements of that ecosystem. You want the opposite to be true. You want everyone focused on understanding how different elements work together in this ecosystem. The one key metric can make you think that is not important.”
How to fix Your Product Goals for Better Human Outcomes by Rob Boyett
"So, product goals and metrics – the tools that allow you to build design foundations and shape a strategy. These often-confused bedfellows can set you up for problems later on, because metrics are not goals. You know that, right? Tech entrepreneur Avichal Garg puts this very well in his aptly named piece Metrics: “The biggest risk in creating a metrics-informed culture is that over time, people conflate metrics and goals.” Avichal goes on to say: “If you lose sight of the value you are ultimately creating, you can move metrics for the sake of moving metrics.” For clarity, goals can be summarised as an aspiration to create real value for customers. A metric is a proxy for that value, an abstraction that allows you to track progress toward a goal."
5 Ways Your Company May Be Misusing OKRs by Itamar Gilad
Quote from the article:
"But here’s the thing - OKRs are just containers for goals. They serve bad goals just as well as they do good goals. In fact, of all the management tools, OKRs are the easiest to misuse, overuse and abuse - many companies fall into this trap. This is a major problem because bad OKRs can amplify the issues the org is troubled with rather than fix them."
Empower Product Teams with Product Outcomes, Not Business Outcomes by Hope Gurion
"Product teams struggle to drive business outcomes because many companies haven’t taken the time to define their strategy. Marty Cagan highlighted this in his recent post “Product Strategy – Focus.” Cagan laments that many companies think they are prioritizing and strategically focused when in fact the opposite is true. He quotes Richard Rumelt, author of Good Strategy Bad Strategy: “Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes."