DevOps needs a “Product” mindset

Ten months ago I stepped into a new and exciting opportunity at Medtronic. My basic goal is to help my internal “customers” modernize their apps and the ways in which they work, with objectives around increasing our release frequency, quality/reliability of our apps, and to enable a more innovative, autonomous, and accountable development culture.

The journey thus far has been nothing short of invigorating! We’re standing up cutting-edge self-service AWS cloud infrastructure, templatizing pipelines to enable faster adoption, and facilitating the capture and dissemination of DevOps best practices. I’m learning A TON and working with extremely brilliant teammates!

However, my background is in Product Management, so what am I doing gushing over an internal IT adoption project? Why is this opportunity at Medtronic something to be so excited about?

Well, that’s my goal today, to share how applying a Product Management methodology to internal IT initiatives can enable deeper customer success and create deeper meaning for myself and my teams.

From B2B to B2E to E2E

Before joining Medtronic I brought to market B2B products in the digital communications industry. Today, I’m still building products… but I like to say I’ve moved from B2B to B2E to fully embracing “E2E products”.

E2what???

E2E, or “Employee to Employee” is my adaptation of B2E, or “Business to Employee”. Workday and other HR platforms broke ground in B2E, and E2E is my extension of that concept, except where teams within the company are productizing their value to other teams.

My team exists to help other Medtronic teams deliver their apps faster and at higher quality through the internal productization of DevOps and Cloud services.

E2E moves beyond the simplistic “producer/consumer” model of team dependencies common in operations. E2E product teams disdain the notion of a “project” and the iron triangle, so commonly leading to failure.

Fully embracing an agile Product development mindset, E2E product teams see the enterprise as a vast “marketplace” with “customers” who have “underserved needs” and “pain” that is uniquely felt by them but yet is generalizable to many.

These “opportunities” beg a product solution with a “value proposition” that can be brought to “the market”.

Customer success, net promoter scores, objective-key-result indicators, key performance indicators, and even internal revenue/expenses P&Ls (chargeback) can be set up to measure success.

This is what I’m trying to do at Medtronic around DevOps and cloud adoption.

In many spaces, I leave my product-y nomenclature at the door, but the basic thrust of how I’m approaching my mission is unabashedly product-centric, even within the depths of a 100k global employee enterprise.

Why a Product Mindset for Internal DevOps?

Well, we learned like 30 years ago (Hammer & Champy, 1993) that 70% of tech projects fail, so I don’t feel like I need to rehash my “agile vs waterfall” diatribe. That should be obvious by now.

But what is agile anyways?

Damn, I just can’t help myself.

I’ll keep it short, I promise. My basic premise here is “Agile” and “SCRUM” are inherently customer-centric ways of working. With mechanisms such as “customer feedback loops”, sprint reviews, “product owners”, and so forth, one can argue that there’s a built-in customer bias, vs. say “business objectives”, “scope” or other measures of success found in more traditional waterfall settings.

DevOps in particular is particularly difficult to define project scope for, making an agile methodology all the more critical.

But what is DevOps? What does it mean to be “the DevOp team”? We know the DORA report and all the objective measures of DevOps performance (lead time, frequency, etc), but what do we do, build, and/or buy to help us “do DevOps” better? The problem is of course these questions themselves.

You can’t “do DevOps” and there’s no such thing as “the DevOps team”. One can only help others in THEIR DevOps transformation, and a Product Management methodology is the best methodology I know of to help drive this program of culture change.

Applying Product Management to Internal Adoption of DevOps

DevOps is what I call an “infinity term”… there are infinite ways to define the meaning and deploy the word to suit one’s purposes. “The Cloud” is also equally infinite. How do we deal with this?

First Acknowledge DevOps is not a Tool

Every Product Manager knows that “if you build it, they will come” is not a successful product launch strategy. The same is true for internal adoption initiatives and DevOps in particular.

DevOps is NOT a tool. DevOps is a way in which we work, a combination of people, processes, and technology to continuously deliver value. Its goals are to enable us to go faster, achieve higher quality, and be more innovative. Too often folks scope a “DevOps Initiative” to deploying a tool, but that’s only one of the three dimensions.

Product Managers know their biggest blind spot is their own bias to their product. Likewise, with DevOps, we know we need to look past the tools. Product Managers know that the value needs to be bought into and the customer experience with the product needs to be great. Just dropping in a new tool doesn’t ensure either is true.

Don’t start a DevOps conversation with tools. Instead, start where Product Managers start… with your own internal market research.

Start with Market Research

Tech startups similarly begin their journey with limitless possibilities. The marketplace is infinite with many industries, customers, and potential competitors. Key point: before you get yourself sold on one DevOps tool or another, be sure you know what problem you’re trying to solve.

Tabulate these problems as “opportunities” to add value. The DevOps space is huge, so your list may be long. Some examples might be:

