Kubernetes is renowned for its undeniable power, but mastering its intricacies often feels like scaling a steep learning mountain. Yet, for those seeking to harness its potential, not just as users but as providers, collaborators, or customizers, the journey presents an even greater challenge. In this blog post, we embark on a voyage to explore the art of product management within the realm of Kubernetes. Join us as we delve into a mindset that can serve as your climbing gear, enabling you to extract the maximum value from your Kubernetes setup by treating it as a holistic product.

Product Management and Value

Let's begin with the first stage of our ascent by unraveling the concept of product thinking. At its core, product thinking places the value your product brings to your customers front and center in your strategic endeavors. It's not just about fulfilling requests for features; it's about diving deep into the 'why' and 'what' behind those requests.

With product management your attention should stretch beyond just the delivery of your product. It encompasses the comprehensive exploration of your customers' needs and preferences. This entails understanding the problems your customers face, how they interact with your product, and most importantly, why they choose your product in the first place.

To navigate this terrain effectively, modern product teams employ a diverse array of methodologies and frameworks. These tools, including visions and missions, personas and jobs-to-be-done, prioritization techniques, and roadmaps, all serve a common purpose: to mitigate risks associated with the desirability, feasibility, and viability of your product. Essentially, they serve as compasses to ensure that your development efforts align seamlessly with genuine customer demand and remain economically sustainable.

Product management, when guided by the principles of product thinking, can lead to the creation of products that truly resonate with and serve your target audience.

Understanding Value in Infrastructure

Now that we have product thinking and the focus on value as our base camp, let's tackle the next stage of our ascent: how do we map these onto an infrastructure product? Imagine running an online shop; it's relatively straightforward to see how direct value is delivered. Customers visit your website, place orders, and you generate revenue. The value is tangible, immediate, and easy to trace. However, when we shift our focus to infrastructure products, things get a bit more complex. Much of the value they offer is indirect, lurking beneath the surface.

In the realm of infrastructure, the true value often lies in what your workloads and applications engineers deliver. It's not about the infrastructure itself, but rather the seamless and efficient functionality it enables for these teams. While the online shop's value is to generate revenue, the infrastructure's value lies within making the online shop available at all times to generate this revenue and giving the engineers of this shop enough time and headspace to improve their product.

Most of the time the real value of infrastructure products is making the lives of application developers easier, making their applications available for the end customer. One helpful tool to identify the value within your organization and how the infrastructure helps to deliver this value is User Needs Mapping, created by Rich Allen for Team Topologies to explore team and service boundaries. In Figure 1, you can see such a model for the online shop example, where the capabilities of the customers get mapped down through various systems to the infrastructure.

Figure 1: Online Shop Example of an User Needs Mapping Model

As we can see in this holistic view on the value delivery of the online shop the contribution of infrastructure within the value chain is indirect. Even if our own organization directly sells infrastructure to other organizations, they will still use this infrastructure as an indirect contribution within their own value chain. There is no intrinsic value in infrastructure alone.

Understanding Customers in Infrastructure

Due to the indirect nature of value delivery of infrastructure products, we face a special challenge regarding the target audience of the product. While you should keep the overall value chain of your organization and with it your end customers in mind, you usually do not address them directly. Instead, you interact with the application developers in between. In many cases, your offering might not boast a flashy user interface (UI) but instead provide an application programming interface (API), making your product and its audience inherently technical.

These intermediary engineers can even consist of different layers. Imagine you provide Kubernetes clusters for an internal developer platform. In such cases, it's not uncommon - and, in fact, advisable - to 'eat your own dog food' by using your own product. This means that alongside the application developers, your internal platform engineers become users of your product as well.

But while engineers are deeply vested in your product, they are seldom the ones holding the purse strings. In most scenarios, it's their management who wields the budgetary power.  Therefore, your attention must span two key groups: your customers, who are the decision-makers in managerial roles, and your consumers, who are the engineers actively working with your product. You have to make your customers happy to close the contract and make the consumers happy to stay in the contract.

