Don't Stop at DevOps: Applying an Integrated Approach to Building Product
By Jody Bailey, CTO, Pluralsight
Jody Bailey, CTO, Pluralsight
With the advent of Devops, we’ve seen a major push to integrate two practices to deliver products with more efficient systems and processes. But while this partnership between traditionally separate roles has spurred exceptional progress, there’s still work to be done. The DevOps approach focuses on building products better, but it’s not grounded in designing a fundamentally better product. At Pluralsight, we’ve found that the key to creating products that delight customers is to creatively collaborate on and share responsibility for the final product.
Similar to how DevOps introduced agile development into operations and improved relationships across teams, connecting product managers, developers, and engineers with the rest of the business plays a crucial role in delivering the best possible product. At the core, the key to designing successful products is to take a user-centric approach founded in both empathy and trust with our product and business counterparts.
As you encourage your teams to work more closely, here are a couple of specific ways to make the transition more successful and ultimately deliver the right products to your customers:
Implement Continuous Delivery
Continuous delivery has fundamentally changed the mindset at my company around building products. As an industry, we used to face immense pressure for perfection the first time we released a new feature or launched a new product. Now we have the flexibility to iterate and improve as we go. This ability to release and re-release reduces the upfront risk, enables us to dedicate focus to subsets of customers, and allows us to think about product definition and distribution in a completely new way.
“The DevOps approach focuses on building products better, but it’s not grounded in designing a fundamentally better product”
At Pluralsight, we’ve taken this strategy to heart. In just two short years, we’ve gone from releasing 10 deployments a week to nearly
Generally, we start with a limited release, delivering new products to our internal teams and employees, and then extending to customers and others throughout the Pluralsight community who have opted in for the experience. By electing to push out these smaller, incremental releases, we’re able to easily manage any bugs or negative issues that arise. Releasing in short spurts also enables us to effortlessly rollback with no downtime and little to no impact to our customers.
We’ve taken a multi-faceted approach to measuring the success of our deployments. Our team analyzes the number of rollbacks we conduct, as well as quantitative and qualitative data from our users. We’re able to track usage to see if the products are being used as expected and collect feedback from our test users to determine if the latest update solves a problem or makes our customers’ lives easier. As a result, we’re able to track the progression and impact through each stage of the release–using it to guide our next move.
Develop Autonomous, Cross-Functional Teams
Having your development and product teams work in silos doesn’t cut it anymore. To unlock true value, you need autonomous, cross-functional teams made up of product, dev, DevOps, QA, and UX specialists who bring different backgrounds, viewpoints and skills to the table. By building these diverse teams and empowering them to own their services and choose their technologies, we can innovate and deliver great products even faster.
At Pluralsight, we created our service-oriented architecture to leverage domain-driven design principles, allowing us to isolate different experiences. This flexibility enables our teams to take complete ownership over their services, selecting which technologies they want to use, and operating and releasing independently of other teams. For this strategy to be successful, however, teams are solely responsible for all aspects of their service including, deployments, monitoring, alerts and support. With the increased accountability comes more pressure, but also more innovation and a stronger sense of teamwork and involvement.
Traditionally, the product owner was tasked with understanding the customer, but in reality, anyone involved in building a product should be well versed in what motivates the customer and what the team, and the larger organization, is trying to accomplish. With our team structure, it’s expected that every member engages, designs and builds products based on customers’ expectations and experiences. We herald collaboration through participation, encouraging product leaders to involve engineers in the customer interview process and in return, expecting the tech team to take a more active role in the design and decision-making processes.
Bringing together teams that have largely worked in isolation and sometimes opposition can be a challenge. But rather than narrowly focusing on specific disciplines, cross-functional teams with a DevOps mindset learn to work with members across the entire organization to create products with the user in mind. By developing a culture of involvement that’s rooted in empathy, speaking each other’s language and producing knockout products, teams can find common ground and band together to build something great.