• Releases are fraught with fear and doubt
• We are not releasing new features as fast as our competition is
• We don’t know if our application code is secure
• Our app can’t scale or is slow
• I want feedback on my code much faster
• When my app fails I often have no idea where to start looking to troubleshoot
• I spend so much damn money on cloud infrastructure and yet don’t feel faster, more reliable, nor more secure
• Our teams have a “throw it over the wall” to ops mentality
• Our regulatory burden for release approval is extremely laborsome
• Team interdependencies are numerous and complicated; it takes coordination between 10 teams just to build and release one feature
• We have very little objective visibility into our roadmap
• The people who built the thing are no longer with the company

And so on.

I state the obvious here just to say that knowing what problem you’re trying to solve, and what business impact you’re trying to make, is so foundational to a successful DevOps program.

A “tool” doesn’t solve any of the above, per se. None of that gets better by punching in your credit card number. It takes concerted effort supporting the improvement of people, process, and technology to impact the organization change in mindset that is “DevOps”. More important, you need to know what problem you’re trying to solve, and you need to measure your progress towards solving that problem.

Don’t buy a DevOps tool unless you have a measurement strategy to gauge the desired “opportunity” impact!

As you do this market research, you’ll find that some problems are bigger problems than others. Some problems are more important to your business than others. Also, some problems come with solutions more readily than others. These solutions can in fact be “competitors” too… such as other tooling or legacy processes that limit your penetration.

The key: which problem space will you focus on? Your value proposition cannot be “We’ll do DevOps” or “We’ll deploy XYZ tool”… it has to be more specific and a value statement.

MVP still holds water

The minimum viable product is your friend when you have infinite opportunities such as in the DevOps and Cloud spaces. Just deploying a tool does not mean you derive the intended value. Even if the tool does 50 things great, it’s still crucial to dial in on a few key results and value you are focusing on delivering.

The key with any MVP is:

• Minimum capability so as to not over-invest in capabilities that turn out to be not needed
• Viability such that the original use case and opportunity can actually be met or improved

Some of these DevOps tools are SOOOOO full-featured that all you get is dear-in-the-headlights looks, stakeholders are overwhelmed and as a result, old ways of working (culture!) don’t change.

In DevOps, culture is king, and a DevOps initiative is more about changing that culture than anything else. FOCUS is the key, knowing what aspects of culture you are seeking to change, and how you’ll change it (tools, support, engagement, etc) is key too or culture won’t change.

Viability is key too.

If you have a 20-year-old monolith application and you drop in support of Kubernetes, you’ll soon find out that just because you have a cluster running doesn’t mean folks will start using it.

Viability MUST be defined by your customer!

Many DevOps tools and practices far exceed their practicality in legacy, monolith application settings, and as a result “viability” may look different from their perspective than yours.

And isn’t that the entire point of an MVP? To deliver just enough product to get feedback? To then take those learnings into the next “release” and thereby continuously adjust your actions to best achieve success for your customers?

In the DevOps space, a “feature” could be:

• The capability of an off the shelf tool
• A propriety app/tool you built
• Templates enabling self-service and/or extensible code to expedite delivery
• An example architecture, such as an example pipeline or sample “hello world” code deploying something cool via CI/CD
• A collection of “best practices” you want to build awareness around
• A service, such as an internal consulting engagement for teams to get tailored guidance/assistance
• “Spaces” for community and sharing of practices
• Training offerings, demo days, themed hackathons, etc.
• Support offerings, such as “office hours”, Slack channels, etc
• And many others…

Sales and Marketing are Key

The other day I met with a buddy and we were discussing my new role at Medtronic. He was surprised I took the job because of how much I enjoy sales, marketing, and sales engineering, as he knew well. He worried I couldn’t be happy in my new role.

The reality is a “Product Mindset” comes with me no matter where I go or what job title I have. Sales and marketing are important adjacent support roles of any Product Manager, and it’s no different with me in my new role.

DevOps is all about culture. Culture does not change without deep relationships and engagement in those relationships to influence new possibilities, new ways of working. I may not be “dialing for dollars”, per se., but driving adoption of new ways of working indeed takes a lot of salesmanship.

Marketing too is a key enabler of any DevOps initiative. It is invaluable to have a clear and concise “story” for why you do what you do, what value it provides, and how you provide that value. Otherwise old ways of working will just manifest themselves in the new shiny tool you just bought. Culture means folks are bought into a common vision, and good marketing can help us get there together.

Final Thoughts

There’s a lot more I can share, such as what a DevOps E2E roadmap could look like, what “features” you might scope into your DevOps MVP, and some lessons learned as I’ve transitioned into the E2E space. But, this post is already way longer than I thought it would be. Stay tuned for more!

However, I hope at the very least this gives a sense of how a Product mindset can go with you no matter your setting, role, title.

Even at the most basic level, our individual raw skills are our “product” and our manager could be seen as “customer”.

Whether a custodian at your local high school, Product Manager at a swanky start-up, or a leader in an enterprise setting working to raise all boats, product-centricity is a great approach in each circumstance.

Let me know if you agree/disagree! Any examples you have of taking a Product Mindset into the enterprise? Lessons you’ve learned?