Watch the Video
Senior Product Leaders are actually Company Change Agents and most aren't trained for it.
This part of their role may also not be explicit. "Product Transformation isn't really a thing, like "Digital Transformation" is a thing, or "Agile Transformation". The latter is probably closest to Product Transformation.
Doing this organisational change work is difficult and creating changes to organisational structures and processes can get frustrating if things move very slowly.
In the book The Idealist's Survival Guide I learned something surprising. The book is about people working in humanitarian aid campaigns and organisations. You'd think that this would be a very fulfilling job, full of purpose.
Why would people leave such jobs? The primary reason are poor processes and bureaucratic organisations. I'd like to help you avoid getting beyond frustrated.
Only a few of my clients follow some of the principles of organisational development. Those who do have an easier time in their work.
Those who don't are regularly frustrated by the challenges they are facing.
There will still be challenges. There always are. With the following principles you can bring them back to a manageable level and free up attention for more actual product work.
In the video/audio you find a bit more about the following:
1- Create Shared Goals with key stakeholders
2- Get curious about what's in it for them
A brief side-note, last month's member video was a case study of a senior product leader who drove the implicit "product transformation" of two FinTech companies. For features like this, check out http://productleadership.eu/
3- Use basic experiment design when talking about structure changes
Listen to the Audio
- "Senior product leaders are actually company change agents, and most aren't really trained for it. So what does that then mean in practice? It means that there is so much challenge in trying to change the organisation in order to become more product-driven, that it gets into the way of the really important product work, especially more strategic product work.
But what surprised me when I recently interviewed a group of wonderful senior product leaders was that pretty much all of them really thrive in that challenge, but they sort of don't want for the challenge to go away completely. They just want for the challenge to go to a manageable amount, so that they can have just a bit more time getting back into the product work. So let me share some principles with you that help you make that a lot easier.
First of all, where does all of this come from?
It comes from product transformation not actually being a thing, not in the explicit way that digital transformation is a thing or agile transformation is a thing. There is no product transformation and maybe it will come, maybe it will not come, I don't know. But if you think about it, product leaders, especially senior product leaders in organisations, they are changing the way that the organisation is working, especially for those companies where product thinking and product management, modern day product development is only becoming a thing. So the work that senior product leaders need to do will result in a change to the organisation, so that it becomes more product-driven.
So once we've worked through this period where product transformation as implicit as it might be, is done, the next one would be product design transformation, right? Once we get product development going, then usually we need to help the organisation become more product design-driven as well, and really help it appreciate how important user experience is in the product experience. But I digress.
So why is this a problem, right?
If you think about it, this organisational change that is happening, the challenge for most senior product leaders right now seems to be at a level where it's getting beyond frustrating. And that usually results in one thing which is if there's not enough progress happening over a sustained period of time, and it outweighs the enjoyment that senior product leaders get out of the work that they do, then there is one outcome that is inevitable, and that might mean leaving the organisation for one that is more morphable, more open to improving, more open to embracing becoming product-driven.
I see a parallel here from a book that I read which is called the "Idealist's Survival Guide." It's about people working in humanitarian campaigns on humanitarian organisations where I might think, "Wow, that's really great work." I mean, that must be super fulfilling and really high with purpose. So the job satisfaction must be quite high too. And yeah, of course, to some degree it is. However, the number one reason of people leaving such organisations really surprised me. The reason why people in humanitarian campaigns and organisations are leaving those jobs is not for a lack of purpose, of course, but it is because it is so hard to get things done. It is ultimately about processes and how the organisation is working on supporting the work.
So all the things that get in the way of the work, kind of like in product work, right, helping the organisation change and become more product-driven is so consuming because there's so much education and so much support and so much aligning that needs to happen in order for the organization to become more product-driven, that it actually gets in the way of some of the product work, at least on the senior product leader level. So I don't want for that to be your future.
I want to share some principles with you that can help you make that work easier, and I've got three prepared for you in this video.
Those clients of mine that I get to work with that follow these principles have a much easier time dealing with those challenges and the challenges become a lot more manageable. And those clients of mine that haven't been using those principles are the ones who are noticeably more frustrated by what they have to put up with, if you will, on an everyday basis.
Okay, so, the first thing I would like to suggest to you is when you are interacting with a key stakeholder who needs to improve some things in the organisation, processes or structure or whatever it might be, in order to enable smoother product work, to identify some shared goals. If two people have no shared goals, but everything is separate, it is very difficult to actually align around something. So always think about what the shared goal might be of doing something and inspiring some sort of change in order to make product work more seamless and help the organisation do that better. So that's the first principle.
The second principle is to nurture a bit of empathy and think about what's in it for them.
What is in it for the key stakeholder that would make this particular change that is required in order to make the product work easier, simpler, more streamlined? What is it that the other stakeholder, what is it at the other person might gain from that? And that would give you a bit more insight into what it can include in the conversation when it comes to inspiring more organisational change that optimises product work.
The third one is something that you probably have done a lot in the past, but may not have considered to incorporate when you are thinking about organisational processes that need to improve in order to support your organisation becoming more product-driven. Before we get to that though, I just wanted to share very quickly that actually last month, the video of the month for my members was a case study of a senior product leader who ran a product transformation campaign, an implicit one, at not just one, but two major FinTech organisations. And that's one of the benefits that are included in this program. If you're curious to learn more, check out productleadership.eu, that's productleadership.eu. Now back to the third principle for organisational development, to make it easier for you to affect organisational change that makes your company more product-driven.
The third one is to use basic experiment design when you are looking to discuss changes to organisational processes, right, and structures.
So to form an example, this might be about shaking up the team structure or responsibilities in the teams in order to empower the product managers or product owners and ensure that the work that they do is actually fully driven by their prioritisation, right? So there might be some dynamics that are not supporting that right now. This is common when product and engineering aren't actually one organisation, just to mention one example, and the proposed change might be formulated in an experiment, right?
The observed issue that we're experiencing is XYZ, we believe that by doing ABC, we will see this other type of outcome. We will know that this is true when we can actually count these things or observe these things. And we will see these different types of outcomes, right? We will give ourselves one, two, three months, no more usually I would suggest, in order to be able to observe how the change that we're suggesting may or may not bring about this particular change, right? By adopting basic experiment design, the perceived severity, if you will, of the change is usually lessons, right? You see the same thing with trials, pilots, those types of things, just psychologically forming a demarcation around a particular change, and that makes it a lot easier.
So if you liked what I shared in this particular video, feel free to check out the other ones that should be popping up for you right about here. Thank you very much, bye."
==end of transcript==