Product managers need devops, and devops people need product managers. This might seem a stretch at first but considering devops ties together all parts of the customer value stream and product managers want to create the best possible product as quickly as possible and keep applications up and running, it suddenly makes sense.
The two groups of people are specialists, and actually are very closely connected to each other in a traditional devops kind of perspective. It starts to make a lot of sense that that a lot of value can be created if they are they are copacetic, especially as the underlying technology makes this possible through the power of innovation and virtualization and vice versa.
It is helpful to join the processes as well as the people, not just to have an understanding of what the other group is doing, but also to be able to play an active role there, and that goes in both directions. What devops has done for the industry by and large is create this understanding that doesn’t make much sense to have these two groups totally separated with the same hand-over moment that we had between development and operations. Many of the same kind of failure modes and many of the same challenges apply.
Benefits to product managers that devops can provide
It is an antipattern to have an artificial wall between devops and product management, but it still persists in many places.
Shared understanding, shared goals, and shared incentives are absolutely important to creating closer collaboration. Anybody reading devops blog posts will have heard exactly this, but it might be new to the product managers.
Product managers, like developers, need to think about why you should be building a particular offering, as opposed to the common approach of simply putting resources into building it the right way. You need to make sure to solve the problems that need solving. You need to have a deep understanding of who it is that you’re solving the problem for. And yet, in most of the industry, you have a pretty strong disconnect between the technologists building the new products and the customer.
All product managers have had users come to them and tell them that they can’t use the product because sometimes it blows up. This definitely makes the product manager want to fix this problem more when this happens. They should head right for the devops team, who generally have a “we can fix it” mentality and skill set.
One great technique is dogfooding, of course, where you are your own user. And dogfooding is one of those things that everybody says, “Oh, that’s natural,” but nobody really quite does it, because sometimes it is difficult. Turns out the devops team would probably love to do this—its job is to automate fixes to problems. There are lots of other options as well. For example, you can have one of those famous customer days, where your product management team goes and sits in an office and spends hours talking to your customers. The devops team may be barely a floor away, so go around and bring it into the meeting.
And then there are more regular things that a lot of companies may not really execute on, which is have a rotation through customer service or a community forum if you’re working on an open source tool. Every few weeks, a devops engineer can spend some time actually reading through the problems the customers and users are having, and gain invaluable experience dealing with them.
Devops is a set of concepts and a set of principles that is very powerful, because it transcends particular technologies. I don’t want to trivialize these principles and practices, but it’s important to recognize that you have to pick and choose and adapt to make them fit your context and organizational maturity. Clearly there’s a middle ground between blindly following something and having nothing to go on.
Here are some of the key how to’s,
Align incentives
We know in devops it’s the easiest thing to say, and the hardest thing to do. If your head of infrastructure has a different motivation from your head of product development, they are not going to work together well. If they are motivated in different ways—for example, if the head of product gets a bonus for customer retention, and the head of development gets a bonus for feature ships in production—you have a problem.
Another classic incentive misalignment is when engineering is incentivized to build complicated, large, highly scalable, sophisticated products, and ops just wants to keep the store up and running.
Get the right data and metrics
For my company’s clients, who are really developing and transforming into a devops cultural and collaborative process and mindset, we use an open source data correlation or presentation tool. One of the important things about the tool is that it gives the ops people the data they need, in a single pane of glass. It gives the dev people the metrics they need, and it also gives the business owners and product managers a presentation of the data that makes sense to them, which are typically revenue, e-commerce uptime, and performance during peak periods.
Benefits to product managers that devops can provide
One of the things that drives devops is that, if you can see the amount of failures you have when you go to production, you have an immediate task that you can try to move the needle on. We think the same goes for product success. It may be hard to define product success at a granular or precursor level, but once you do that you have a devops and Lean way to measure product success. Devops metrics become more and more available and cloud systems are giving a lot of it for free. That doesn’t necessarily mean that they are the right ones, but they are definitely better than nothing.
For example, you can correlate a report on retention or cancellations with latency and outages. By and large, defining what customer success is and putting the metrics in place is often way down most teams’ priority list. Devops can more easily get this done than most teams, because of the available tools, skills, and mindset.
Instrumentation is hard. Getting business level instrumentation right and doing it in a way that doesn’t degrade the application is key. You don’t want to hang the application because it’s trying to send 10 million bits of data back to devops.
One example of devops-generated business instrumentation that is very interesting to figure out is feature activity. If product managers can’t show this, they can’t demonstrate that what they’ve built is actually worthwhile.
Sometimes devops teams have discovered that if they harmonized their logging, they would have better outcomes. Or that if they had better correlation IDs between our PC calls, they could trace applications or transactions better. It’s great when devops understands the application, and that application metrics are not outside their scope of responsibility.
One of the things that works is that on a rotating basis, using a grooming session, the product manager sits down and goes through the backlog and figures out with devops some priority fixes. I’ve seen product managers give the devops team some kind of advance notice of what was coming, and this also provides an opportunity to talk about why certain things are more important than others. This removes the pressure of immediately having to estimate them and try to shove them into a two-week sprint.
Summary
Benefits product managers can provide to the devops:
- Demonstrating a collaboration mindset; all project managers really do all day is collaboration, communication, and consensus—they are supergood at it and can generally be a good example for others.
- Bringing the voice of the customer into everything; devops is not a means in and of itself, but the goal is to really speed things up to ultimately delight the customer. For example, think about how the product manager can help justify and build the business case for a new CI server.
- Enabling work flows that allow the team to use its product or get as close to it as possible; a product manager can help champion dogfooding or rotations through customer service, both of which are super valuable
Benefits devops can provide to product managers:
- Deep visibility into the health of a service. This really helps when setting up success metrics and SLAs. For example, what uptime can you promise customers?
- Understanding technical debt and the potential implications (what needs to be addressed so the product can continue to scale without issues?).
- Building tools to help the product team innovate faster; how can new features get out to customers faster? This usually includes build automation, strong testing, etc.
The lesson from devops is that, in an ideal world, development and operations people would both be interested in learning about what the other is doing. And in some cases that’s true, and in some cases it’s not. There’s always going to be a bunch of developers who are more interested in learning about the most recent framework or building an application that scales crazily than really care about its use, but it’s helpful to use devops to help them drive the application business success.
This article is published as part of the IDG Contributor Network. Want to Join?
