Most transformations fail. Here’s why.
Let’s talk about transformation.
For many people in our industry, that often means switching from a feature team model to an empowered product team model. Regarding this aspect of transformation (amongst others), everyone is talking about the same: Product leaders want their teams to think about outcomes over outputs. They want their teams to be “empowered”. They want to foster ownership. They really want to transform, and therefore they focus on changing how the teams should work… They think about competency and how their Product Managers need to step up. They change their Product Owner’s titles to Product Managers. Some of their senior engineers are now promoted to “tech leads” because that’s an important role in the “product trio” they read about. They bring in agile coaches to improve product delivery, without realizing that many of these coaches never really worked in an empowered product team model. They add new roles to the organization. They create processes, and add more roles on top of that to own and improve such processes that the teams should use. And the list goes on.
But have you spotted anything special in all of these initiatives?
Apart from the clear antipatterns of scaling with processes, adding unnecessary complexity and bureaucracy to their organization, and the whole madness around delivery frameworks and rituals being at the center of everything these poor product people do — there’s something else going on.
What’s missing is simply the most important thing about this transformation aspect: the fact that it all starts with product leadership.
The reality is simple: without strong product leaders that deeply care about creating and continuously incentivizing a strong product culture, your organization won’t succeed with the transformation you’re aiming for.
This is because the epicenter of the change to evolve from feature teams to empowered product teams lies primarily in three leadership efforts:
- Managing by outcomes
- Transferring accountability of the results from the leaders to the teams
- Coaching the teams on what great looks like and focus on culture
Let me unpack these, one by one.
Managing by outcomes
If product teams are focused on shipping outputs assigned to them, and all they care about is when that feature is released and how they’re building it — you’re likely working in a feature factory.
You can easily verify this by asking your engineers why they are building what they are building — and you’ll understand what I mean. Ask them how their product is doing in the market today, and what customer and business problems they’re trying to solve. Most likely they have no clue, because most product teams out there are feature or delivery teams — not empowered product teams.
But you don’t even need to pick the engineers… Just ask your Product Managers to tell you a clear story about the world they want to create with the product they’re building, how this fits with the product strategy and company vision, what the most important customer and business problems to solve are and why — and you’ll probably realize that the challenge goes beyond your engineering culture.
So what can companies do?
The path towards dismantling the feature factory culture and becoming a strong product organization with empowered product teams starts here: assigning your teams problems to solve or opportunities to tackle, usually framed as objectives.
This is how you empower your teams and deploy your product strategy — which is the set of the most important customer and business problems you should focus on next, to make your product vision a reality. This of course means that you have one.
Once you have decided on the problems you should be solving (which comes from an insights-driven product strategy, not opinions shared in a meeting your leadership had during an off-site), then you’re ready to assign these problems to specific teams that have the right competency and domain knowledge to solve them.
Framing these objectives as problems to solve (outcomes) empowers the team to discover the best solution to solve them.
Now, that sounds simple, but it’s a completely different ballgame when compared to how feature teams work.
In a feature-team model, teams are given features to build or ideas to pursue. Such ideas quickly turn into backlog items, a project, or an output-driven roadmap. They usually come from product leaders or from Sales. When the latter is the case, and such features or product requests become the main driver for the product teams’ day-to-day, that’s a clear symptom of a sales-driven company operating in a feature factory environment. These organizations are reactive to the market. Not strategic and proactive.
But that’s not the only reason these organizations end up being disrupted, sooner or later.
The main reason is the lack of discovery which is directly linked to how the organization makes decisions: how the organization prioritizes the problems they should solve next (product leadership’s responsibility), and how they come up with the solutions to solve such problems (product teams’ responsibility).
Without discovery, you won’t be able to consistently innovate on behalf of your customers — like the best product organizations do. You won’t be making evidence-based decisions. You won’t be continuously generating the insights you need to inform your product strategy.
And no, just because teams are “talking with customers” that doesn’t mean they are doing discovery. Sadly.
Although having product teams talking directly with customers is a great start for many, in most cases what they are actually doing is really just design and validation.
And those are two very different things.
Again, when teams are assigned ideas to pursue or features to build, the whole point of true discovery is gone from the get-go… All that is left is a product team defining how that feature should be built, validating the design with some customers, and iterating on a few things.
As opposed to in true discovery, where an empowered product team is trying different approaches to find a solution that customers love and that works for the business, feature teams are already given the approach. They were already given the idea to execute on. All they do is to try to make it as good as possible — without any knowledge about the outcomes they’re seeking or caring about the results.
And why do you think that is?
It’s related to accountability.
Transferring accountability of the results from the leaders to the teams
In order to manage by outcomes, product leaders need to practice the art of asking outcome-based questions.
More often than not, you find leaders asking questions related to development status. This, on the other hand, incentivizes the teams to provide status on outputs.
The cycle has suddenly been established: leaders ask the wrong questions, and teams get used to providing the wrong answers. In the end, we all focus on the wrong things: the outputs, the processes, the means to the actual end.
Instead, in order to incentivize an outcome-based culture and foster ownership in the teams, leaders must ask questions related to the outcomes we want to achieve.
When leaders have conversations with the teams about the progress towards a problem to solve, teams are forced to define what success looks like for them — and measure it.
It forces them to have a constant pulse on what truly matters: the results they want to achieve.
In true empowered product teams, they do this naturally for one logical reason: they are accountable for such results.
“The product manager is responsible for value and viability, the designer is responsible for usability and the engineers are responsible for feasibility.”
Together, they ensure that we’re building a product that customers love within a sustainably profitable business model. And together is a keyword.
This requires extreme collaboration. Collective ownership. Passion and grit. And, specifically for Product Managers, this is what makes the role so rewarding. It’s hard to be accountable and to take responsibility for value and viability. But that’s also why the role of a Product Manager in an empowered product team is not for everyone…
As Marty Cagan puts it:
“When a product manager says, “not my fault” that sales can’t sell, they are not only mistaken, but they are missing the point of their role.”
Yet, that’s unfortunately the reality in most teams out there. Because in feature teams — or worse, delivery teams — the leaders are the ones being accountable for the value and viability of what’s being built. Not the Product Managers. Not the teams, overall. It’s the product leaders, the C-Suite, the founders, the Sales organizations, and so on. The variation here doesn’t matter much, as this will depend on how large the organization is and the culture they have. But the point is the same: it’s not the product team who’s accountable.
I hope I don’t need to tell you how dysfunctional this is. You only need to scratch the surface of the literature on high-performing teams to understand that sense of ownership and accountability is a fundamental driver to building intrinsic motivation, fostering cross functional collaboration, and — ultimately — improving results. And in the context of building products, this is even more dysfunctional because when the teams are not doing discovery to find the best solution to solve their problems, this means that someone else is making the decisions on what to build. In most of these cases, without any evidence. That’s honestly the root cause of why so many products fail…
So what can we do?
Again, it starts with product leaders asking the right questions and holding these teams accountable for the solution they are coming up with. It starts with leaders asking the teams — not just the Product Managers — how their products are doing in the market. It starts with leaders asking the engineers why they’re building what they are building; what customer problems they’re trying to solve.
As argued by Camille Fournier:
“Product managers are only useful when they are paired with willing engineering teams. If the engineering teams don’t feel a sense of ownership for delivering a great product to their customers, product managers are unlikely to close that gap, and they will more likely turn into glorified backlog groomers than true product leaders.”
This requires leaders to design the right mechanisms to build and foster trust — among the team members and with the various stakeholders. It requires hard work in order to evolve their groups of individuals into actual teams. Those are two very different things.
And please note that this doesn’t mean stepping back and letting them figure it out on their own. First of all, leaders must ensure that these teams have the right competency to solve the problems they’re asked to solve. This means spending time working on team topology, properly staffing those teams, and carefully hiring — aiming to bring genuine and amazing people in, while trying to constantly “raise the bar”.
Then, it’s important to understand that empowerment requires better management, not less management — as the Silicon Valley Product Group would argue. This means coaching the teams and spending most of the time developing their people as well as incentivizing the right behaviors to foster the right culture.
Coaching the teams on what great looks like and focus on culture
As Bill Campbell once said:
“Coaching is no longer a specialty; you cannot be a good manager without being a good coach.”
I can’t stress enough the importance of making coaching the number one priority for product leaders. Sadly, more often than not, I hear many leaders say that they “don’t have time for that” or that they are not “experts” in coaching itself — so they won’t do it. But that is just a demonstration of the clear misunderstanding of what coaching is all about. Also, to put it bluntly, a complete misunderstanding of their roles as product leaders.
I tend to tell them that in order to be more coach-like, it really only takes a small (but hard) change in their behavior:
“A little more asking people questions and a little less telling people what they should do.”
I‘ve written about this elsewhere and talked about it in the Product Club podcast recently.
But of course, it isn’t easy to coach and help Product Managers grow without defining what great looks like first — in the context of your organization, industry, team, and product needs. We need to start there.
Now, why is this important in the context of transformation?
Because by defining what great looks like, you’re setting a clear expectation.
The reality is that many Product people don’t have the competency they need to thrive in an empowered product team. If they’ve worked for many years in a delivery team or feature team model, they simply don’t know what great cross-functional collaboration looks like. They don’t know what great product discovery looks like. And, most of the time telling them what it looks like is not enough. You need to show them. You need to coach them. The answers need to come from them.
The point is:
If you want to have empowered product teams and transform your organization in this specific aspect, you need to help your Product Managers understand what it takes to de-risk their ideas. You need to help them understand how to collaborate with designers and engineers. You need to help your designers understand that they can’t design in isolation. You need to ensure your engineers are not only thinking about how to build the stuff they’re building, but about the people who are going to use such products. You need to ensure that your product trios really understand the power of discovering solutions together — and are spending at least 70% of their time doing so — continuously. And the list goes on.
Ultimately, you need to pay attention to what you are celebrating, rewarding, publicly praising, disapproving, and promoting. Culture is a set of actions, not beliefs.
Many product leaders who want to transform their organizations and evolve from feature teams to empowered product teams tend to focus on everything else but themselves. Yet, such transformation starts with leadership.
In many ways, without strong product leaders — you won’t be able to succeed.
Teams won’t simply focus on outcomes if their leaders don’t ask them outcome-related questions. Teams won’t do real discovery if their leaders don’t assign them with problems to solve. Teams won’t work collaboratively unless their leaders update their reward systems and define what great looks like. Engineers won’t evolve from being mercenaries executing requirements to missionaries, unless their leaders ask them about the customer problems they’re solving. Teams won’t feel true ownership of what they’re building unless leaders shift their accountability model and culture. Teams won’t necessarily know how they’re supposed to work unless their leaders make coaching their number one priority — setting clear expectations, developing coaching plans, asking the right questions to foster reflection, and focusing on bringing the greatness in their people to light. A real focus on creating an environment for people to thrive and become the best versions of themselves. An environment where product people can truly practice modern product development as part of a real team, have fun, and enjoy innovating on behalf of their customers.
And the reality is brutal: if you don’t, there’s other companies out there who will.
It takes time, and it’s not easy. But it’s absolutely worth it.
Read the full article here