Introduction & Anti-pattern #1: "Giving too much autonomy, too soon"
Break the loop of transformation failure. Avoid common pitfalls. Learn about their remedies.
Note: For this article series to be especially useful to you, I recommend reading prior content relating to the product operating model. If you haven’t, please start by diving into this article by Marty Cagan or pick up a copy of TRANSFORMED.
So, you want to move to the product model.
Well played.
But remember, the journey ahead is not without its challenges.
The essence of the product model is to decentralize decision-making. As a leader, you empower teams. You give them problems to solve, in the form of a strategic context, and the autonomy to figure out the right solutions for your market. In turn, the teams become accountable for driving outcomes. Instead of being the “smartest in the room,” you coach and mentor teams to increase their competence. This is a stark contrast to the traditional command-and-control leadership style.
I’ve seen firsthand how this transition improves organizations and teams. The main benefits are increased innovation, engagement, business results, and shorter “time to money.” Sounds pretty incredible, right?
But... please pay attention.
There are plenty of potential downsides if you poorly adopt this way of governing product development.
The fundamental aspect is that it requires not less leadership, but better leadership. Without better leadership, you will not see positive returns in empowering teams, you might just see worse outcomes.
For the last 10 years, I’ve had the good fortune of being involved in transformations, in some shape or form, toward what we now call the product model. Some initiatives have been bigger, some smaller. Some have been great successes, while others have delivered lackluster results. Together with amazing colleagues, we’ve faced our fair share of struggles, push-back, and collected some scar tissue to prove it.
In this article series, I will outline the anti-patterns my peers and I have observed in the field while helping companies move to the product model. These pitfalls are rooted in leadership challenges when it comes to empowering teams and driving change.
Let’s learn from them?
The anti-patterns
Giving too much autonomy, too soon
Focusing on parts rather than the whole
Not balancing innovation, business as usual, and keeping the lights on work
Pushing dependencies to the side
The CTO and CPO have different agendas
Losing momentum
Forgetting about the value of design and design leadership
Going “all in” at the same time
Leaders not talking enough about the “why”
Leaders talk the talk but don't walk the walk
Without much further ado, let’s begin with the first anti-pattern.
Anti-pattern #1: Giving too much autonomy, too soon
Some leaders might mistakenly see a shift to the product model as an opportunity to take a step back and simply let teams “do their thing.” Sure, that’s part of the equation, but what if teams are not given clear direction and are not competent enough to make the right day-to-day decisions? What would happen then?
You guessed it: chaos.
The sad truth: fast-forward six months or a year, and you'll experience this loop.
Ask yourself, when you see this flow of events, what’s the root cause?
That’s right: lack of leadership. Leaders who are laissez-faire. They are not doing the groundwork to create the environment and conditions for teams to flourish.
Now, let’s explore, and compare and contrast, different leadership styles and cultures to hone in on this pitfall.
Alignment vs. Autonomy
Below is a brilliant 2x2 matrix, created by Stephen Bungay and later adapted by Henrik Kniberg. When explaining the impact the product model has on leadership, this is an excellent concept to show the shift that needs to be made among leaders.
High alignment, low autonomy
In the upper left quadrant, you have a command-and-control leadership style. The leader is telling you what the objective is but also exactly what the solution should be. The direction is clear, but teams lack motivation.
For instance, as the current zeitgeist goes, leaders are urging teams to build AI capabilities, a solution that most likely lacks a problem. Teams I have spoken to, who have found themselves in these situations, find this leadership style disheartening because it lacks dialogue: the solutions are definitive and leave little leeway. The team is expected to march toward finishing the task without asking any questions. Not exactly an inspiring environment.
Low alignment, low autonomy
In the lower left quadrant, leaders lack a distinct direction. A common scenario would be that they jump from idea to idea – new brilliant “master plans” are shared every week. When teams hear a new idea, they scratch their heads and think, “Oh well, yet another idea.” And, as a defense mechanism, they prioritize their own work to keep their sanity. The big problem is that the boss might come by and ask teams what they are up to: “Why aren’t you working on the ‘big great idea’?” This is a recipe for disaster that I have unfortunately experienced in some startups/scaleups (with limited traction, that is).
Low alignment, high autonomy
In the lower right quadrant, you have autonomous teams, defining their own work. They pick and choose what’s most meaningful to them. They are engaged, but they lack alignment.
I have seen this pattern among government-funded organizations or organizations that have business models that are not in direct threat. The business is humming along, growing steadily.
So, imagine this type of product organization: the team topology is structured around specific channels such as a “mobile team,” a “web team” and an “in-store team.” Essentially, a team owns a specific technology that powers a certain channel. Each team defines their own work.
When you would walk around the office to have a friendly chat with teams and ask the fairly straightforward question: “What are you working on?” you might hear “Improving search” from a member of the Mobile team, with a slight smile, and when you would ask the same question to a member of the “Web team,” you might receive the same reply, also with a smile. The teams are happy. They have autonomy, but – big caveat – there is a lot of duplicate work and a fundamental lack of alignment.
High alignment, high autonomy
Where empowered teams flourish, and what the product model is all about, is the upper right corner. In this way of operating a product, leaders share the strategic context as problems to solve for teams, and teams figure out the right solutions to these problems by doing product discovery.
Let me try to make this a bit more tangible for you.
A story from the field:
When I worked as a product leader at a fintech company, we developed a product strategy centered around three main problems for teams to tackle in the coming years. One of these problems was addressing the two types of users on our platform: A) users who knew what financial products to buy and had the in-depth knowledge to make decisions, and B) users who were struggling and needed guidance. We weren’t being helpful to the latter group. These users yearned for something simple, something easier to digest. As product leaders, we shared that story, along with the insights and data to support it. We didn’t provide a specific solution or idea on how to solve it, instead, we presented the “strategic context” and the core problems to solve.
Now, let’s go deeper, and explore actionable steps you could take to avoid this anti-pattern.
How to avoid this anti-pattern
To avoid the loop of transformation failure, you want to give autonomy – and – at the same time create alignment. However, there is another pivotal aspect as well – competence.
Here’s an example:
The traditional way of governing product development has been to fund projects. You might not call them projects, but “features” or “initiatives,” but that’s what they are: pet ideas of stakeholders from the “business.”
The business could be sales, marketing, customer service, and other stakeholders in the company. Amongst themselves, they listen to customers (hopefully) and brainstorm ideas that will make their function or department more successful.
The product organization receives these requests, and they are put on a roadmap with a deadline. Here, the product organization is subservient to the needs of the business. What we are trying to address with the product model is to shift the dynamics, and change the playing field. Product development is now in the driver’s seat on what to build.
Here comes the tricky part. This is a big mental shift for teams and leaders. You have to learn and unlearn skills. Instead of being handed features to build by some vocal stakeholder, you need to figure out your own roadmap, your own backlog, and product leaders need to do the balancing act of providing you with fruitful problems to solve while paving the way for you to be empowered and not micromanaged by the business.
This is where you come in.
To avoid the loop of transformation failure, you need to create the right environment for teams to succeed. You do this mainly by:
Creating clarity of direction: Where you are going and why this is a valuable path for the company, in the form of a product vision and a focused product strategy.
Coaching, mentoring, training and staffing teams to be more competent in the new skills required to make the shift.
Competence and clarity are the foundations of autonomy, as succinctly visualized and explained by David Marquet.
Let’s discuss these two aspects in detail.
Increase competence
In the product model, you are dialing up cross-functional collaboration. You are introducing new roles such as a product manager and a product designer within teams, and pairing these new roles with a strong tech lead who can be a sparring partner in product discovery activities. The team is now accountable for figuring out the right solutions to solve specific problems for the business and its customers, formed as team objectives. This requires, first and foremost, skills in the following practices:
Connecting strategy to outcomes: As a team, you need to understand why you have been assigned a particular problem to solve, its strategic context, and how you could translate this goal into tangible, valuable solutions for your market.
Product discovery techniques: As a team, you need to be competent in both problem discovery, understanding the needs of your customers and business stakeholders, and solution discovery, quickly ideating, prototyping, and validating solutions in the market to connect to your team objectives.
Stakeholder relationship building: As a team, you need to actively engage with key stakeholders to foster transparency and understand the business' constraints, financial metrics, go-to-market strategy, compliance requirements, and more. Building these relationships is crucial for gaining the trust needed to take the lead in defining what to build.
Obviously, there are more skills that are needed, but these are the three highest-leverage ones to achieve quick results.
Create clarity of direction
Your job as a product leader is to provide strategic context to teams, meaning teams need to understand their part in the grand scheme of things, why they have been assigned a certain team objective, and how that objective is connected to the overarching direction of where you are taking the product.
“‘What should we work on?’ is a very easy question to answer.
‘What should we work on so that we win?’ is a more difficult question to answer.”
- Shreyas Doshi
“Good strategy isn’t a detailed plan. It’s a framework that helps you make decisions.”
- Melissa Perri
Your narrative when talking to teams should be about how their contribution will make you win now and in the future. The story should win the hearts and minds of the teams, showing that they are working on something meaningful.
What you could try
Up until this point, we have explored the importance of creating an environment where teams can flourish and develop their new competencies, with leaders providing an engaging strategic context. However, we haven’t yet explored tangible actions you can take to build these pillars in your organization. Here are a few concrete recommendations:
Create or update your product strategy
If you don’t have a meaningful product strategy, create one, using practices from Good Strategy/Bad Strategy or Gibson Biddle’s framework
Draft a first set of OKRs for a pilot team
Dive into this excellent article series by Felipe Castro to learn how to best shape your OKRs.
Assess your teams’ competence
Assess and create coaching plans for your Product Managers, for instance using Petra Wille’s PM wheel or SVPG’s assessment framework. Have your engineering and design counterparts do the same.
Train teams in product discovery techniques
Coach, mentor and train teams in product discovery techniques such as user research, product risk mapping and Teresa Torres’ opportunity solution trees
Facilitate a leadership workshop around “mandate levels”/levels of autonomy
Invite senior product leaders to discuss John Cutler’s classification of mandate levels from A to I. The conversations will likely spark reflection and change in your leadership stance.
Key takeaways
A fundamental tenet of the product model is giving autonomy to teams. To avoid the loop of transformation failure, ensure that your teams have the right environment to succeed. They need to be competent in the new skills required, such as product discovery, and have a clear understanding of the product's direction. As a product leader, your job is twofold: A) Assess, coach, mentor, and train your teams to enhance their competence; and B) Tell the story—provide the strategic context of why you’ve assigned a certain problem to a team and why it’s a meaningful problem to solve.
Next up
Up next, we’re going to explore the second anti-pattern: “Focusing on parts rather than the whole”.
Thank you to Mathias Holmgren and Martin Christensen for providing feedback on this article.