Product Strategy – Focus
To continue with our series on product strategy, in this article I’d like to 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, yet won’t be able to do this year. 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 the leaders feeling the need to place a lot of bets, versus the best or most impactful bets; the fear of missing out; the need to respond to every competitor; to respond to every lost deal; to 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.
About five years ago, one of the execs of Pandora shared the “Pandora Prioritization Process” which was published in the otherwise excellent, First Round Review. The exec shared the company’s process for deciding what to work on and build.
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/share they were finally “put out of their misery.”
For years I’ve been sharing this article as a clear case study of how not to do product.
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.
Yet another clear example of feature teams striving to serve the business, versus product teams striving to serve the customers in ways that work for the business.
While common, this is an especially obvious example of the lack of product strategy, a lack of true 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:
“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.” – Stephen Bungay
This is one of the most important lessons in leadership, and successful leaders have learned this one way or another.
Even though I 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 which means 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, 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 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 consistently kept saying “we could, but no.”
Finally, he said, “OK, time to work on performance,” and he proceeded to bring up our performance analysis tool, which let us measure the performance of our software, and 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 like 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, getting 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 and each team is then struggling 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, involving management time, decisions, monitoring and tracking, staffing issues and more, and the same concept of WIP Limits applies here.
The bottom line is that organization will get more critical work accomplished if it focuses on just a few at a time.
So, we need to pick our battles based on what really matters, and we need to limit the number of major problems we’re trying to solve at once.
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.” –Richard Rumelt
If the leaders are not willing or able to make these choices, then the product strategy is doomed from the start.
In the next article we’ll talk about how we identify and leverage insights on these few critical problems we’ve decided to focus on.
