šļø #45: Is there a better way to driving transformations and influencing change?
Plus: Behind the scenes of building Magical Audios and 5 things to help you this week
Hola friends š
Itās July!!! Can you believe it?! Weāre already in the 2nd half of the year! I hope youāre already preparing for your summer break. š
The last few days have been a mix of amazeballs and meh:
š I went to Copenhagen for the first time! I even managed to muster up the courage to bike from where we were staying to the beach! No Danes were harmed during this activity.
š¤ Iāve been nursing laryngitis for the last few days. I think I caught it on my flight home. (mask up if youāve got the sniffles, folks!)
What about you? What has been amazeballs or meh for you lately? š«¶
Now on to this weekās thoughts and feelings!
Thoughts and Feelings about Transformations - Is there a better way to drive change?
Building Magical Audios in public: The first mistakeā¦ kind of
5 Things to help you this week be bright and shiny š»
š Read on!
01 Thoughts and Feelings about Transformations - Is there a better way to drive change?
Two PMs I'm coaching are introducing some big changes in their organizationsā ways of working impacting between 40 to 4000+ people.
But as expected, they are facing some challenges.
Overwhelm. Because there are so many moving pieces to enact the change.
Resistance. People who are pessimistic to the change.
And I canāt help but think about why these challenges always seem attached to any change regardless of the size, whenever itās introduced to any organization.
As a veteran and casualty of changes, let me share my 0.3ā¬
***
The desire to change things often come from a good place butā¦ thereās always a but
Letās acknowledge that desire for change comes from good intentions. But the road to hell and allā¦
I think people believe that when they want to change something regardless of the size and complexity ā they truly believe that it is the right thing to do.
This is great, right? We all want to be working with people who strive to improve situations, so that our opportunities to create value can increase.
But 90% of the time, having a righteous belief is never enough.
My worst attempt at introducing changes were misguided by these motivations:
I learned from a very expensive course I attended that Product organizations need to *insert process here*
Iāve read that *insert big company name here* is doing *insert process here* and now itās fashionable to do the same thing
Iāve done it before and it made my organization successful, so let me do it all over again
Have you heard any of these reasoning before?
Thereās nothing really solid behind these motivations apart fromā¦ my ego. I learned, Iāve read, Iāve done - therefore I must be right.
And the worst part? Thatās precisely whatās coming across in my communications.
A communication thatās making people feel that everything theyāve been doing all along is wrong. The missed targets, the challenges we keep encountering, and the walls we keep running into were somehow their fault because they were not doing the right thing. But have no fear! I am here to save the day!
Terrible approach made worse by even worse messaging.
The irony of this is that Iāve also been part of transformations that frustrated me because my leaders mandated all these changes that, for me, completely disregarded my context. And here I was doing the exact same thing.
Changes are necessary for teams and organizations to keep growing, scaling, evolving. BUT if we ever hope for these changes to even see the light of day outside of a beautifully written proposal document then we must:
Be clear on the problems that this change is trying to solve and the impact they have to business and to the users.
Get input and feedback from the people we expect to enact the changes we want to happen in the first place.
Have clearly defined measures of success that is known to everybody
Belief is great. But that belief needs to be backed by information and clarity for it to be worth any salt. Otherwise, the likely scenario is to be met with resistance (if not hostility). We are not a church here, after all.
A tsunami of change vs small iterative changes
If I look back at all the transformations Iāve been part of, I canāt help but wonder sometimes āHOW IN THE WORLD DID MY SANITY SURVIVE THAT?ā
I think changes in organizations, processes, and practices need to happen all the time. If we want to keep improving as a team/organizaiton, we need to keep evolving so weāre always relevant to the context of the market, the business, and the people.
But Iām also a big believer that continuous improvement needs to be normalized and ingrained in our day to day that the talk of reorgs or adoption of new tools/processes shouldnāt require a huge fanfare every single time. It should just be a habit and not a big event.
I canāt help but ask myself sometimes ā
Does every new strategy need a new organization? Why canāt we constantly strive to adjust the organization and architecture until we can get to a point where autonomy is real and dependencies are non-existent so that every team can always contribute to the strategy?
Does modernizing our products require a full platform overhaul every single time somebody cries āmonolith!ā ? Why canāt we strive to really allocate capacity and give priority to technical improvements in our roadmaps with the aim of true flexibility in the long run?
Does rolling out a new tool for processes require impacting every single team in the entire company in one go? Why canāt we roll it out small from team to team and gain feedback overtime to validate whether this new tool is going to deliver on its promise?
I think my problem with these big changes is that thereās just a strong assumption that the proposed change is THE right change.
My Product Manager brain has been trained to think that when there is an assumption, the best approach is to validate, learn, and implement incremental changes to adjust accordingly.
And then thereās āContinue with Business As Usualā. Because users will go on with their lives and the market will keep on spinning, after all.
But when big changes require capacity from the same people who also need to keep business as usual going ā How much time and energy is necessary to do both? And how much people are actually able to give?
Especially when business as usual really is pretty much 90% reporting and other administrative work that donāt add any value for the users.
I think we romanticize too much the metaphor of changing planes midflight - but thereās a reason this scenario hasnāt actually happened in real life! Except in the movie Speed, and it was a bus and fictional. And in the end, the bus exploded and some people died.
Maybe Iām being too conservative. Preferring an iterative approach that slices the big change needed to be done into smaller ones. Preferring to be cutthroat on the BAU and getting rid of everything thatās not about providing value to users. Prefering to not see transformation as a year long activity that has a start and end date because I donāt believe that improvements have a deadline.
I like to compare transformations to butterflies flapping their wings in one side of the world then starting a hurricane in the other. Small changes have big impact all the time. Whether positive or negative. And itās important to understand the result first of that first round of flapping before going for a 2nd so we can adjust as necessary.
People as the reason for failure
When transformations fail these two get the blame
The people and their perceived fear of change making it impossible for the change to actually be enacted. But people are not afraid of the change itself. Theyāre afraid of what the change can mean for them. Changes bring with it uncertainty and uncertainty can easily be seen with a pessimistic lens.
Unwanted change in scope
Workload that may become unmanageable
Or a loss of their job, in the worst case scenario
The leadership and their perceived lack of empathy or expertise. They might be accountable but theyāre also only humans. They may have the experience to be able to see a big picture, which explains why they are in the position they are in; but they could still be limited by their own experience, context, and mindset. People only know what they know.
Itās so much easier to simplify the cause of the failure of change asā¦ people.
Which would simplify the solution toā¦ get better people.
And then try the same thing all over again but with a different name.
Versus do the harder work that entails:
Creating a safe space that can help people deal with uncertainty
Adopting a learning mindset that encourages small and consistent changes and a critical lens to really understand the impact
Collaborating with a diverse group of people to understand context, analyze results, and iterate on implementations on a continuous basis
Accepting that transformation requires a lot of time and thereās no room for a single hero. (terrible for my ego š )
Hindsight is always 20/20
Iāve been through a lot of transformations of different sizes. Iāve led and failed some of them myself.
Thereās a lot of material on change management out there so Iām not going to wax poetic about them. But my biggest learning from all of the changes Iāve been through is this:
When weāre building products, we care so much about the people weāre building those products for.
We give so much effort in understanding the problems we need to solve so we can achieve the results we want
We preach endlessly about the importance of experimenting, doing small iterations, so we can minimimize risks for both users and business
And we are clear about the result we want to achieve - always to the benefit of the user and the business.
And when the new solutions we build do not work out because theyāre not the right one to generate the necessary impact, we donāt put the blame on the team nor on the users right? We just roll up our sleeves and get back to work.
And we work as a team. We involve our squad, our stakeholders, and even our users to a certain extent in finding out what the right solution to build is.
So why canāt we seem to apply the same product mindset when weāre driving changes to our organization whatever the size of that change may be?
Transformations are hard! Of course they are! Transformations entail changing behaviors and ways of working for multiple people who all have their different personalities, contexts, preferences ā just to name a few. Transformations are fuck*n complex!
So why do we keep treating it as just another project that needs to get done?
***
Hey there product builder, are you struggling to implement a new process or any other change in your team or organization? Are you facing resistance from your peers and your stakeholders? I know it can be frustrating! But you also donāt have to figure it out by yourself.
I have available slots for coaching and Iād love to chat about supporting you.
02 Building Magical Audios in public: The first mistakeā¦ kind of
Last week I wrote about the first steps we took to create Magical Audios. And this week I promised to write about our first mistake.
Parallel to doing the research to validate our problems and get insights for potential solutions, we started conversations with potential investors.
We thought that if we wanted to move forward faster, we needed money. And weād prefer to not have to dip into our retirement plans to get some.
But every potential investor we talked to pushed us to have a working product and a healthy number of engaged users.
Makes perfect sense. Except we didnāt have any of the above.
But we needed the money to have both. But also we needed to have both to get money. šµāš« Needless to say, this sent us on a spiral.
Shouldnāt be a problem normally but we had limitations. None of us 3 could design nor code.
So armed with a kind-of validated idea, we went looking for freelance engineers. I made wireframes and userflows and did my best to represent the idea.
We found our first engineer from outside of EU. While the cost was something we could afford, the collaboration was not a fit. We worked together for 3 months before he had anything to show. And the work was completely disappointing. It was buggy and far from some of the mockups we did together.
I probably should have cut the collaboration short early on - but sunk-cost fallacy got in the way. And thatās money I will never get back.
Then we found another person to help us. And this time the collaboration was much better. A bit more painful in the pocket but we had an MVP in 4 weeks! Shout out to Piccia Neri who did both the design and tech work for us!
Immediately after that, I scheduled user tests to get feedback on our MVP. And while the general tone of the feedback was positive, the biggest learning we got was that our MVP wasā¦ neither minimum nor viable. Meaning, what we had was missing a lot of important things for our users to even begin using it.
What we have built, while it would give value, was not the biggest value that our target users needed.
In hindsight, we definitely didnāt need to start coding anything right away.
But the rush to get funding (which we still didnāt get) made us focus on the wrong thing - which was to BUILD something immediately.
I could have gotten the same feedback from users if I built a prototype on Figma instead. Great example of focusing on the output vs the outcome. Adios, šø!
But we did get BIG learnings; which is the most important thing anyway at the stage we were in. Including learning that what we have was not a waste. We were just missing some things. So we went back to the drawing board and iterated.
But Iāll share that part of the story in the next newsletterā¦
02 5 Things to help you this week be bright and shiny š»
Rachel Botsmanās latest newsletter on managing our attention and regaining control of our focus
Speaking of influencing change in behavior - Wes Kaoās latest newsletter shares a framework that you can incorporate when giving feedback to influence change
If youāre preparing for your summer break, read
ās post about Stepping Away without Worry - and learn how to really disconnect this summer, stress-freeMay I recommend Dolly Adlertonās Good Material for your Summer Read?
If you enjoyed this post, why not forward it to a friend who might enjoy it too? š«¶
And If you reached the end of this issue, Iād love to read your thoughts, feelings, and violent reactions in the comments. š«¶
š
Kax
Loved the building in public story! Agree a product approach is a better way to handle a transformation.
Thank you for the shout out on my vacation article!