Most companies fail in execution, not strategy. Clearly defining and communicating strategy to your teams can close the strategy-execution gap.

“Culture Eats Strategy for Breakfast.”

Peter Drucker

Though there is wisdom in Peter Drucker’s experience, I’ve been a part of a number of growth-stage companies with healthy cultures of execution that failed to execute on high level strategy. In these cases, my observation is that the true failing was in the definition and communication of the strategy rather than than a cultural inability to execute. Through these failures, I’ve come up with a framework for defining, layering, and communicating an effective product strategy that can close the gap between strategy and execution.

Why Defining Product Strategy is Hard

Strategy Overload

One of the challenges with the word “Strategy” is that it is an overloaded term. Every function within a business needs to operate within a strategy.  There may be a sales strategy, a marketing strategy, and product strategy, and operational strategy, an technology strategy, etc.  And to top it all off, there may be an underlaying or over-arching corporate strategy, and if it’s a large organization then there actually may be different business unit or divisional strategies.  This can get confusing, since all of these different artifacts are described as a strategy, but are each completely different things.

Diffusion of Focus

Product strategy is especially tricky because of the centrality of a product to any business. It it at the intersection of customer, tech, and business which means that everyone function in an organization is impacted by the product. Sales has to sell it. Marketing has to talk about it. Engineering has to build it. Ops has to support it. Customers have to buy it. All of these functions have a stake in what the product is and how it is delivered, and they all know exactly what THEY need the product to be, but not necessarily the other functions in the organization.

Furthering the challenge is that each of these functional areas tends to be rather myopic in nature. A sales rep is going to be focused primarily on how they can sell the product to customers this quarter, and not necessarily on how much it costs to operate or long term sustainability. A marketing person is going to be focused on what type of stories they can tell in the marketplace to bring in leads, but not necessarily the limitations or hidden downsides of a product. An operations person is going to be focused on reducing the number of customers who are actually calling in for support on the product, but not necessarily how quickly the product is shipped or how much revenue it brings in.

While focus and attention to detail is essential for each function to fulfill their role effectively, it is very challenging for a single person to be able to understand the details of their own function and also be able to understand the details and perspective of another, completely different and perhaps even competing function.

From a stakeholder’s perspective, why should they defer a critical strategy decision to a product manager who doesn’t share their same goals and objectives? It is this fear and lack of trust that can cause stakeholders to be vocal and prescriptive about what the product strategy should be instead of accepting a strategy defined by someone else.

The False Promise of a Corporate Strategy

In theory, the trust problem should be addressed by a strong corporate strategy which is defined ahead of time. This corporate strategy would then be used to align all other functional and product strategies. In my experience I’ve found that this is not often the reality:

• At a large telecom, I found that the most influential strategy was the one espoused by the largest business unit rather than an overarching corporate strategy, and this shifted from BU to BU over time and as technology evolved.
• At a large B2C media company, I found that there was an over-arching strategy but it was formulated with little input from each of the business units, which continued to operate independently and never actually made the sacrifices necessary to implement it.
• Within a B2B company, I found that there was alignment between the corporate strategy and the business unit strategy, but neither of these matched the functional strategies within the organization and were never implemented.
• When working with external “corporate strategy” consultants, I found the level of strategic work to be all over the place ranging from high level M&A recommendations to low level project management / implementation support, driven by the functional strategy of whoever was paying the consultant.

The implication here is that waiting for a higher order strategy to put everything in place is just not a realistic solution. It isn’t possible for an effective top down strategy to be fully formed and defined without the right level of context and data flowing up from the bottom. There is no silver bullet or magic formula that will make all strategic decisions clear for everyone.

This is why product management exists – to help organizations align top down and bottoms up strategies, as well as cross-functional strategies so that the best decisions are made at the right level with the appropriate amount of context and responsibility. But this is easier said than done.

A Clear Product Strategy has Four Levels

Getting lost in the maze of “strategy” can be very distracting for product managers. It’s not often clear how much time that a product manager should be spending on influencing or developing one, or at what level.

The following is a framework that I use (loosely based on the Scaled Agile Framework) to help navigate the strategy maze and to stay focused on influencing the appropriate stakeholders.

I’ve broken a Product Strategy down into four parts. Each of them is inter-related and needs to build from the bottoms up:

Level 1 – Team Strategy

Team strategy should be primarily focused on how a specific agile team can be maximize value delivery by prioritizing a backlog of specific tasks (commonly known as user stories). This is very tactical in nature and the focus here should be on maximizing value delivery (not velocity) of the engineering team. Is the team delivering value every sprint? If your team can’t deliver value, then there is no point in going any further because no matter what the rest of the roadmap is roadmap is, the lack of execution is going to kill you and you need to make sure you have the right team in place to actually build things at all.

