Don't stop at DevOps:
An integrated approach to product development

When it comes to delivering amazing products, we've found that the traditional DevOps mindset doesn't always result in the best product possible, in part due to the pressure placed on a perfect, initial delivery. And while the DevOps approach is a major step toward a more effective and collaborative process, there's still room to innovate when it comes to product development—starting with continuous delivery and cross-functional teams. Read more in the post below, which was originally published on CIOReview here.

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 rerelease 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.

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 400 a month. Granted, our manpower has increased with the growth of the organization and output, but our delivery pipeline has significantly improved as well.  

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.

To do this, 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 focus 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.

Learn more about how we build products together – and how we focus on the experience rather than the features – in this post by our Chief Experience Officer, Nate Walkingshaw.