As a product management teacher and expert, I had a unique opportunity to talk to and meet hundreds of product managers from around the world. I got to know their problems and struggles and I can identify a common reason for their challenges: a divide between older and newer ways of how leadership works.
The classic approach of leadership builds long-term, detailed plans and expects results at a certain time. The newer, agile scrum-inspired approach sets goals and evaluates progress regularly, allowing us to adapt to changing markets and jump on opportunities quickly. This builds trust in teams and gives them much-needed flexibility by sacrificing illusionary predictability (“no plan survives first contact with the enemy”). At the same time, the risk of failure is minimized, as the company no longer relies on massive, long-term plans to achieve profit.
However, this requires adaptive leadership — the subject of today’s article. This concept is universal, but especially important to product managers in an agile scrum environment.
PMs need to be able to react to new information and proceed with opportunities and pause or withdraw from less promising projects. That creates a divide between them and potential “old-fashioned” higher ops, as outlined above. So, the question remains — how do you be an adaptive leader and promote this style in your organization?
Let’s kick the article off with a proper definition. Adaptive leadership is a management style that enables leaders to adjust the way they work for consistent growth with fast-paced change and complex issues.
Adaptive leaders do not rely on their position to make decisions, but instead justify them with data and reliable insights. In time, this builds trust in these leaders, making it easier for their teams to follow directions they might not have supported at first.
Now that we are on the same page, let’s look at the core principles of adaptive leadership:
This is probably the core reason why agile scrum emerged in the first place. The old world of software development tried hard to develop software in a way factories work — with a plan that is executed to the letter.
However, in the world of software, there are a lot of unknowns and hidden dependencies that no amount of planning will uncover. These types of issues simply need to be found and dealt with during development — with no knowledge of the scale of the issue and effort needed to resolve it.
I recall spending two weeks during my Erasmus Student Exchange program debugging an issue with my graduation project: the electrical engine I operated with a very unique setup ran only for seven minutes and would start again until the software was rebooted. The solution was trivial in hindsight, but nobody in the whole department was able to help me. I can also recall long hours debugging “simple” math that I needed to work on to have any hope of becoming a doctor.
This was more of a code development challenge, but very close to the world of a typical product manager. For us, the principle of navigating uncertainty and change often translates to:
This might sound counter-intuitive, but hear me out. Being adaptive and agile is not about not having plans. It’s about the ability to change course if needed. However, it’s still best to set off with a specific direction and stick to it. It’s the most efficient way to progress and the reason why old-style execs try to keep to this way of working.
Rather than stubbornly clinging to a set plan, it’s best to ensure the correct decision in the first place. Use any available data to support it! And if an adjustment is needed, don’t beat yourself up — things change and as an adaptive leader you need to react.
There will hardly ever be a case where a major development will change course on a whim. Thus, make sure to always communicate your plans and decisions in a clear and transparent way.
Adapt your wording and level of detail to your audience and use data to support your choices. Imagine being on trial and needing all the evidence you need to prove your innocence. While a typical product manager’s decisions are not so dire, this comparison should build the right mindset for you!
Once you have data and a plan, as an adaptive leader, you need to realize that things could change at any given moment. This change is actually the only thing that is certain. As the market evolves, new opportunities arise, and you receive user feedback, you need to be able to constantly evaluate what you plan to do next.
Your brilliant new feature might not initially find appreciation during the discovery phase and you may need to adapt the concept or abandon it completely. You may need to pause development on a new initiative to address urgent feedback or prevent your product from being taken down from the App Store. Lots of products’ roadmaps were thrown away in the bin to address the release of ChatGPT (more on that later).
This is a large benefit of an agile, adaptive approach. You work in a way that allows you to find evidence that the direction you have taken is the best one. You can do that with client interviews, different discovery techniques, or by building a simple minimum viable product (MVP).
Regardless of the means, it’s about confirming whether the direction is correct at a minimum cost. A more classic approach would require you to build a complete product before putting it before the users.
Adaptive leadership is not only about reacting to a changing world. It’s also about being able to achieve your goals regardless of how the company is being set up. This will come down to the following points:
Being adaptive means you need to be able to make a quick decision without too much of a corporate overhead. Your org needs to be built in a way that gives you the necessary freedom to make tough and urgent calls. If you need a sign-off to change direction from three levels of senior managers, you may find that before you get the approval, the opportunity may already be lost. However, such freedom comes with the points below.
I already talked about transparency in communication. However, this comes with real responsibility for any decision. This could be seen as a downside, but that should be the goal of any product manager. While the risk of making a bad decision and failing is an option, the opportunities connected to being dynamic will give a PM more chances to bring significant value to the product.
As a product manager, you may stumble on an opportunity that your small team might not be able to capitalize on. If you work in a dynamic, adaptive company, it will be possible to quickly assign you additional teams and focus the right talent around your demanding idea. Your company should be a means to an end: achieving product goals
Adaptive leadership, even for product managers, is not only about project management. It’s also about people. As time goes on, and you get to know your team members better, you can make sure you get the most of them while keeping them happy and motivated. We are all different and can contribute best in different areas. Be sure to invest in the following points:
Your team is not a group of external contractors. Be open to their ideas, encourage their growth, and let them explore new aspects of the product. If not nothing else, this will help to retain talent and product knowledge, making it easier to progress with your adaptive product developments.
At its very best, you will create your team of unofficial junior product managers that will support you with their full energy and enthusiasm. Part of achieving this builds off of the below points.
That’s right! People are different! Some may play well with others and are OK dealing with mundane code and product issues. Others will get frustrated but will excel at finding brilliant ideas and solutions when left to their own accord.
While you can’t spoil your team to do what they want (you still have goals to achieve!), you can be aware of your team’s strengths and weaknesses and play off them to achieve your goals quicker.
Now that you know the theory, let’s look at adaptive leadership in action. For example, just look at what happened with the pandemic. Basically, the status quo was broken and we woke up to a brand new world of isolation.
Some companies like Zoom, Teams, and food delivery apps thrived and worked furiously to meet the demand, while others, not being able to adapt, withered away. I especially recall my local grocery delivery service, Frisco, changing almost daily during the pandemic. One could see how the product offer was growing, how additional delivery slots were made available, and how the company scaled effectively to meet the demand.
But there is another aspect of this story: the pandemic turned out to be only a temporary change. Frisco is still around and it’s apparent, based on the delivery times availability, that they had to scale back to account for the “in-person” shops reopening freely.
The story is similar when we look at remote work — lots of companies didn’t allow it before the pandemic and went fully remote during it. It may seem like the only logical thing was to adapt to the situation, right? Yet, a lot of companies resisted and due to stubbornness, probably made people sick who never needed to get COVID. It’s also sad to see all the resources invested into making remote work a thing, for the “old style” companies push back to the previous, in-person work due to shaky (at best) reasons. But I digress, let me provide you with another interesting example: the recently launched AI wars.
You probably heard that AI got a significant breakthrough last year with OpenAI’s ChatGPT. For this article alone, let’s just accept it was a major shift in the IT market. In terms of adaptive leadership, Microsoft sensed a great opportunity and being the de facto owner of that technology, suddenly changed from a slow, stagnated giant into a literal start-up. Teams and focuses were shifted around and in a matter of weeks, the company was able to introduce ChatGPT functionality in Skype, Edge, Office, and many other apps with no signs of stopping.
As a Skype alumnus, I can tell you this sort of development speed at Microsoft was previously unheard of. This is not even the full story! The ChatGPT situation pushed Google’s leadership into adapting to the new rising star of the AI market. Suddenly, all the AI projects that were experimental and risky had to be made production-ready yesterday. Why?
Otherwise, Microsoft would have completely taken over and there simply was no time to waste. The history of these events could easily make for another article and it’s far from over, but again, only Google’s adaptive leadership kept them in the race in the first place!
Now, dear reader, this is perhaps the hardest paragraph to write. Usually, when I write an article or record a course, I present issues/challenges with a proven solution that I already successfully adopted. With this, I must say it’s an ongoing struggle for me to successfully promote adaptive leadership.
The funny thing here is that very often, companies proclaim to be adaptive and agile. However, when it comes to actually working in such a way, one discovers that there are so many controls, limits, and waterfall-style planning sessions in place. That can be disheartening.
I haven’t lost hope yet.
So rather than give you a foolproof plan on how to effectively promote adaptive leadership as a product manager, let me just list the actions I have tried (with various degrees of success) or plan to introduce to battle the stiff boundaries of waterfall-type of planning:
Nothing will change if you won’t fight for a change. Only by speaking out and pointing out the flaws and difficulties do you stand any chance of having things better in the future. Don’t do it as a fanatic — a regular, polite and diplomatic approach will not start a revolution, but evolution is also a great start! Now, I admit that the following points are only subsets of this point, but I do believe it’s important to single them out.
If every three months you are not able to deliver your initial plan because…
…then one might ask: does this plan have any value? Maybe, just maybe, the company can extend a little more faith that employees do their best to deliver their goals.
Data is always an ally of a product manager. Maybe you can demonstrate that meticulous long-term planning is simply not a good investment of time and energy.
If long-term planning is unavoidable, perhaps it’s best to advocate for at least easing the burden. Using the data already collected, identify the elements of the planning that take the most time and effort and eliminate/simplify or automate some parts of it. Who knows? Maybe you can push it to a point where the quarterly planning will be a goal and backlog review.
Now, this is at least one piece of advice that isn’t about combating the negativity. If you can attempt to educate your colleagues and managers and show them the agility benefits, who knows? Maybe this will spark a very positive change!
Adaptive leadership is a practical, common-sense approach to solving business issues while acknowledging the truth already mentioned in the article: “The only constant thing is change.”
If companies are to succeed, they need to adapt. You can compare it to Darwinian evolution: it’s just like how life needs to adapt to survive on a planet. Stiff leadership won’t induce learning new things and discovering new strategies that can work.
We have all seen it clearly for the last few years and it’s been as true now as it was when COVID struck the first time. However, don’t think that adaptive leadership will excuse you from having long-term goals, plans and bold, but maybe risky innovation. It will just allow you to get there more efficiently!
Be successful. Be able to adapt as a leader. Thank you.
Featured image source: IconScout
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.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
