I lead the product team at my company and have been working in product-related roles for most of my career. I also count myself lucky that a few past roles have involved working with and selling to developers. This is for lots of reasons, but one of the main ones is that it gave me extensive experience with DevOps principles and practices. Now, as a product leader, I’ve come to believe that there are enormous benefits for teams willing to borrow many ideas from DevOps and apply them across the organization.

For those who aren’t familiar, DevOps is a continuation of agile methodologies. Agile broke down the walls between product and engineering, turning software development into an iterative process and enabling cross-functional product development teams to quickly adjust to changing market and customer requirements. DevOps extends this model by giving responsibility for development and operation of software to the same teams. The theory is that if developers are responsible for both building and operating software (instead of assigning those responsibilities to separate teams), they will make the right tradeoffs between working on functionality (building new features) and working on operability (stability and performance). The outcome is better product quality, higher velocity, and happier customers.

While not every DevOps practice can apply to every function, I’ve identified three practices that I believe deserve wider adoption, especially among product teams. These three DevOps principles area culture of blamelessness, a strong belief in measurement, and an ownership mentality.

Culture of Blamelessness

A culture of blamelessness should not be mistaken with a haphazard, “anything goes” ethos. Rather, in the context of DevOps, it acknowledges that operating software is complicated, especially in fast-growing businesses where you’re pushing the boundaries of scale and speed. In this environment, mistakes (incidents) will happen. But when they do, it’s important to treat them not as failures, but as opportunities to learn and improve. And this improvement will only happen when those involved know they will not be penalized for making a mistake, and thus will be open about what happened. Hence the principle of “blamelessness.”

How does this apply to product management? Well, most digital product owners are in the business of building new user experiences. Whether you are at Uber and revolutionizing local travel or you’re a restaurant responding to the pandemic by standing up an online ordering platform, you’re simply not likely to build the perfect experience from day one. The only way to make your experience better is to experiment and learn. It’s to quickly formulate hypotheses, test them, measure, and repeat. Key to it all is creating a culture that celebrates experimentation, regardless of whether results prove success or failure.

Why is it important to celebrate failed experiments? Well, as anyone who has been part of an experimental work culture knows, failed experiments often provide as much (or more) value than successful ones do. I’m still struck by how counterintuitive some results are. For example, when multiple customers routinely stall out at a certain point of their “journey” through a website, it may seem logical to surface helpful information in the form of a link or a pop-up box that appears at that moment. In fact, this is often not the case. It turns out distractions (of any kind) in a workflow typically lower conversion rates. And discovering this -- that surfacing helpful information at key points can reduce a conversion rate -- is a success of the experimentation and data-gathering process. Indeed, in a culture of blamelessness, everyone understands that successes happen because of, not despite, past failures.

So, what does the experimentation anti-pattern, i.e. a culture of blame, look like? It's one in which people don’t take chances because they’re worried about negative consequences. Allowing a culture of blame to take root is one of the easiest ways to stifle innovation.

Metrics and Measurements

A successful DevOps process requires immediate and readily available feedback on the systems the team is operating. This means metrics on service uptime, application response time, operational load, and more. To ensure that customers are getting a good experience, every user interaction needs to be measured and anomalies reported immediately.

This focus on measurement is just as important for a digital product owner. Every new feature or UI adjustment should begin with a hypothesis about the metrics we expect it to move. Data should be driving our roadmap decisions. And each change needs to go out with the ability to trace its impact. Following the discussion about experiments above, one might say that a true mistake in experimentation is not being able to measure the impact an experiment had. And if multiple experiments are running at once, it’s essential that the team be able to differentiate the effects of each change.

One common anti-pattern you see in an org that is not data-driven is when roadmap decisions or experimentation ideas are largely decided by the HiPPO (Highest Paid Person’s Opinion). Further, in an org that isn’t data-driven, success of development efforts is often measured by how much is launched in a timeline, as opposed to the actual impact that the new capabilities drove.

You Build It, You Own It

Another important DevOps principle is a strong culture of ownership. Simply put, the team that builds a feature or service is the team that operates the code. If something fails in production, they are the ones who are notified, and they are the ones who fix it.

The same principle can be applied to digital product ownership. Great digital product owners think of their product or ownership area as a business -- with KPIs they are responsible for moving. They and their extended team are empowered to prioritize a roadmap that produces the outcomes the business is looking for.

The anti-pattern for “you build it, you own it” in the world of the digital product owner is overemphasizing the new. This is apparent on teams where the vast majority of investment goes toward new features (the next new shiny object), and teams don’t find time to iterate and improve existing functionality. Long-term this is a losing business strategy. First, it often leads to products becoming overly complex. Second, it means that teams are not getting the full value out of the capabilities they launch, since they’re not optimizing those capabilities post-release. This is very short-sighted, as the biggest impacts can be realized by making small iterations to existing capabilities -- for example, improving discoverability even a little can dramatically improve adoption rates.

Conclusion

DevOps strategies emerged to optimize the delivery and optimization of modern software, but their lessons are broadly applicable, even for teams that might not ever write a single line of code. These principles often seem counterintuitive, but celebrating failed experiments, using data instead of gut instinct, and investing in optimizing your existing product will ensure that you deliver the best experience for your customers and the best results for your business.