The key types of decisions that the team should be implementation decisions – who is working on what, what the UX/UI should be for a specific feature, and what technology choices should be made to ensure a high quality product. Each of these decisions should be relatively contained and be able to be made by the agile team without any external dependencies. If you are finding that many of these decisions requires external input, then your team might not have the right skillset for the job and/or may not be constructed correctly.

The key stakeholders at the team level are the people who comprise the team – engineers and designers for the most part. In some cases (with truly cross functional teams, such as a growth team, then there may be other functional leads like data analysts or SEO managers. These are the key team members who will actually be doing the work and it is critical for the Product Manager to influence them and help them understand how they are contributing to the team strategy.

A good team strategy should be able to be laid out in a roadmap of key goals that the team will be aiming to accomplish over the next quarter, along with

Examples of strategy decisions that need to be made at the team level

• How much tech debt to pay down
• UX/UI decisions and flows
• Tech stack choices (i.e. MongoDB or SQL)
• Scheduling/Alignment of specific tasks with resources on the team

Some questions to ask to see if you’re building a team strategy correctly would be:

• How is the backlog of user stories being prioritized?
• What is the size and composition of the team and are they a match for the work required?
• How are you measuring the effectiveness of the team?
  
  

Level 2 – Program Strategy

Program Strategy should be focused on making sure that multiple Agile teams can work together to deliver something more significant and that the resulting team of teams is still delivering incremental value to the business. In Scaled Agile parlance, this team of teams is referred to as a Program. The role of the product management leader at this level is really to focus defining, measuring, and optimizing the value that the team of teams delivers as well as communicating to the teams how they are contributing to the program strategy. The product manager should not be focused on implementation level tactics such as dependency mapping, risk mitigation, or inter-team communications as this will be distracting from their primary goal of making sure that the team of teams is delivering the right business value.

The key stakeholders for the product manager to care for and influence at this level are the tech leads, architects, and operations leads. These are the experts of the organization within a specific domain, and have a large role to play in how different pieces of technology will interoperate with one another (architects), knowledge transfer and sharing of legacy systems (tech leads), and institutionalization of any changes in operating models or processes (operations leads).

Examples of decisions that need to be made at the Program level:

• How much architectural runway do the teams have to work?
• How will different parts of the system inter-operate with one another?
• What kind of standards need to be put in place for each team?

Some questions to ask yourself to see if you’re building and communicating program strategy correctly would be:

• What value are these teams working together to deliver?
• Are the handoffs between teams working effectively?
• Does each team understand why they’re doing what they’re doing?

Level 3 – Solution Strategy

At scale, teams of teams aren’t enough to completely solve a customer problem. There are some problems that require a significant amount of agile teams (a good rule of thumb is more than 5) to work together with focus on a specific solution to a problem. Another type of problem that fits into this category is when there is an extremely high degree of cross-functional involvement or organizational transformation involved.

For example, let’s say you want to build a self-service trial capability into your product. That’s great! You’d scope out a number of self-service oriented features like credit card payments, usage tracking and analytics, self-provisioning and account creation flows, on boarding flows, and off boarding flows, decompose them further into user stories build them out in your Program/team backlogs and execute them. But when you’re done, then what?

This type of change is so significant that other functions within your organization will also have to make significant changes and investments. In this case, what needs to happen is that your business has to build a capability to actually execute a marketing led or product led go to market motion – which would create an entire backlog of work for finance, sales, marketing, and your product and engineering team might not even have the ability to influence any of the systems and processes that they use. (for example, CRM systems, or billing systems)

Solution strategy is critical as these types of transformations need to be managed at the organizational level and have a much higher degree of cross-functional complexity than a bolt on feature to an existing product line.

In my experience, this level of strategy is the hardest and most neglected. If the organization doesn’t understand that this needs to happen and dedicate the appropriate time and resources to these efforts, these strategic efforts are set up for failure and the product manager gets blamed for it. Even if the product manager tries to personally fill all of the resource gaps, they’re likely to run into roadblocks and a lack of engagement that ultimately will diminish their credibility, impact, and morale. This is where it’s really critical to educate organizations at this stage of growth on the importance of prioritizing all functional initiatives within in a single solution backlog and being willing to recognize the resource impact of these efforts.

Key stakeholders at this level of strategy would be your middle management leaders, those who have a good handle on both the implementation details as well as have the ability to allocate some resources around. Also important is to have the VP/heads of marketing and tech involved since the types of decisions that are likely to be made here are likely to highly impact brand/product messaging and engineering staffing/allocation levels.

Examples of decisions that need to be made at this level:

• Build / Buy / Partner decisions
• New Product Introductions / EOLs – not routine launches, but major launches – such as Introducing a SECOND product for a company with ONE product (startup), or Introducing a SECOND go-to-market motion for a company with one GTM motion. (i.e. sales led moving to product led)
• Technology / vendor selection/standardization decisions

Some self assessment questions to ask here would be:

• Are teams building things that are core to the success of our business?
• Can we accelerate our time to market by working with third parties?
• Are our product launches making a splash or a thud in the marketplace?

Level 4 – Portfolio Strategy

Portfolio Strategy is the highest level of strategy and should be focused on resource allocations at the company level. In an agile environment this boils down to staffing agile teams against specific capabilities. In non-agile environments this translates to Capex or Opex budgets.

It should also be noted that Strategy in and of itself is not the end-all be all defining framework of a company. There are higher order constraints such as Mission and Vision, which define what the company is about and why it exists. Vince Law does a great job diving into this in more detail on HackerNoon. These ideas of Mission and Vision should be viewed as design constraints for any Strategy and they should be things that already exist and put in place by the senior leadership team including the CEO. If this isn’t the case, it’s very difficult to define a successful product strategy since you don’t know where you need to go.

Key stakeholders at this level of strategy would be functional leaders of the organization (i.e. VP Sales, Ops, Marketing, Tech) as well as the head of Finance and HR. These leaders are critical to allocate staffing and resources to building the appropriate solutions for the market and for the company and they are the ones who can help their teams focus on a specific goal rather than trying to do multiple goals.

Examples of a portfolio level decision:

• New Market entry / expansions (i.e. international, or new product category)
• Acquisition of another company
• Spinning out a subdivision
• Major staffing level adjustments (hiring / RIF)

Some self assessment questions to ask here would be:

• Are we fully resourcing what’s most important?
• Do we have a list of great ideas that we’re NOT investing in?
• How much are we investing in the short term, mid term, and long term horizon?
  

Differences in Scale

I want to point out that not every company is the same. For an early stage company trying to find product market fit – the portfolio strategy, capability strategy, feature strategy, and dev strategy are all basically the same – build something that a customer will buy. The team is likely to be small so all of the nuances between a feature, capability, and user story won’t really make a difference since the same engineer might be the one building all of it, and the product manager might also be the one selling it. Further, it’s easier to change directions on a time as there is no legacy to support.

As companies grow, and more critically the portfolio complexity grows, the number of customers and the amount of organizational debt grows which makes it harder and harder to change directions quickly and the all of the features that were built previously need to be maintained unless there is a conscious decision to EOL them.

Roles are Important when Communicating Strategy

To communicate and execute a complete product strategy, It is critical for the entire product organization to work together.  For the team to be successful, each role has to be properly filled and each member of the team has their part to play in influencing different parts and different levels of the organization.

It’s very important for product managers/leaders/executives to know their role and their focus. When that doesn’t happen, bad things happen:

• I once saw a VP product who would spend too much of their time focused on implementation strategy, digging into technical and pricing details with engineers and sales reps.  While this isn’t necessarily a bad thing, this took away from their ability to successfully influence the Corporate strategy and drive alignment across other functions in the company, resulting in our team being forced to build conflicting features and enhancements that served diverging and inconsistent functional strategies.
• I’ve seen a Product Manager who aspired to be a VP.  This person spent most of their time to shape and influence the larger corporate strategy around sales, services, marketing, and operations at the expense of their primary role of working with their engineering team and writing user stories, acceptance criteria, and maintaining a backlog.  While this helped tactically with a few sales opportunities, it had limited impact because due to their ability to influence other functional VPs was very limited, and the engineering team grew increasingly frustrated with their Product manager’s lack of availability.
• I’ve seen a VP product who spent most of their much time focused on influencing Corporate strategies at the expense of spending time with their team, learning how the product worked, or how it was being implemented.  This ended up working out well with the rest of the organization, but at the cost of team morale and turnover as the team felt that their work was under-appreciated and or not visible in the operating plans of the rest of the business. 

When team members don’t understand or accept their roles, or don’t do their role and instead focus on a role they’d like to have instead, the strategy won’t be effectively communicated which will make it harder to actually execute. Lack of execution ultimately hurts everyone on the product team as stakeholders either see the product team team as ineffective in either vision or on tactics.

The diagram above is a framework for how I tend to approach this, within larger organizations. YMMV as not all organizations are the same, and titling from company to company (i.e. some titled VPs are actually acting as Product Managers), but I’ve found it helpful to be very clear about where everyone on the team should focus. Regardless of title, it’s important for the product management team to be fully aligned and to be able to trust one another so that they can focus on their area without having to worry about the others.

Wrap Up

Strategy is a tricky subject and the difference between a success and failure is often in execution. By being very clear about what the strategy is and by communicating it clearly to different pats of the organization, the gap between strategy and execution can be made just a little bit narrower.