In essence, understanding your infrastructure product's customer landscape is about a nuanced dance between catering to technical users and aligning with the business objectives of decision-makers. Balancing, or ideally, combining these interests ensures not only the acquisition of contracts but also their successful continuation, creating a harmonious ecosystem where both customers and consumers find value in your offerings.

Understanding Consumers Behavior in Infrastructure

Now that we have a clearer grasp of our customers and consumers, a pivotal question looms large, akin to the formidable peak of the mountain we aim to conquer: How can our infrastructure product contribute significantly to the broader value chain of our organization? As we learned earlier, infrastructure is adding value indirectly by enabling application developers with new capabilities or reducing their cognitive load and effort working with infrastructure, allowing them to focus on their core business objectives.

For this, we have to understand how consumers (and customers) are interacting with our product in order to enable or optimize their value creation. One invaluable tool for gaining this insight is Jeff Patton's User Story Mapping. This method invites us to step into the shoes of our users and define different activities those users do within the various lifecycle phases of your product. If we take a look at the example of Kubernetes as a Product, these phases might include the Creation Phase, featuring activities like cluster creation and deployment setup, and the Operational Phase, where tasks such as resource monitoring and scaling take center stage.

Particularly in the realm of infrastructure, which is often characterized by abstraction and technical intricacies, adopting the user's perspective and focusing on their capabilities and interactions with the system, rather than fixating solely on the inner workings and components of the system, empowers us to gain a profound understanding of what our consumers and customers aspire to achieve with our product.

By aligning our efforts with the real-world needs and objectives of our users, we embark on a journey to not only meet but exceed their expectations, ensuring that our infrastructure product becomes an invaluable asset in the broader landscape of organizational value creation.

Putting It All Together

As we reach the high camp of our journey up the mountain, let's pause to reflect on the valuable lessons we've gleaned so far. We began by exploring how infrastructure plays a pivotal but indirect role in the value creation within an organization. Then, we delved into the intricate layers of our target audience, understanding that customers and various consumers harbor distinct motivations and perspectives toward our infrastructure products. Finally, we learned how users interact through different activities within various lifecycle phases of our product.

Now, it's time to combine this knowledge into a cohesive framework - the Product Flow. Here we use the product life cycle phases and user activities within those phases as the base structure, like in the User Story Mapping approach. In the Product Flow, we seamlessly weave together the diverse perspectives of customers and consumers, aligning them with their specific interactions within each activity. Consider, for example, the activity of monitoring: a platform engineer may be keen on monitoring the cluster, an application engineer on monitoring the workload, and management on monitoring the cost of resources.

Next, we augment these activities with metrics, which can encompass both quantitative and qualitative measures. These metrics provide us with a clearer understanding of how a specific activity contributes value to our users. In the context of monitoring, this could involve tracking the number of daily dashboard views to ascertain the effectiveness of our monitoring system. We might even segment this data to account for the different viewpoints our diverse users hold or introduce a health range to detect potential product issues, such as over-reliance on dashboards.

In the final step, we derive and map opportunities from the interactions of our diverse users and the metrics associated with their activities. These opportunities represent problem spaces that we can then explore to deliver genuine value to our users. Returning to our monitoring example, if we observe that a dashboard is viewed excessively, we might address this issue by introducing automated alerts, thereby enhancing the user experience.

Figure 2: An example Product Flow of a Kubernetes Product

Through the insights generated by the Product Flow Model, we can illuminate the contribution of our work to the broader organization's value chain. This model empowers us to efficiently identify and prioritize opportunities for enhancing the value of our products, irrespective of their complexity, abstract nature, or indirect impact on the organization's overall value.

++

Join us at KubeCon + CloudNativeCon North America this November 6 - 9 in Chicago for more on Kubernetes and the cloud native ecosystem. 

##

ABOUT THE AUTHOR

Dominik Kress, Product Manager, Giant Swarm

Dominik is a Product Manager at Giant Swarm. There he is responsible for a Kubernetes Platform with Cluster API.

He has been in the IT industry for over 6 years, starting his journey as a Full Stack Software Engineer falling in love with DevOps and Product Organisations to later become a Product Manager for Cloud Technology.

Dominik is very passionate about Cloud Transformation, Product Management and helping people. He loves contributing to the community with talks, articles, or his publications.