The main thing is to keep the main thing, the main thing.

—Jim Barksdale

To continue with our series on product strategy, in this chapter I focus on, well, focus. The importance of truly picking your battles as an organization.

And I don't just mean deciding what to work on and not work on, but picking the few things that can truly make an impact.

This is another one of those topics, like whether a company cares about their customers. In pretty much every company I meet, the leaders already believe they are reasonably good at focus.

But, often, the company's leaders need a reality check on this topic.

The sheer number of things they believe are critically important, and that need to happen this quarter, or this year, are often an order of magnitude too many. I mean that literally. Instead of 2–3 truly important things, they have at least 20–30.

Now, in fairness, I understand why the key leaders believe they are reasonably good at focus.

They have already had countless meetings where they agreed to so many things they really want to do this year, yet won't be able to. So from their perspective, they think they already know what it means to say no and sacrifice.

In large part, this is a reflection of leaders feeling the need to place a lot of bets—versus the best or most impactful bets—the fear of missing out, and the need to respond to every competitor, every lost deal, every customer request. These are all understandable reactions.

But in this case, they need an intervention and a reset on what focus really means in a product organization. In my experience, many organizations need this intervention.

Let's talk about what an organization that doesn't know how to focus on what's truly important looks like.

A few years ago, one of the execs of the music service Pandora shared the “Pandora Prioritization Process”—the company's process for deciding what to work on and build.¹

The process involved letting stakeholders “buy” the features they wanted from the feature teams until their budget ran out.

I had not worked with them, but when I read this, I immediately recognized the complete and utter absence of product strategy and especially focus. Not bad product strategy—literally no product strategy.

Combined with their dependence on feature teams and their lack of any sign of true product management, it was clear this would lead to many features built, but little in the way of results or innovation, and the company's inevitable decline.

And over the next several years, that's just what we saw. A stock that IPO'd in 2011 at $16 a share kept steadily dwindling until, at about $8 a share, they were finally sold off.²

For years, I've been sharing the Pandora example as a clear case study of how not to do product.

In most companies it's not quite so obvious, but so many companies have some similar sort of stakeholder‐driven roadmap process, where they basically are trying to find a way to “fairly” divide up the engineering capacity across the different business stakeholders.

This is very much what I mean by feature teams striving to serve the business, versus product teams striving to serve the customers in ways that work for the business.

This is an especially clear example of the lack of product strategy, a lack of focus, and more generally, a lack of product leadership.

To be fair, this way of working is rarely desired by the head of product. Rather, it is usually the CEO and stakeholders that want to work this way, and the head of product is forced to serve as the facilitator.

Whatever the reason, this is an example of a company that is prioritizing but not focusing.

It is easy to generate work with this approach, but not results. As Stephen Bungay explains:

Generating activity is not a problem; in fact it is easy. The fact that it is easy makes the real problem harder to solve. The problem is getting the right things done—the things that matter, the things that will have an impact, the things a company is trying to achieve to ensure success.³

This is one of the most important lessons in leadership, and successful leaders have learned this one way or another.

Even though I (Marty) learned this early in my career, this lesson was etched in my mind and I've found that this principle applies in so many aspects of a technology business.

When I was a new software engineer, working in HP's applied research lab, I was fresh out of college. This meant that I knew something about the theory, but very little of the practice.

The way we worked at the time was using a practice referred to today as pair programming, where I was paired with a much more experienced engineer and we wrote software “together.” I use the quotes because the truth is that he did most of the writing, and I mostly watched and asked questions.

We were working on fairly low‐level systems software, for which at the time—and still is the case today with certain types of products—performance is key. Systems and applications were often so slow as to be unusable. So “performance optimization” was one of our ongoing responsibilities.

The good news was that, for pretty much any area of code that we would examine, it was not hard to think of ways to refactor to improve the performance. I kept pointing out areas that we could improve, but he kept saying, “We could, but no.”

Finally, he said, “Okay, time to work on performance,” and he proceeded to bring up our performance analysis tool, which let us measure the performance of our software. We could very clearly see where the time was actually being spent.

He pointed out that, while pretty much the entire code base could be improved, the vast majority of this effort would not matter in the least. In fact, it would not even be enough to be perceived by the user.

However, there were a few spots where almost all the time was going, and if we could improve those few areas, we could make a real impact. So that's where we needed to focus.

He pointed out that in most organizations, they tell everyone that “performance is important,” and so every team works a little on performance. But the vast majority of that work makes absolutely no difference. And, in the few places where it could make a difference, it gets too little concentrated attention.

This was a very tangible example of the power of focus, but more generally this is the situation I see in so many companies when it comes to focus and product strategy.

By not picking your battles and focusing on the few truly critical problems, most of the work going on does not make an impact. And for the truly critical priorities, there is not enough attention to actually move the needle.

There is also a very practical reason to focus on just a few truly critical problems.

Most tech product people know about the concept of work in progress (WIP) limits. It's an especially common concept in product teams using a delivery process such as Kanban.

It essentially says that we'll get more work done (throughput) if we limit the number of things our product team is working on at any one time. For most teams, it's a few items. If you don't have these limits, then work piles up at bottlenecks and we end up constantly switching context, and as a result, get fewer things out the door.

Not a difficult concept, and most product teams see this play out on a daily basis.

However, while this concept is definitely useful at the level of a product team, it becomes absolutely critical at the level of the broader product organization.

When an organization has 20, 30, or even 50 “high‐priority” objectives, initiatives, or projects all going on at once, we have the same problem, only much worse.

First of all, if you have even 20 high‐priority initiatives, that is likely going to overwhelm your organization. Each team will struggle with delivering on those initiatives, versus trying to take care of their customers or otherwise pursuing the purpose of their team.

Second, there is a real cost to an organization, and especially to the leadership, for each high‐priority effort or initiative. This cost involves management time, decisions, monitoring and tracking, staffing issues, and more, and the same concept of WIP limits applies here.

The bottom line is that an organization will get more critical work accomplished if it focuses on just a few items at a time.

So we need to pick our battles based on what really matters, and we need to limit the number of major battles we're trying to pursue at once.

Richard Rumelt reminds us that every good product strategy begins with this focus:

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.⁴

If the leaders are not willing or able to make these choices, then the product strategy is doomed from the start.

In the next chapter, we'll consider how we identify and leverage insights on these few critical problems we've decided to focus on.