As a product owner, you want to release, test and optimize revenue at will, without relying on long and untransparent IT processes. But how do you get there? In this series of blog posts, we explore how emerging technological best practices are helping product owners free themselves of many of today’s outdated IT bottlenecks. These best practices are making going to production a non-event; can provide real-time insight into the customer impact of releases in production; can ensure that fixing bugs is just an automated rollback away; and can allow you to set up small experiments in little time, instead of over several sprints’ time.

Release only to 5% of logged-in iPhone users in the Netherlands

In our last post, we looked at how safely testing in production on real customer traffic is key to gaining the kinds of fast feedback loops that predict how a new version or feature will impact your premium customers. But randomly sending small amounts of traffic to test a release is not the smart way of doing things. That’s why in this post, we’ll take a deeper dive into how you can build fine-grained customer segmentation into your release process (think: release only to 5% of logged-in iPhone users in the Netherlands). That not only makes releasing more KPI-driven but fully makes releasing a business decision that you control.

For the first time ever, you can decide when to “push the release button” and to which customers: what’s driving the change?

Not having to expose all your customers to a new version in one “big bang” by safely testing in production means that you can start asking yourself: which segment of my customer base do I want to expose to a new feature, when and under which specific conditions? But that’s not much help if you have to log change tickets into Jira and wait on someone in IT to push to production.

Thankfully, today’s release technologies allow for the separation of code deployments from feature releases. Whereas in the past, deploying and releasing were a single complex act carried out by engineering, now you as a product owner can release at will with the click of a button.

Best practice: build fine-grained customer segmentation into your process with release policies

So separating code deployments from feature releases is the first piece of the puzzle to creating a “separation of concerns” between IT and product owners. The second piece of the puzzle is having a way to apply business requirements to your releases and have them implemented automatically. That happens through release policies. Here’s how it works:

-          Release policies are rules to govern a release and are easy for those in non-technical roles to write

-          You write the release policy at the moment you create the business requirements for a new feature

-          The release policy is a set of instructions that tells a release orchestration technology how to segment customer traffic to meet your specified business requirements (for instance, segment based on source IP-address and geography, device type, customer type, log-in status)

-          When the release orchestration technology runs the release, the release policy reads metrics from monitoring and analytics tools, so it knows how your release is performing in production in terms of meeting your KPIs

-          The policy then tells the technology what to do next; whether to rollback based on your set of failure conditions or whether to scale up traffic to increasing customer segments based on your set of success criteria

-          The ability to carry out fine-grained segmentation makes releasing new features KPI-driven and release policies safely automate the process

-          That means you can build sets of policies and allow releases to run, even on the weekend!

But running releases on the weekend is just the beginning of the story…
This series is entitled the Product Owner’s Guide to Friday Releases and we mean it! In our next instalment, we’ll tell you how to create smart release strategies that automatically and continuously optimize experiments and revenue, even on the weekend. Or if you would like to read the whole story, download our whitepaper ‘Free from the Department of ‘No’: Release Features, Test and Optimize Revenue Without IT’.

Vamp is specifically designed to give product owners direct control over feature release, without having to rely on IT
If you would like to see how Vamp Cloud-Native Release Orchestration can help you release, test and optimize at will, explore or book a guided product tour.

*This post has been published on communities.