6 Ways Roadmaps Help You Be Better at Your Job (and Your Career)
As product managers, creating and maintaining product roadmaps are regular duties. Product roadmaps enable us to do our entire jobs easier. It only requires...
When you’re continually shipping code, how do you plan, build, and communicate your roadmap? In this post, we’ll outline the basics of continuous delivery, what it means to you as a product manager, and how to adapt your roadmapping process to best work in a continuous delivery environment.
When products adopt Continuous Delivery or CD, they begin pushing updates out to end-users as quickly as they’re available. Previously they may have waited for the end of a sprint or a scheduled release, but with continuous delivery, new code can be pushed to production as soon as it is ready.
To accommodate this nonstop release cycle that supports deploying new code multiple times per day, a number of processes must be automated. As soon as code is committed, it sets off a chain reaction that eventually (but quickly) results in the production environment being updated.
The philosophy behind Continuous Delivery is based on two key tenets: shorter feedback loops and immediate customer experience improvement.
The more frequently code is released, the more opportunities product teams have to gather feedback. By creating a constant feedback loop, learnings can be gathered much faster, which then drives additional innovation or refinement.
“Frequent releases let the application development teams obtain user feedback more quickly. This lets them work on only the useful features. If they find a feature isn’t useful, they spend no further effort on it,” says Lianping Chen of Paddy Power. “This helps them build the right product. Previously, teams might have worked on features that weren’t useful but didn’t discover that until after the next big release. By that time, they had already spent months of effort on those features.”
Of course, Continuous Delivery requires a major shift in mindset and comes with its fair share of risks. Human gatekeepers don’t really exist in this setting and the constant flow of changes into the wild can be a challenge. However, Continuous Delivery creates a read-and-react product development organization that can deliver value far faster and more frequently than typical Agile or waterfall release schedules.
Before a product manager can consider what adjustments they must make if their organization adopts Continuous Delivery, they must first decide whether they even want to have their product exist in that environment. With Continuous Delivery, users will see a constant array of changes to the product, some minor or unnoticeable, others significant and impactful. Ensuring you have a customer base that will tolerate this rate of change is important since many enterprise customers prize stability and consistency.
Assuming everyone is game for Continuous Delivery, the next step is determining how liberal the organization will be when it comes to activating that continuously delivered code (since most user-facing changes can include a toggle that turns them on or off). There’s a choice to be made about what automatically shows up for users and what requires a coordinated signoff before it gets “turned on” even though the code is already deployed.
The other aspect to consider is how to collect, evaluate, and react to the continuous feedback loop created by this method. A combination of looking at usage and analytics, surveying users, and monitoring incoming customer feedback must be utilized to fully take advantage of the continual stream of changes reaching the user base, otherwise, the company misses out on seeing exactly which tweaks are moving the needle.
Continuous Integration—Although often used interchangeably with Continuous Delivery, continuous integration is specifically referring to automated verification of code before it is merged into the main codebase. This can be very important in a Continuous Delivery environment since there is constantly new code being pushed and tested, but continuous integration can really be used in any development setting (and is quite frequently).
Incremental vs. Iterative Development—In an incremental setting, developers write some code, check it in, then write some more code, check that in, etc., until a chunk of functionality is complete and ready to be tested and only after passing those tests is it deployed. In an iterative setting, the initial chunk of code contains enough functionality that it’s useful and then it gets tested and deployed. Based on the results of the deployment, the code is continually tweaked and improved upon, with each iteration tested and released to users as it’s ready.
Version control, trunks & branches—Many software development organizations let each developer create their own branch of the code base (think private sandbox) to work on their specific projects. When they’re done, the branch gets merged back into the trunk, and then the trunk is tested before it ships. This is a “safe” way to develop software because it means one developer can’t screw things up for everyone else by working directly on the trunk, however it can also be problematic because those branches may not play well together when they get merged back in. Additionally, if one developer doesn’t finish their work before the specific release is ready to be merged and tested, they’re now working on an orphaned branch and may have difficulties when it’s time for them to merge in later. It also means that everyone must wait until the entire version is ready before it goes into testing and is eventually released to the public, delaying the delivery of value to the user.
When you’re operating in a Continuous Delivery environment, roadmapping can be a little bit trickier. Rather than being saved up for larger releases, functionalities trickle out steadily. However, if major changes are controlled with kill switches and activation settings, you can still time how and when things are actually available to your users, even limiting their activation to specific subsets of users.
Given this chaotic setting, it’s hard to pin down specific dates and timing for particular features and enhancements. But a product roadmap remains a valuable and accurate tool if structured and managed appropriately.
The devil is in the details, and that’s true for product roadmaps as well. The more granular and specific your roadmap gets, the more likely it is to be inaccurate. So steer clear of specific dates and deliverables and focus on the high-level strategic aspects of the roadmap. Instead of calling out every minor enhancement and release, stick to major features and areas of focus, showing when they’ll reach the market in broad time windows.
When your engineering team is pushing code multiple times per day and your team is evaluating the impacts of all those minor changes, things are bound to shift. With so many moving pieces, specific commitments should be avoided whenever possible. This extends to OKRs, where the criteria for success should be the overall business impact and not “shipping” a new feature at a certain time.
Given the constant updates to the product and on-the-fly adjustments made based on the feedback loop Continuous Delivery creates, saving up roadmap communication for a big presentation every month or so isn’t practical. While you can still have those in-person sessions to talk strategy, it’s important to keep a steady flow of updates coming to stakeholders so they know what’s been released.
Consider your roadmap a living document that others can access on-demand. Supplement it with daily or weekly release notes covering what changes have been made in the interim. Then, save the big announcements for when major features are finally code complete and activated in production.
Every product team strives to react to customer feedback and deliver a steady stream of value, and Continuous Delivery can make that dream a reality.
“Anytime something sits in a queue (aka waiting for a release), there’s waste between the cost of production and not yet realizing value. You don’t know if something is valuable until you get feedback from your users,” says Adam Zolyak of CA. “Each release is an opportunity to validate and learn – a feedback cycle. And the more feedback cycles, the more opportunities to learn and ultimately achieve your goals.”
But along with the responsiveness and speed comes a new set of challenges for product managers to make sense of the tsunami of feedback coming in from each new tweak. However, once faith in the automated testing process has been established and confidence that kill switches can be used to shut things down or roll things back when they’re not working, product managers can thrive in an environment where they can test, gather feedback, and react in hours or days instead of weeks or months.