Have you ever worked in an organization where a strategy exists, but you don’t feel like you can effectively execute on it, as every team has different priorities? Or worked in a team that doesn’t feel like it can do anything to contribute towards the strategy?
Far too often, product leaders are scared to shift their teams to really focus on the strategy and common goals. Instead, we organize our teams around functions such as particular products, or particular elements within a product.
There is some value in this, but it doesn’t always mean that you’ll be working on the most valuable opportunity in the organization. Sometimes, you’ll just be filling time.
So what’s the answer? You need to craft an amazing strategy and align your teams around this to achieve this effectively. Is this easy? Not necessarily. Does it have a huge impact on the value your product teams can deliver? Absolutely.
Table of contents
- What is product strategy?
- Bridging the gap between strategy and execution
- The downsides of traditionally structured product teams
- How to align your teams around the product strategy
- Product strategy skillset and teams
- Product team structures
- Team set-ups that you can use
- Setting your product teams up for success
- Key principles when setting up teams
What is product strategy?
Product strategy is the bridge between vision and execution. It clearly states the key bets you’re making. Product strategy highlights where you want to focus and your rough plan of attack.
If you already are sold on product strategy, know how to create one, and now want to understand how to maximize the value of your product strategy, keep reading.
Bridging the gap between strategy and execution
Organizations tend to face less difficulty creating the strategy than actually executing on it. 61 percent of respondents acknowledge that their firms often struggle to bridge the gap between strategy formulation and its day-to-day implementation.
One of the main reasons why teams struggle to bridge the gap is that the strategy doesn’t become the main piece of the puzzle for the organization. It exists, but teams continue to work on their own agendas and the strategy doesn’t really influence what they do.
One of the most effective ways to solve this is to use your product strategy to structure your product teams. This allows your product strategy to become the centerpiece of your organizational design.
The downsides of traditionally structured product teams
Most product organizations are set up with teams that are focussed on a particular area of the product, or vertical. This often leads to siloed ownership. Teams are often domain experts and can deliver code quickly in their area. However, they’re also less flexible and agile.
Teams are also often made up of only product, UX/design, data, and engineering. They therefore have other parties sitting external to the team such as sales/commercial, legal, marketing, and customer success. This also leads to siloes across the organization.
Learn more →As a result, different teams and different departments have competing priorities. This leads to conflicts of interest on what to work on.
The solution? Aligning your teams around the product strategy to unlock value.
How to align your teams around the product strategy
To achieve this, you need to have an effective product strategy and a rough implementation plan — meaning that the product priorities have been broken down (at least on a yearly basis). You should have also conducted capability analysis to see where you have gaps and know what kind of teams and skillset you might need to plug these:
As I also mentioned previously, this doesn’t have to be set and done — you can involve teams to get their thoughts and opinions and assess what focus is needed. Just make sure you carve out some time for them to be able to do this.
Now that you have all of your essential ingredients you can start to think about how to align your teams around your product strategy.
Product strategy skillset and teams
For each strategic pillar, you’ll need to assess who you need to be involved to deliver this effectively. For example, if strategic pillar one is about launching your product in a new market then you will likely need to involve:
- A capability product team, for any changes needed to allow you to deliver in this market
- A front-end product team, for any changes to the consumer facing element of the product that are needed to be successful in that market
- A marketing team, to define and execute on the strategy for that region
- Legal input to ensure compliance in the market
- Commercial input, to assess how you best sell in that market in a financially viable way
- Within your teams you also likely need a combination of product, engineering, test engineers, data, UX and research skills
Traditionally, each of these teams and departments would be separate functions, with their own priorities.
A capability team might operate as a supporting team for multiple areas, and therefore find it hard to prioritize and remain focussed on the main goal, or they might have their own competing objectives.
A commercial team member might have their own agenda, and their own priorities of features that they think would be important to implement (for the good of the overall profits), but as they have their own individual department-led goal, it might not fully align with what the overall priorities are when considering effort, customer needs, marketing, and long-term growth.
More great articles from LogRocket:
- How to implement issue management to improve your product
- 8 ways to reduce cycle time and build a better product
- What is a PERT chart and how to make one
- Discover how to use behavioral analytics to create a great product experience
- Explore six tried and true product management frameworks you should know
- Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
You might also find that the skillset and teams need to change over time. This can still work by rolling teams on and off an objective.
Product team structures
You can structure product teams by:
- Having one “normal-sized” team dedicated to the pillar that still able to contribute code to other areas
- Having multiple teams working on the project, but they work in alignment towards the same goals
- Placing more engineers in one team to allow them to achieve the goals in different spaces, but keep the product function smaller
There are pros and cons to each of these approaches.
“Normal sized” is typically a product team with one PM, up to five engineers, a test engineer and the right supporting functions.
Depending on the size of the organization, and complexity of the code base, it could be that one team is sufficient to achieve all of the goals that you need to execute against the strategic pillar.
If the team has the right knowledge and skill set, and can be agile and not pass through too much bureaucracy, it’s likely that they can contribute to different areas of the product either through coding directly in that space or agreeing to merge in code with the appropriate team.
The benefits of this are that:
- Retaining one small team to work through this keeps the team focussed and they can easily achieve their goals
- There are less supporting functions needed, as there are less people working in the space
- The team can quickly and easily make decisions amongst themselves
The downside is if the process / code base is too complex. Having one small team in that instance is likely to mean that the team sees really slow progress.
If your organization is large and complex, and you already have multiple teams that are assigned to different areas of the product, you may choose to retain these team set-ups, but set them on the same strategic goal.
This works well if the teams aren’t expected to contribute to other work or be pulled on to any other strategic pillars.
Teams can then self-align and work out how to work together to contribute effectively to the strategic goals.
If the teams are expected to have their work split across competing goals, and contribute to multiple business objectives, then it can become really hard for teams to remain focussed and make decisions.
Placing more engineers in a team can work extremely well, if the engineering team is self-sufficient, understands the product goals and can make decisions and have conversations to drive their work forward without supporting functions.
This can help to alleviate issues that you might see with speed in approach one, while also reducing the complexity of having multiple teams and potentially different opinions.
Overall, the best approach (or combination of approaches) to take, depends on your organizational set up, processes, and the complexity of the code base.
Team set-ups that you can use
Once you’ve established the approach you want to take with your product teams, you want to assess how you align with other departments on your strategic pillars.
To achieve this, you already need to be aligned at the strategic level on what the most important goals are.
There are a few different variations of team set-ups that you could try, again, depending on your organization and what you think will work for you:
Working groups
Working groups are a great way to align people around a strategic pillar, if you don’t need too much dedicated input from these people to achieve that goal. For example, this works great in the kind of example where you might need a small bit of legal input, but you’re not working on something that will be completely dependent on the legal approach.
Working groups allow you to align the right people that are needed to make a strategic pillar successful.
The right people should be involved in creating goals and understanding what needs to be achieved. You can then continue to have regular check-ins with them afterwards. When you set up a working group, people should know what is expected of them to make this goal successful, but they also can reserve most of their time to work on other projects and their day-to-day business needs.
If you need more dedicated time from people — say if they are crucial to the success of the pillar — then you’ll need to explore one of the more intertwined team set ups.
Nuclei teams
The typical product nucleus contains UX, engineering lead, and the product manager. The idea behind this is that all three of these parties have a stake in deciding the direction and areas of importance to allow them to progress. These three functions will meet up on a more regular basis than the whole team to discuss their insights, learnings and what approaches to take.
This approach can be expanded further to contain other functions that are critical to the success of the strategic pillar. For example, this might include someone from commercial, data, or customer success, depending on the area in which you are working.
With this, you can form a tighter working group that meets more regularly. These people might still have other priorities, however, they’re more dedicated to the success of this strategic pillar than they would be if they were part of a working group. They might have their own personal goals and objectives that highlight the priority of the work that they are doing on this strategic objective.
People in this space should be fully invested and available to make the pillar a success.
Full squad integration
This is the best approach to take when people need to be heavily involved in the success of a Product. This doesn’t necessarily mean that people join the product team as a function — it might be that the strategic pillar is led by another department, but they’re fully involved in the product and understand the customer and trade-offs that need to be made to make the product a success.
The idea behind full squad integration is that:
- These people share the same goals
- They all have the same responsibility for the success of the pillar
- They work together as one group, as opposed to different groups of people that depend on each other
- They are continuously collaborating, sharing learnings and inputting into what they do next
The dangers of operating in this space could be that you have too many people and too many inputs. There is also a danger of involving people in the product team if they don’t fully understand how to do product well.
You might only want to embark on this path if you have a very mature product organization that takes a product-led approach and everyone understands how to do this well.
Setting your product teams up for success
No matter which approach you take, there are some key elements that you will need to embed to ensure that you successfully align everyone to achieve the goals.
Key steps to work through are:
- Clearly communicating the strategy — providing the right level of context and detail for teams to be able to know what they need to do
- Providing more granular goals for the team. Instead of just providing the high level strategy, you might also want to provide some clear OKRs for the team on a regular basis, so they have more direction on what they need to achieve
- Allowing teams the time to form, especially if you have changed team structures
- Teams taking the time to run through ways of working, roles, responsibilities and understanding how they will work with the larger organization
- Teams having the ability to input and feed back up the chain on what is and isn’t working for them
- The ability to remain fluid, and change the approach or people involved to allow you to effectively reach the goals
- Set up the right reporting lines so you receive the right level of communication on progress against strategic goals and where support is needed, at the right frequency
Key principles when setting up teams
Personnel, structures and approach might change over time. The crucial thing is to follow some key principles that allow you to constantly evolve and learn the best approach to take.
In essence, don’t worry about getting this “right” the first time. It’s rare that anything will ever be perfect, and as with anything in a product, the best way to learn is by doing.
Keep the following principles in mind:
- Communication — Encourage an open, trusting dialogue. This allows you to create the space and have the conversations about what is and isn’t working, allowing you to make changes where needed
- Empowerment — Give the teams the direction they need to get started, but empower them to input and feedback their learnings so you can change direction where required
- Be fluid — Don’t worry about your strategy and team approach being perfect and set in stone. As teams get started working through different pillars, they’ll learn more and more about what they need to be successful, so allow your approach to be fluid and change
- Use your strategy — You should use your strategy on a regular basis. This allows you to bridge the gap instead of having a standalone item where teams aren’t sure how they can contribute to it.
Summary
By aligning your teams around your product strategy, you set yourself up as an organization to make sure that you’re working on the most important areas.
This allows you to live and breathe your strategy and constantly learn what is and isn’t working. Along the way you’ll also reduce silos and focus on increasing the speed that you reach your goals at.
Featured image source: IconScout
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
