Product Thinking for Cloud Native Engineers: From Cost Centers to Value Drivers

In today's rapidly evolving tech landscape, cloud native engineers often find themselves in a challenging position. While their work forms the backbone of modern software delivery, they're frequently viewed as cost centers rather than value drivers. Stéphane Di Cesare and Cat Morris, experienced professionals from DKB and Syntasso respectively, presented a compelling framework for how engineers can transform this perception by applying product thinking principles to their work.

The Shift from Cost Center to Value Driver

"We realized how much more difficult it is for operations people to show which value they're bringing compared to people who are building something," shared Di Cesare, reflecting on his experience with performance reviews at a consulting company. This observation sparked their exploration of how engineers can better demonstrate and deliver value.

Historically, IT departments were viewed as cost centers—focused on maintaining infrastructure with minimal disruption. While IT has evolved significantly, many organizations still treat engineering teams as expenses rather than investments. Product thinking offers a way to change this narrative by focusing on outcomes rather than outputs.

"IT should be the cheapest possible," Di Cesare noted, describing the traditional mindset. "This is very often the way as engineers we think about value as well."

Understanding Product Thinking for Engineers

Product thinking isn't about becoming a product manager—it's about adopting a mindset that prioritizes user value, problem identification before solution building, and outcome measurement.

Core Principles

1. User Value First: Understand who your users are and what value they derive from your work
2. Outcome Before Output: Focus on impact rather than activity
3. Product Before Projects: Consider the full lifecycle of what you build
4. Problems Before Solutions: Identify real problems before jumping to solutions

"What is important is to first show the value of your work," Di Cesare explained. "Focus on what the outcome of what you're doing is, so not the output. Not only how much work you do but what does it bring for the people who are using this work."

Understanding Your Users

When working on cloud native platforms, engineers often identify developers as their primary users. However, a complete view reveals multiple user types:

• Builders: Developers in product and application teams
• Enablers: Those who help others use the platform
• Regulators: Compliance and audit teams
• Viewers: Finance and management needing visibility
• Future Users: Those who will adopt the platform later

"The platform has other values for other people," Di Cesare emphasized. "You will have builders who are developers in product teams, in application teams outside your platform, but also internal ones. It's important to keep them in mind as well."

The Double Diamond Framework: Identifying Problems Before Solutions

One of the most powerful concepts presented was the "Double Diamond" framework, which emphasizes the importance of spending time in the problem space before moving to solution space.

"Often, if you're in engineering it's very tempting to go straight into the solution space," Morris explained. "This is the classic build, measure, learn loop. What am I going to brainstorm? How do I build it? What am I going to build? Iterate over that to get more value."

The Double Diamond consists of two phases:

1. Problem Space: Explore and define the problem
2. Solution Space: Develop and deliver solutions

A Cautionary Tale

Morris shared a personal experience that perfectly illustrates the danger of skipping the problem space:

"My first official platform role was a long time ago now, and I was parachuted into a team as the platform product owner... I looked at my team. I'd worked on platform adjacent things before and internal tooling but it'd never been called this. I was like, what do we need to do? We've got this budget, this team has been formed, what are we going to do?"

The team identified that their Jenkins pipelines were outdated and needed migration to Azure DevOps. "We spent about three months, maybe a bit more, migrating all of the build pipelines from Jenkins to Azure DevOps because no one in the team knew Azure DevOps but they knew Jenkins really well."

The result? "By the time we got into Azure DevOps we realized we still don't know Azure DevOps, so maintaining it was really painful. The operational costs were really high at the same time. Actually, there was no user value. There was literally zero impact to the business because it was just as hard to maintain these things. The users had the exact same experience."

Exploring the Problem Space

To avoid such pitfalls, Morris outlined techniques for exploring the problem space:

1. Customer and Stakeholder Interviews: Talk to your users and business stakeholders
2. Data and Process Analysis: Examine pipelines and processes for pain points
3. Shadowing: Observe users as they work with your tools
4. Business Context Understanding: Read business updates and understand company goals

"Shadowing is one of my top recommendations if you can do it," Morris suggested. "Anyone in your role can do it. The best thing about working on a team that builds software for internal users is you have unprecedented access to these people."

Defining and Prioritizing Problems

Once potential problems are identified, they need to be defined and prioritized. Morris suggested several frameworks:

1. Value vs. Effort: Plot problems on a matrix focusing on high-value, low-effort items
2. RICE Framework: Consider Reach, Impact, Confidence, and Effort
3. Opportunity Solution Tree: Start with high-level problems and explore potential solutions

"The Opportunity Solution Tree is a model that was created by Teresa Torres in her book, 'Continuous Discovery Habits'," Morris explained. "It's really good. She's crazy smart and also has a lot of stuff of how to do product management with AI."

Choosing the Right Metrics for Developer-Focused Tools

Metrics are essential for demonstrating value, but choosing the right ones is crucial. "Who here is working as an engineer at the moment? Who likes working with metrics?" Di Cesare asked rhetorically. "Typically, this is a topic that engineers have a tendency to flee somewhere else when we start talking about metrics."

