Business Strategy vs Product Strategy: How to Operate with One Strategy and Win 

Do a quick search for “business strategy vs product strategy” and you will find a very long list of articles insisting that these are two different things.  Countless authors write that executives decide goals like “increase revenue” and then the product team sorts out how.  Dig a little deeper and we quickly see the root cause of the problem: a fundamental gap in understanding of what it takes to create high performing teams.

In this article I am going to offer a different answer to the “business strategy vs product strategy” question. One that will help you structure your organization and teams around your strategic priorities and be more effective as a result. I will cover:

• The concept of One Team, creating value
• How business strategy vs product strategy should, in fact, be One Strategy
• How to operationalize around One Strategy and structure your teams to succeed

In order to succeed, we need to embrace this concept of One Team.  The business, whether 10 employees or 10,000, is one team.  That one team is working toward one ultimate goal – solving valuable problems for our target customers.  Each of us has differing skills and levers at our disposal and contribute to this goal in different ways.  Whether an engineer or a sales rep or a customer service agent, we are all on the same team contributing in our own unique way toward the same goal.

Let that sink in.

Businesses are not composed of product, marketing, sales, and implementation teams.  A business is one team composed of people that use different tactics to achieve one goal: creating value.

What follows when we internalize this as a fundamental understanding is subtle but immensely powerful in shifting the way we work and what we are able to achieve.  

Let’s talk a bit about what it means to be one team.  Then we can talk about what it takes to develop a meaningful and robust business strategy.  And then we can consider how we can abandon the division of “business strategy vs product strategy” and use the concepts of one team and one strategy to completely rethink the way we organize ourselves and our product development squads.  I will show you that by creating organization structures that reflect these ideas of one team and one strategy we can radically shift the performance of our teams and ensure that everything we do is driving us toward success.

How do we break business silos?  Shift to One Team

In his bestselling book, The Five Dysfunctions of a Team, Patrick Lencioni, introduces the concept of “the first team”.  He argues that the best leaders are the ones that prioritize their peers – their fellow leaders – over their direct reports.  This might seem a bit jarring at first, but think about what it means.  What happens when the head of product prioritizes the needs of the head of marketing over the needs of her direct reports?  To be able to do that, she would need to understand what marketing does, how marketing works, and how marketing is contributing to the business goal. And then she would need to think about how to use the resources she has available to her to help.  In other words, she would need to be truly collaborative.  

This is what it means to break silos.

Now let’s extend this concept of “the first team”.  What if every employee was in on this?  What would it look like for every employee to shift their concept of their first team?  What would it take for engineers to no longer think of themselves as a part of the engineering team but rather as a part of the One Team that is the business and – crucially – have that association come first?  

In product leadership conversations we often talk about how important it is for product managers to be in continuous dialogue with peers across the company.  I have argued before that the product manager is actually like a mini-CEO.  She is in the middle of a fly-wheel taking in and sharing information across the customer, customer success, data, design, engineering, marketing and sales in order to continually identify, build, and take to market solutions to high value problems.  She has to be the ultimate collaborator.

What if every person in the company felt a responsibility to deliver value in this way?  How can we shift the structures we have in place to make this inevitable rather than just an aspiration?

Hold onto that thought.

Business Strategy vs Product Strategy?  Wrong question.  You only need One Strategy

There are countless, and I mean countless, books on strategy.  Richard Rumelt, in his book Good Strategy / Bad Strategy cuts to the chase:  “Good strategy is not just “what” you are trying to do. It is also “why” and “how” you are doing it.”

It really is that simple.

As a business, we need to decide what we are going to do. What customer set are we going to go after, in what regions of the world and what problems we are trying to solve for them.  And then we need to be able to articulate why we are the best placed to do this and how we are going to go about doing it.  This is the definition of business strategy.

Andy Grove, the former CEO of Intel and father of OKRs, famously said that every employee in the company should be able to tell you the company strategy.  It needs to be that clear and that relevant to them.  

As leaders, it is our job to articulate the strategy.  But it is impossible to do this effectively and successfully in a silo.  I spent years developing strategy at a huge global company called RELX (owners of LexisNexis, Elsevier and also Comicon).  It was always a collaborative effort that required input from every department at multiple levels.  We all needed to agree on what we were going to do, why and how.  And then we could each take responsibility for one piece of the how.

So, business strategy vs product strategy? They are the same thing.  It makes no sense to think of them as different.  Product is one tool in the box.  It is one of the “how”s.  

When we use the word “aligned” we are implying that teams are separate.  It may seem trivial, but words matter.  The way we talk about things shapes how we think about them.  If we’re asking about business strategy vs product strategy and  answer that “product strategy needs to be aligned with business strategy”, we are setting ourselves up for siloed thinking and working.  This is the antithesis of high performing teams.  We are not setting up for success.     

How to Operationalize One Team, One Strategy

