Building the Outcome muscle
I recently finished listening to Marty Cagan’s book Transformed on Audible. I was so excited about this book that I purchased it in several formats. Initially, I pre-ordered the print version on Amazon, which I’m still awaiting. 🙁 In the meantime, I also acquired the Kindle version, which I’m currently reading.
Since I was engaged with another book when the Kindle version came out, I opted for the Audible version to access the content sooner. It quickly became my favorite companion during my daily gym sessions. Additionally, I had the opportunity to attend the Transformed workshop in person in Rio de Janeiro.
To my recollection, this is the only book I’ve ever purchased four times. 😀
Was it worth the time and money? Absolutely.
For me, and in conjunction with other SVPG books like Inspired, Empowered, and Loved, Transformed stands as the most comprehensive guide for Product teams. This collection comprehensively illustrates the Product Operation Model, offering substantial insights that I regularly apply to coach my teams.
In my view, a critical aspect of training is the use of real-life examples that contextualize the concepts discussed in the books and help people apply those concepts in their particular scenarios.
I found the case study in Empowered (see Part VIII) particularly illuminating; it demonstrates in a very clear form what an empowered product organization looks like.
Transformed also contains a series of cases — Marty calls them innovation stories — that illustrate how some companies managed to shift from an IT Mindset to a Product Mindset and generate tangible results. I found these particularly inspiring, especially because they are examples outside Silicon Valley. This demonstrates that, although challenging, it is possible to make the shift even in less mature markets. For a Brazilian that aims to help the local community to master the Product Operation Model that definitely shows that there is light at the end of the tunnel.
In coaching sessions, I often refer my team to these business cases. Sometimes, I even read these cases together with them.
However, I’ve noticed a challenge when team members read these cases. Some find the complete cases abstract and struggle to grasp certain concepts, such as outcome versus output, what constitutes a product strategy, context and not control, and the distinction between autonomy and anarchy.
Thus, the purpose of this article, and likely a few more, is to illustrate these concepts with small, real-life examples that you and your team can use to implement the Product Model.
I believe a good analogy here could be that the cases in SVPG books are like a movie depicting what a team working or transforming to the Product Operation Model looks like. This article focuses on specific scenes from that movie and provides a detailed view of them. Now, let’s get into the case!
CASE: Context and Not Control to Generate Good Outcomes (Results)
The case I’m going to discuss in this article is about a SaaS company that aims to enhance its profit margins to achieve greater sustainability — a very common and reasonable objective. During the most recent Black Friday, the company experienced a significant increase in cloud costs, which more than doubled compared to the previous year.
In this case, the tech organization is composed of five product teams. Each team has a Product Manager, an Engineering Manager, around five developers, and some have designers.
The company has a head (director) of product who leads the Product Managers, a head (director) of engineering who leads the Engineering Managers, and a CEO. For the sake of simplicity — as this case is more related to an outcome connected to the engineering organization — we will focus more on the CEO and engineering personas’ interaction. Nevertheless, it is important to note that all this happened in partnership with the product and financial organizations.
To start, I would like to illustrate the concept of autonomy and alignment.
AUTONOMY AND ALIGNMENT
This image — extracted from the famous Spotify Culture video — beautifully depicts how leaders should act regarding empowering their teams with problems to solve.
It’s pretty clear that the optimal quadrant is high in alignment and high in autonomy. But how does that play out in real life? Of course, there aren’t many people crossing actual rivers in tech teams. 😀 So, how does that relate to our case?
Our story begins just after the pandemic, at a time when every company in the market was striving to optimize its cost structure. Our company was no exception and, as mentioned before, the cloud costs after the last Black Friday were still haunting the team.
Following a series of "intense" meetings among product, engineering, and the finance teams, there was still a lack of clarity on how to achieve greater cost efficiency. It was a time when you could feel the worries about costs just by walking down the corridors. Finally, In a one-on-one, the CEO brings the issue dramatically and tells the director of engineering:
“Our cloud is expensive. There is another provider that did a quick diagnosis and says that they will be way cheaper. We need to change providers!”
I believe you can look at the autonomy-alignment quadrant and see where we are now, right?
Well, we can see that at this moment the CEO is giving a direction and pointing to a solution without knowing much about how cloud costs work and the cost of migration. There might be alignment, but the autonomy part is missing.
He was looking for a quick solution. It’s important to remember that CEOs are also human beings and sometimes under stress — like all of us — they tend to look for quick fixes. And, of course, the sales department of the new cloud provider said it would be very easy even without a close context to the software the company was hosting on the cloud.
The Director of Engineering had experience with multiple cloud providers and knew the promises from the new provider were too good to be true. She also knew that migrating software as complex as they had, with millions of users, to another provider in a rush could be a several-months project and potentially create a huge impact on the throughput of all product teams and to the end users themselves. She had done that before and had the scar tissue to prove it.
So, she clenched her fists and prepared to fight.
Metaphorically, of course. But she shouted for real:
“We are not expensive!”
The CEO was caught by her reaction. He trusted her. So he showed vulnerability, lowering his voice:
“We are not? You don’t think we could improve our costs?” he asked genuinely.
When the CEO showed empathy, she became disarmed. Fists down, she said:
“Aaah. I don’t know. We have to figure it out.”
The dialogue above was simplified for brevity but it pictures well what happened that day.
The very nice thing that happened here is that — although it started almost as a fight, which is more common than not in many organizations — the CEO and the Director of Engineering trusted each other and were able to communicate.
Even better, they realized that neither of them knew if they had a real problem with costs.
It was up to the Director of Engineering to find out and come back to the CEO.
DISCOVERING THE PROBLEM
After the last 1–1 with the CEO, the head of engineering started to look for a baseline from where they were as a team in terms of cloud cost.
She spent a couple of days researching and managed to find, with some fellow engineering leaders, a very nice benchmark done by the CFO of Harness.
You can find the benchmark here. It’s a very good report on the state of cloud spending for SaaS companies.
One particular thing that caught her attention was the image below:
She knew from the executive team reports what the company’s Annual Recurring Revenue (ARR) was. She also knew, by heart of course, the amount of cloud spent — that was where the issue started. The company ARR was in the $50m — $100m bucket, and the percentage of cloud spend was around 23%. She knew she was onto something. The CEO’s fear was real. They were very inefficient in terms of cloud spend.
She knew she had to do something. She had already known from previous conversations with the CEO and the financial department that the cloud spend directly affected the company’s gross margin, one its main indicators.
She rushed to the CEO and told him all her findings.
It was bittersweet for him. He was pleased to see the data. But it was not a hunch anymore, the problem was real.
Still with butterflies in his stomach, but with an even higher level of confidence in the Director of Engineering, he asked:
“What are we going to do about that?”
LEADING WITH CONTEXT, NOT CONTROL
Before continuing with our story, there is a very important concept I would like to bring attention to now: the concept of “LEAD WITH CONTEXT, NOT CONTROL,” which is one of Netflix’s mantras — more on that can be found in the excellent book No Rules Rules: Netflix and the Culture of Reinvention (p. 207).
Leading that way takes way more work, especially at the beginning, when you are not used to it, you don’t have data, etc.
However, this approach, when combined with the autonomy-alignment concept, is a very effective way of generating results at scale.
If we recall the previous interaction between the CEO and Director of Engineering, we can notice that part of the information necessary to solve the problem effectively was with each one of them. None of them had the full picture, as is usually the case.
The CEO knew that it was important to focus on controlling costs to create a sustainable business with good margins. He also knew that cloud costs were a big chunk of the company’s costs.
The Director of Engineering knew that migrating cloud providers for this company was not as easy as some people with less experience in this kind of migration thought it was. But she did not realize that cloud costs could be harming the company.
The magic happened because the CEO managed to control himself, gave context to the Director of Engineering explaining the company’s costs and how cloud costs were included in them. After that, he gave her the mission to discover if they were efficient in managing cloud costs.
After she investigated and realized that they really had a problem, she felt she owned it. It was not only the CEO’s problem anymore. She had to find a solution because their company was suffering. They had started to move from the quadrant: high on alignment/low on autonomy to the one high on alignment/high on autonomy as pictured in the image below. Now she had to do the same with the engineering team.
CREATING ALIGNMENT WITHIN THE SQUADS
Now with the context in hand, she called the engineering managers and senior engineers from each squad to explain the problem they were facing. To her astonishment, they were unaware of how much the company spent on cloud services or any details about the company’s overall costs, including key KPIs like Annual Recurring Revenue (ARR) and the company’s gross margin.
In her mind, she couldn’t help but think:
“Are these people crazy? It’s hard to sell our products, we’re spending a fortune on the cloud, and they don’t even know the costs of what they build. That’s insane.”
This first meeting did not go well.
She thought: The team did not get it.
She finished the meeting, her cheeks red, a thousand thoughts crossing her mind.
She started immediately to think of ways to solve the cloud cost problem. Maybe she could do some optimization in AWS reserved instances? Perhaps, she could look at optimizing some part of the software, but what part? What about contracting external consultants to solve the problem?
As she started to walk back home that day and think about the burst of frustration she had in the meeting, she took a deep breath and remembered the first meeting she had with the CEO about that topic. Then, the penny dropped!
She realized that it was also her fault. She acted exactly like him in the beginning.
If her team didn’t have the context, it was her responsibility as a leader to help them. She had just recently discussed with the CEO that if context is provided and people understand the problem, they can be held accountable for it. If she wanted her team to come up with a solution, they needed to understand the problem first. That was what her leader had done with her and she realized it was important for her to do the same.
Calming herself, she spent the rest of the week coaching them on cloud costs, company expenses, ARR, and other crucial financial metrics. More importantly, she arranged several meetings between the engineering leaders and the finance team so they could start understanding the costs together.
FINDING THE SOLUTION
The team did not immediately get up to speed as a whole. However, one of the squad managers teamed up with a senior engineer and they realized they lacked good visibility on AWS services costs.
They began tagging the AWS resources, associating them with the squads and their respective assets.
After a couple of days, they dove into the cost explorer and started looking for opportunities.
And they found a lot of interesting things.
One of the first discoveries was that their ElastiCache costs accounted for more than 6% of their monthly bill — several thousand US dollars per month. This seemed enormous, considering they believed they only had a small cache for a particular API.
They also noticed that the RDS costs for one of their products had increased by more than 50% in recent months.
OUTCOME, FINALLY!
It did not take long for the squad leaders to start incorporating those insights into their team meetings. Initially, they instinctively wanted to come up with solutions immediately after seeing the numbers. However, they had learned from their CTO — who had, in turn, learned from the CEO — that context was crucial to making people accountable for the problems and, more importantly, enabling them to solve them.
And that was exactly what the team did.
When they understood that their ElastiCache costs were disproportionate, they realized they could compact the content being cached and save a significant amount of money without compromising user performance. This led to a highly positive outcome: lower ElastiCache costs with no noticeable impact on user experience. The leaders were relieved, and the team was energized.
They then tackled the next issue and discovered that some engineers did not fully understand how RDS costs worked. They had been saving images as blobs directly in the database, a very inefficient way to use cloud databases. By saving only the IDs in the database and storing the actual files in S3, they dramatically reduced database costs. Over a few months, the company saved a substantial amount — RDS costs went down by more than 40% — the teams were thrilled!
OUTCOME AT SCALE, FINALLY!
After one squad was working like that and had very nice results, all the other squads started to see the value they could generate.
Inspired by the initial results, the CTO and their squad leaders continued to double down on giving context and showing the results to the whole team whenever they could. So the whole team kept aligned on cost optimization and felt valued when providing solutions.
Every squad helped target the overall goal of world-class cloud cost efficiency.
They created a unified opportunity table like the one below and started to tackle the ones that generated more value per team effort.
After a few months, many cost-saving opportunities were found and fixed, and their cloud costs decreased from 23% of their ARR to about 10%. That saved the company several thousand US$. That was huge.
One day, after the executive review where she had reported the savings above, the CTO was reflecting on the long path they had crossed since the first meeting about the costs with the CEO. How they managed to create alignment to the cost problem while allowing the people who were best equipped to provide the solution to do so.
It was a long journey but they managed to:
- work as leadership team to identify an important problem for the teams to solve — As an executive team — the CEO, her and other senior managers were able to work together and find a problem that was important to the business and validate their insights with data.
- Giving context and aligning the team on the problem — They managed to give context and alignment to the team enabling them to understand why the problem was important to solve and while making them feel committed to solving it.
- Empower the team — Finally, they were able to empower and trust the team in coming up with a solution after they understood the problem
And, they managed to do all of that across several leadership layers from the CEO, to senior product leaders down to the squad level.
It was the first time in months that everyone was actually happy with the cloud costs, but would they be able to keep that in the culture for the future? While thinking and searching, she bumped into this article about tech transformation and realized they evolved a lot as a team but there were still things she could do in order to continue in her transformation journey. But that is the topic for a new article. 🙂