DevEx Framework

The Developer Experience (DevEx) framework provides a useful starting point for measuring developer productivity across three dimensions:

1. Flow: Minimizing interruptions and maintaining focus
2. Cognitive Load: Reducing the complexity and context switching required
3. Feedback Loops: Providing timely feedback on work

"In the DevEx framework, they divide it in two kinds of metrics, so the perceptions and the workflows," Di Cesare explained. "The workflows, they are more quantitative metrics, things like build time, things like how many steps you have in the deployment. There are perceptions, which are things that are more difficult to put a number on, but they are still important."

Platform Engineering Metrics

For platform engineering specifically, Syntasso has identified four key metrics:

1. Speed: Time to deliver value
2. Safety: Risk reduction and compliance
3. Efficiency: Resource optimization and cost reduction
4. Scalability: Ability to handle growth

"There are other frameworks as well. DORA was really the first one which was in this area, comes from this 'Accelerate' book," Di Cesare noted. "I think it's the first book which really went into what is the value of DevOps and of trying to improve the speed of deployment, speed of feedback."

Implementing Instrumentation

Regardless of the framework chosen, implementing proper instrumentation is key to measuring outcomes effectively.

"Implement instrumentation. These are really helpful for proving the value of what you're doing," Morris advised. "It could be real time. It could be that you build a monthly report that you export around what you're doing and the improvements that you're making in an organization. What value you're delivering. How much faster are people moving? How much cheaper are your services? These are things that are going to really make it much more easy for people to understand what value you're delivering. Everyone loves a good dashboard."

Practical Techniques for Bringing Product Thinking to Your Role

Even if you're not a product manager, you can apply product thinking principles to your engineering work. Morris and Di Cesare shared several practical techniques:

1. Shadow Your Users

"Shadowing is one of my top recommendations if you can do it," Morris emphasized. "Anyone in your role can do it. The best thing about working on a team that builds software for internal users is you have unprecedented access to these people."

When shadowing:

• Observe without interrupting
• Note workarounds and pain points
• Look for patterns in behavior
• Don't correct users—take notes for improvement

"The big thing of this actually, is make sure you don't tell them what they're doing is wrong," Morris cautioned. "Don't say like, no, you just click this button. If you can help them, great. Take that as feedback for you to improve your tooling, not to dunk on your users."

2. Ask "Why" Relentlessly

"I want you all to become the annoying toddler in the room that asks why way too many times as everything's happening," Morris suggested. "If someone tells you, 'I want you to build this, I want to fix this'. 'Why? What are you trying to do? Why should I fix that? Why are you trying to do that? Why aren't you using another tool?'"

This technique helps uncover the root problems rather than addressing symptoms.

3. Understand Business Context

"Read your business updates," Morris advised. "I know it's not the most fun job in the world, but this is going to give you really good context into what your business is trying to do. Is it trying to reduce operational costs? In which case you need to make sure that you're adding value. Is it trying to improve the speeds of delivery? Are you trying to invest in a brand-new region? That's really good information if you're building internal tooling because then you're thinking about different regions that you might need to deploy software into."

4. Apply Product Thinking to Your Career

Product thinking isn't just for your work—it can be applied to your career development as well.

"These are things that you can use personally as well, as an engineer for your career," Di Cesare pointed out. "You can think about, who are your users? There is probably your manager. Part of your job is always to help your manager reach his goals. You have to ask, what are your goals? When do you get a bonus? Things like that. Also think about more long-term, is there a specific position you are aiming at? What do you need for that? Then it's important to think also that way. What are the goals I want to reach and discover for the people who are controlling this? What are their goals? How can I help them reach their goals?"

Morris added: "I set my one performance review cycle. I set my goals for the year as OKRs, Objectives and Key Results. Basically, I set myself targets, and because I hit them, I could be like, 'We agreed this was promotion criteria, can I have my promotion now?' It worked. I can recommend it for you."

Conclusion: The Benefits of Product Thinking

Adopting product thinking can transform how cloud native engineers are perceived and valued within their organizations. By focusing on outcomes, identifying real problems before building solutions, and measuring the right metrics, engineers can demonstrate their value beyond simply maintaining systems.

"Product thinking, if you are a cloud-native engineer, maybe building tools for other developers, or data, internal tools. Think about user value. What is your user actually getting out of this thing that you're building?" Morris summarized. "Think about the problems that you're trying to solve before you try and solve them. That's really linked with that user value. Choose your outcomes over outputs. What am I trying to achieve, rather than, I've delivered this many tickets? Consider that lifecycle. Your operational costs are part of your costs as well. You're not just building once and done. Explore, define problems to maximize that user and business value. Go into really thinking about what is that problem that I've thought about. Finally, measure your metrics to show your results."

By embracing these principles, cloud native engineers can shift from being perceived as cost centers to becoming recognized as value drivers who directly contribute to business success.

For more information on product thinking for engineers, check out:

• Teresa Torres' "Continuous Discovery Habits"
• DORA metrics
• DevEx framework