Six Practices for Product Managers
DevOps changes the traditional rules of software development. It brings frequent, if not continuous deployment and delivery into a world that was typically releasing its products once every couple of months, once a year, or even less frequently than that. These changes do not only affect customers, developers, and operations. They also have a significant impact on many activities of product managers. In particular, it changes release planning a lot.
What does DevOps mean to release planning? I’ve been thinking about this for several years now and talked with product managers about their DevOps release planning practices. I have also collected relevant published experience reports. In this article I summarize the key learnings from some of these discussions and observations.
The described release planning practices represent a blend from about six leading software vendors and web services providers. Their practices differ in detail, sometimes from product to product within the same company.
However, I identified interesting similarities, from which I have derived six release planning practices in a DevOps environment:
- Plan release themes with flexible content
- Apply two layers of planning
- Use pilot releases
- Intensify customer involvement
- Monitor feature usage
- Speed up on-premise product deployments
Before we dive into these practices, let’s briefly recap what’s so new and special to DevOps.
DevOps Challenges for Release Planning
From a product manager’s perspective, the main challenges of DevOps are:
- Continuous integration and delivery practices (CI/CD)
- Various elements of the agile development practices that usually come with DevOps, such as highly iterative development cycles, the role of the product owner, and—ideally—direct interaction between development teams and customers
Of course, when an organization already has used agile methods prior to moving to DevOps, Agile does not appear all that new. However, better don’t be surprised when DevOps further transforms your agile work practices.
Now, let’s have a closer look at the six release planning practices I identified above.
1. Plan Release Themes with Flexible Content
Prior to DevOps and Agile, release planning has defined the heartbeat of development: Fixed release dates with fixed content, specified upfront on a quite detailed level and involving considerable preparation work. In DevOps and Agile this is different: Development heartbeat is set by agile sprints (Scrum-style Agile) or by small-grained work item completion, resulting in a more continuous flow than a rhythm (Lean/Kanban-style Agile). Extensive preparation makes way for fast and flexible adjustments.
DevOps release planning determines themes and target dates, and hands over detailed design of features and release content to agile teams, their product owners, and their customer interaction. As a consequence, roadmaps both for internal and external audiences, are theme-oriented. Even for internal audiences, they provide less detailed information than before. This is a common characteristic I found throughout all interviews and observed cases.
2. Apply Two Layers of Planning
In DevOps, the flexible and open release planning is often structured into two layers of granularity along two different time horizons: Mid-term and short-term. One interviewed product manager reported about four quarterly releases (short-term planning) per year with one year look ahead (mid-term). This organization updated and extended the mid-term plan in the context of their quarterly short-term planning activities.
An important purpose of the mid-term release themes is to focus and coordinate development activities towards the main lines of improved customer value. For this reason, product managers translate the few overall themes into a collection of often quarterly features. Within each quarterly time frame, product managers leave the decision as of what feature to deliver when to the development teams. This is particularly relevant when there are several releases within a quarter, for instance monthly releases.
3. Use Pilot Releases
DevOps makes market testing with real customers cheap. When you can ship a new feature to a few selected pilot users, then why not try new ideas fast and under real-life conditions?
One company I talked with tests new features in special pilot releases that exist in parallel to the main product release. They deliver these new features to selected customers or users only, who use the features in real-life business operations. These can be company-internal users, external pilot customers, or even a random subset of regular users within A/B testing scenarios.
Along with the first feedback from the pilot users, the company improves and extends the features. If users and vendor are satisfied with the new features, they will be deployed with the main product to the entire customer base. Technically, this is mostly a no-brainer, because the pilot release is already part of the overall current product release.
In case new feature acceptance does not meet product management’s expectations, it will be switched off and not delivered to customers any more. This particular vendor took the in/out decision of a new feature and its pilot release after a maximum of three months: With DevOps you can act fast. So you should do it fast.
4. Intensify Customer Involvement
DevOps brings shorter feedback cycles between customers and developers, and generally more flexible and reactive systems evolution. Vendors can use this to maximize customer value. Intensive customer involvement is the starting point for making this happen.
A product manager I interviewed reported that they ask selected customers or internal users to become what they call “design partners”. They involve these design partners into the feature creation process, already at a very early design stage. For instance, the vendor shows design partners first product mockups or prototypes.
At this company, design partners receive privileged access to preview upcoming features: Two weeks prior to each public SaaS release internal customers get early access to the product. These customers will then be interviewed to gather feedback
5. Monitor Feature Usage
Software enables its vendors to collect data on feature usage. Some types of software, such as web applications, mobile apps, and company-internal applications, enable real-time access to usage data and even offer real-time analytics. Vendors can act rapidly on this data and their analysis results.
Several of my interview partners have emphasized the importance of monitoring feature usage. Effective monitoring is also a prerequisite for the above practices of pilot releases and intensive customer involvement.
6. Speed up On-Premise Product Deployments
Companies that offer the same product both as Cloud/SaaS service and on-premise installation variant face the challenge of coordinating both release cycles. Specifically, on-premise customers may want similarly fast access to newest features already available in the Cloud. This puts specific requirements on release planning.
Technically, it is often not feasible to just increase the delivery frequency of on-premise products. This is mainly due to the high cost of traditional release and delivery models. However, there are first examples of vendors increasing the frequency of on-premise delivery and at the same time making installation easier for customers.
An example is the requirements management tool Jama. Traditionally, they delivered their on-premise releases every six months. Since early 2016, they re-architected their traditional installation procedures to deliver the software on a monthly basis, using Docker containers and the Replicated software distribution platform. For technical details see Jama blog “Jama On-Premises Update Technical Overview“. I also discussed this approach in a previous post “Speed up On-Premises Product Delivery“.
The release planning practices discussed so far deal with the interface between product management and development organization. However, there are also various interactions and dependencies between product management and IT operations. For instance, support needs to learn early about new features.
Unlike the product management / development interaction, the interfaces between product management and operations are still often in their infancy. Product managers should aim at involving IT operations early during planning and development of new features. This is particularly important to make sure product management benefits from operations-side monitoring and analytics. Monitoring and analytics data can be important sources of customer insight, helping product managers to increase customer value of the product.
I’m Gerald Heller, and I’m a partner at pd7.group. We provide training and consulting in the area of software product management. Release planning is one of the focus topics where we help product managers to further advance their current practices. Contact me, if you want to explore available techniques.