Why Private Equity Needs DevOps for Product Led Growth

Private equity may like high margins in a portfolio company, but what they really like is growth. We’ve talked about how to improve the margins in an organization after a lot of M&A activity, but how does one use DevOps to improve growth?

The software portcos I work with want to be “product-led”. Operating partners I talk to have suggested training like the offering from the Silicon Valley Product Group (SVPG) to improve the product of an organization. But is DevOps at odds with being product-led?

Many DevOps proponents are big fans of Agile to keep work flowing through an organization. In Agile, aren’t the development teams responsible for what is developed? While it’s true that Agile teams (stream-aligned in Team Topologies vernacular) have a lot of autonomy, they are also developers. Their primary responsibility is development. What to develop needs to be done in concert with Product.

When the SVPG talks about Product Discovery, they share something core with the DevOps movement: Lean. One of the original models to describe DevOps was CALMS (Culture, Automation, Lean, Metrics, Sharing). In Lean, and in Toyota Production Systems specifically, there is Systems Thinking (the First Way of DevOps) and Feedback (the Second Way of DevOps).

The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure. Therefore, it’s no surprise that when talking about product learning, the SVPG describes:

“Culturally, it’s critical that the organization understand that discovery and innovation is about continuously running these rapid experiments and learning from the results.”

I like “learning from the results” better than when Gene Kim says “learning from failure”, but the rapid and continual experimentation is Lean.

Experiments in DevOps

When working with portfolio companies on improving their DevOps practices, we’re also working on their product practices:

  • Embracing a project to product mindset. We set up long lived teams that deliver products that allow the rest of the organization to move faster (systems thinking) by continuously improving capabilities and facilitate feedback loops (2nd way) because they find out the results from experiments much faster. If you can build representative test environments of your top 5 customers on-demand, you have a tight feedback loop.
  • Empowering Teams with Self-Service and “Shift Left”. We enable development teams to provision their own infrastructure and deploy software by making it easy and safe to do things earlier in the process. This reduces dependencies and waiting (waste in Lean). This platform approach empowers continuous delivery without manual bottlenecks.
  • Leverage Cloud Flexibility for Discovery. The public cloud’s primary advantage is flexibility not cost. This flexibility allows for rapid experimentation to determine both optimal infrastructure implementation but also to get product feedback. If I have the ability to deploy multiple Kubernetes pods simultaneously behind a robust feature flagging system, and direct the traffic appropriately as a result, I have the ability to create a situation where I am “running rapid experiments and learning from the results.”
  • Leverage AI to create more experiments. If I have strong DevOps fundamentals in place, that means I will have comprehensive testing done on all the code that I write. Product folks are discovering that AI allows them to quickly prototype a number of experiments, and if those can be proven to work correctly (through tests), then we can pick the very best out of this portfolio of experiments to either run further experiments based on what we’ve learned, or go forward with developing that prototype into production code.

DevOps for Product?

Remember our CALMS model above? Eventually the originators (Edwards & Willis) dropped the L, but it is not too difficult to imagine mapping the CAMS model to SVPG Product Discovery:

Culture: It’s the very first word in the quote above. Product Discovery is not a project we implement and then throw away, it’s a culture in the organization. In DevOps, we describe those high-performing cultures as Westrum Generative.

Automation: If we are going to run all these experiments, we are going to need automation or it will get very messy, very quickly. We want automated tests, automated artifact builds, and automated deployments. This automation allows us to collect feedback quickly.

Metrics: The feedback we collect needs to be in a form that we can analyze. There will definitely be qualitative feedback that is collected, but also quantitative. Being able to track the results of our experiments and use that to make data-driven decisions is a fundamental part of our experimentation process.

Sharing: At the end of the linked SVPG article above Cagan has advice on to how to do this correctly:

  • “The big learnings are important to share broadly, especially when things don’t go as hoped.”
  • “It is also important culturally that the product organization be transparent and generous in what they learn and how they work.”

Sharing what we learn broadly. Whether that’s between development and operations, or operations and security, or the product organization and other teams. Sharing is a fundamental part of DevOps and Product success.

Innovation for Business Outcomes

We know from the research that high-performing DevOps organizations are “twice as likely to meet or exceed their organizational performance goals”, including increased revenue, customer satisfaction, market share, and optimized costs.

Certainly one of the ways to achieve some financial outcomes is to have high margins. But the number one lever of private equity is growth! We can have automated tests, we can have dynamic cloud infrastructure, but the way those are used in product-led companies is to create better products.

Products that don’t have maintenance windows resulting in downtime.

Products that are performant, even under load.

Products that innovate quickly by creating portfolios of experiments so we can quickly and easily discover the things that will lead to Product-Led growth, as well as a better working environment for employees, better performance for executives, and better returns for investors. Win-win-win.