Transformation Politics
Continuing on the theme of sharing more of the lessons learned from companies that are embarking on transformations to the product model, in earlier articles we discussed transformation regrets, the problem of managing the transformation as a project, and then we talked about the importance of winning the hearts and minds of the executives and stakeholders.
Many of these discussions are necessarily dancing around the topic of politics. In this article, I’d like to address these political issues directly.
In every successful transformation I can point to, the leaders were very aware of, and intentional, in how they addressed the political challenges. They did not avoid or ignore the challenges; they embraced them.
I want to be clear here that I don’t mean “politics” in any bad sense. As my partner Christian Idiodi likes to point out, “every problem is a people problem.” And since companies are comprised of people, it should be no surprise that changing how an organization makes decisions and builds products is bound to be a difficult change for many of the people impacted.
While many of the accommodations in the name of politics will be a result of the specific individuals involved and their specific personalities, there are a set of general learnings that probably apply in pretty much every organization, and those are the ones we’ll discuss here:
Product Leaders
As I’ve emphasized several times, product leaders really are the key to successful transformation. And when the product leader doesn’t have first-hand experience with the product model, then a product leadership coach is very likely going to be essential to filling that gap.
But either way, the product leader needs to establish the necessary working relationships with the essential executives and stakeholders. That usually means starting by showing humility and a genuine desire to learn what each key executive and stakeholder is concerned about, and the constraints they represent.
At least initially, the product leader is usually the face of the broader product organization to those outside of product and technology. So this person needs to be sensitive to this, and also realize that each additional person that is exposed, starting with the product managers, should only be exposed once the product leader is confident the person has enough sophistication about the business that they can and will maintain a high standard.
Please remember that the product leader will be judged by her weakest product manager.
Product Managers
Few things will undermine confidence and trust faster than people with a product manager title that are viewed by stakeholders or executives as clueless about how the company actually works.
This is why it is so absolutely essential to have an effective onboarding program for product managers, which includes learning about business viability – marketing, sales, finance, monetization, legal, compliance, security, and privacy, and potentially several other topics depending on the company and industry.
I encourage product leaders to protect the integrity of the “product manager” job title, but really any title with the word “product” in it.
If you have a series of similar job titles in your company (e.g. product manager, product owner, product operations, and/or product analysts), it’s hard for the rest of the company to understand and remember the distinctions, especially when it comes to the necessary level of business savvy.
This is also the reason the product manager has a minimum level of competence required. An “assistant” or “associate” product manager is usually not at this minimum level of competence – and if they are, they should be given the title they deserve.
Change Management
Many people intuitively believe it’s best to take a gradual approach to change. Make a series of small changes over time, and eventually you can end up at your destination. Unfortunately, we rarely see this strategy work when it comes to transformation to the product model.
The problem is that once a transformation effort starts, the clock starts ticking. The organization has a limit to how long they’ll wait before they see real and meaningful change – especially when the purpose of transformation is to deliver real business outcomes.
It is hard to see the impact of small changes, and it’s also very natural to avoid the most important changes in the early stages.
This is why we believe that the more successful approach is to instead take a small subset of the company, and to show the impact of a much larger set of changes. Show the company what good really looks like. This is why pilot teams (described below) are so powerful.
Pilot Teams
Pilot teams are primarily a risk mitigation technique. It lets the company learn safely, quickly, and inexpensively just what it means to move to empowered product teams operating in the product model.
But this is precisely what makes the technique so powerful when it comes to politics. It is normal and understandable for the company to be nervous or skeptical about any new way of working.
Many successful transformations credit their success to the first pilot teams.
Which is why it’s so important to think very carefully about the pilot teams. Who do you want on the team? What problem do you want the team to solve? What is the outcome the team is striving for, and how will it be measured? What training and coaching will the team members need?
Strong product leaders hand pick the members of these pilot teams. They are not only trying to win the hearts and minds of the stakeholders and executives, but they are also using this team to show the rest of their own organization what good truly looks like.
You also want to be sensitive to the size of the pilot team. Just about everything is easier and faster with a smaller team – role clarity, coaching, communication, collaboration, decision making, and dependencies are some of the big examples. If you define a large set of new roles, and people think that they are all required in order to move to the product model, many stakeholders will be inclined to suspect an unawareness or insensitivity to cost.
Strong product leaders also think very carefully about the problem to solve. They don’t want something so simple that the product model isn’t necessary and nobody is impressed, yet they also don’t want to set the team up to fail. They also don’t want to pick something that is heavily dependent on major tech-debt replatforming efforts that may not have happened yet.
Similarly, strong product leaders know that the pilot team will be judged by their ability to achieve a business outcome. Something that is truly meaningful to the business. It’s good to make our customers happy, but it’s not enough. The team also has to solve for the business.
Finally, strong product leaders ensure the members of the pilot teams have been trained, to give them the best chance for success, and the members have coaching available throughout the pilot so they know how to tackle the various challenges they will face.
Product Discovery
For those that are new to product discovery, there are two types of product discovery: problem discovery and solution discovery. In problem discovery we are looking for important problems to solve, and in solution discovery we are trying to solve that problem in a way that is valuable, usable, feasible and viable.
First, it’s important to acknowledge that a trained product team is very capable of doing both types of product discovery. And further, they love it when they can do both.
However, the subject of this article is politics, and it’s important to acknowledge that in the vast majority of cases, the stakeholders already have a very good understanding of the problems that need to be solved.
They don’t always frame it this way, but most stakeholders have been dealing with these problems, and very likely pleading for solutions, for several years. It’s not hard to imagine how frustrating it is for a stakeholder to have to sit by and watch as a product team spends weeks or sometimes even months coming up with the same list of problems.
Furthermore, remember these pilot teams are looking for solutions, and if the pilot team spends too much time on problem discovery, they won’t have time to explore and discover a successful solution.
Now, clearly, if the pilot team does not understand the problem or the customer’s context, then they have little hope of coming up with a winning solution. But that usually takes far less time than identifying the problem and deciding that’s the most important problem to solve.
So, especially for politics and winning hearts and minds, I strongly encourage the pilot teams to trust the stakeholders when it comes to the problem.
In the very first days of testing out potential solutions, if the pilot team has an incorrect assumption about the problem or the customer, then they will likely see this immediately.
But the truth is that in most cases, the stakeholders have identified a real problem, and there are real customers in need of a solution, and if the pilot team can discover and deliver an effective solution, they will have done something very significant for the customer and for the business, and earned real gratitude and respect from the stakeholders.
Once a product team has demonstrated their ability to consistently deliver successful solutions, they will find that the stakeholders are much more open to insights, observations and suggestions from the product team about potential problems to be solved.
One other thing to watch out for, especially when it comes to the political optics. Sometimes product teams that are new to product discovery have no real understanding of how long they should spend working on a particular type of problem. A discovery coach or experienced manager can help them, and they are usually able to help them solve the problem in days rather than weeks, but if a team goes dark for several weeks – or worse, multiple months – the stakeholders will lose confidence.
As a general rule of thumb, if a product team is working on the same problem for more than two weeks, they need some immediate coaching to determine if it’s worth continuing down that path for another week.
Product Strategy
From a political perspective, product strategy is often perceived as a shift in control from stakeholders to product leaders. In truth it’s moving to more of a collaboration, but it will still feel hard for the stakeholders.
This is why the move to a true, holistic product strategy (i.e. changing how you decide which problems to solve), is so much easier once the product teams have demonstrated their ability to consistently and successfully solve problems in ways that customers love yet work for the business (i.e. changing how you solve problems and changing how you deliver solutions).
So you will likely have better results holding off on changing how you decide which problems to solve until after you have largely won the hearts and minds of the stakeholders and executives.
The last point concerns the need to maintain enthusiasm and support over long periods of time.
Keeping The Lights On
Remember that in addition to solving problems in ways that customers love yet work for the business, virtually every product team also has a responsibility to “keep the lights on” by knocking out the never-ending list of usually minor items that are necessary for a stakeholder to continue to run their part of the business.
If a stakeholder believes that the product team does not understand this need, or worse, doesn’t care, then no matter how much they may support the move to the product model, they are going to insist on resources for this, one way or another. From their point of view, they have no choice.
Internal Evangelism
In a large company, you can expect a transformation to take one to three years. But I can tell you right now that very few organizations are prepared to wait that long to see results. Instead, we need to show results in the first months (hence the importance of pilot teams) and then sustain that momentum over the months that follow.
The key is to maintain a constant drumbeat of outcomes. Real business results. They do not have to be dramatic results, but they do need to be real results.
Don’t confuse business results with activities. Just because you’ve been busy training and coaching your people, talking to customers, setting up data tools, purchasing and learning prototyping tools, and hundreds of other discovery and delivery activities, none of these things are business results. They are useful insofar as they contribute to real business results, but it is the business results that we need to highlight.
The more frequently you can send meaningful updates, the better, but in no case should it be less than monthly. Share the successes as well as failures. If people feel you are sugar coating things, you will undermine your own message, especially the real results.
Being sensitive to how your work, words and actions are perceived is important any time large groups of people are involved, but when you’re advocating for major change in how a company produces its products, empathy in general, and these items in particular, become especially important.