When I talk about these concepts I usually get a lot of head nodding.  Yes, who doesn’t want collaboration across the business?  Yes, sure, “one strategy, aligned strategy – whatever, same thing”.  Absolutely, “business strategy vs product strategy – they should be the same. Gotcha”. We can agree with the concepts easily.  But what does it mean to operationalize these ideas? How can we create organizational structures that make these ideas of one team and one strategy inevitable rather than aspirational?

Reed Hastings, founder of Netflix, once told a reporter that he hates making decisions.  He prefers to create autonomous teams that can make decisions on their own.  Of course, this is only possible if the strategy is clearly understood by all.  Good strategy serves effectively as the guardrails for decision making.  You know you have a good strategy when you can pass what I call The Hastings Test.  Does your strategy tell me enough to enable me to make decisions on my own?  Yes?  Excellent.

How do we create OKRs that are actually helpful?

Once we have a clearly articulated strategy we can start to create OKRs.  Objectives should be those goals that, as a company, we need to deliver together.  I see so many companies fall down right here.  They start to separate out financial targets and come to see these as company goals.  They immediately lose sight of the market.  We want to use OKRs to guide execution of our strategy.  So OKRs need to be extensions of that strategy.  OKRs need to be the guardrails for the what and how of execution.

Ok, so let’s say that we’ve managed to set good OKRs.  Let’s say our company objectives are:

1. Grow market share in XYZ new segment 
2. Expand value for our existing segment

Great.  Now we have OKRs that are relevant for all of us – One Team.  We can all see very clearly exactly how our roles fit with the goals of the company. As a product leader, I know exactly what I’m supposed to do.  And I know that I only succeed if every one of my peers also succeeds.  Excellent, we are starting to set ourselves up for collaboration.

Ok, now what to do with my teams?

It is very common practice to organize engineering around pieces of the platform: the authoring team, the mobile team, the distribution team, etc.  And then it follows to create roadmaps for each of these teams.  The distribution team is going to do these things now, those things next, and the other things later.  But what about the OKRs? Ah, well we can just rejig and shuffle to show that this relates to that OKR and this other thing relates to the other OKR. This reshuffling and rejig of communications to appease stakeholders is so common that we have software to help us do this.

Please stop.

The need to create multiple views of a roadmap shows me that we are not set-up for success.  We are thinking about engineering and product development as somehow separate but “aligned” with the business.  We think executives are stakeholders to be appeased, not members of our own One Team.  This is not a recipe for success.  

How can we change this?

Organize your teams around your OKRs

What I now do is set up my teams and engineering squads around OKRs instead of around parts of the platform.

That is a really fundamental change.  Subtle but critical.

And, it’s important to remember, I don’t have a business strategy vs product strategy division here.  The OKRs that lead our work are all from the same set of OKRs – those relating to the business’ One Strategy. 

Say I have the 2 objectives articulated above and I have 100 engineers.  The first thing I do is decide on resource allocation for each Objective. This is actually a great exercise to do with the Executive team.  We can decide as one team how many engineers to allocate to each objective.  Let’s say we decide 60% on growing in the new segment and 40% on growing in the existing segment. Now we have a clear articulation of investment aligned to our strategy.  I can then quickly allocate the rest of the roles – PMs, Design, Data, Product Marketing – accordingly.

Next we break into squads and decide on KRs (Key Results).  Each squad has the resources they need to drive their assigned KR and the permission to work on any part of the platform.  We no longer have engineers that are assigned to one part of the platform or another.  The team can do anything they need to deliver on their KR.  Hello, autonomous teams! 

Say I have 8-9 squads working toward growing in the new segment.  We can break that Objective down into smaller pieces and assign each team to one piece.  I try as much as possible to assign KRs that are metrics to be moved. This opens the realm of possibility.  What could we do to move this metric?  Any part of the platform is fair game and the team has to draw on every part of the company to be successful.  This leads to built in collaboration that in turn drives more experimentation and more innovation.  It is a beautiful thing.

(Of course, we don’t want teams running into each other so we also set up a governance team composed of the leads from each squad.  They meet regularly to talk through dependencies and order of operations.)

Right within

We all want to win.  We all can agree in theory on what it takes to win.  We need a well thought through and clear strategy that every person in the company can recall easily and repeat when asked.  We need high levels of true, productive collaboration. In short, we need not stop thinking about “business strategy vs product strategy” and embrace One Team focused on One Strategy.   

These are things we can easily convince ourselves we already do.  But operationalizing these concepts of One Team and One Strategy is where companies often fall down.  It requires us to break free of the inherited ideas about how teams should be organized and how we relate to each other as employees of the same company.  It requires leaders to set up structures that make collaboration and goal orientation inevitable.  

When we are brave enough and clear eyed enough to really internalize and bring these concepts to life, we set ourselves up for achieving so much more than we ever thought possible.

Let’s talk about output vs outcome, which one you should focus your attention on when, and why it matters.

Trust me, understanding this can be a game-changer. It’s a pretty crucial concept in Product Management, and it can really change how you think about both developing your product and strategizing for your business.