Long sprint cycles, putting in requests in Jira, negotiating release dates, not releasing on a Friday, Sunday, any day near a holiday…sound familiar? As a product owner, it’s your responsibility to push the product forward on customer experience and revenue, but the need to push forward on value comes with facing IT bottlenecks. In this series of blog posts, you’ll discover four emerging best practices that give you control over feature release, while shortening or by-passing a lot of today’s long and nontransparent IT processes.

We start by examining how to move from “big bang” launches to shorter iterations and gradual rollouts by testing-in-production. With the right process and autonomous technology in place, you can continue to ship changes to customers, even on the weekend!

Pre-production testing: no prediction of customer or revenue impact

When the release moment is the first time you expose code changes to real customers in production, releasing is risky, and everybody in the process gets understandably nervous.

To gain certainty that you’re releasing stable code to production, the intuitive response in many organizations is to mitigate risk by adding more testing before releasing. The testing lifecycle becomes a vicious circle. As testing complexity increases, release cycles drag, more changes are piled into each release, making each new version even bigger and riskier.

But the result isn’t better. Your customers still suffer from bugs in production. And the product and business suffer because testing and acceptance cycles take up most of your total time-to-market, eat up an ever-increasing share of costs and offer no prediction of the revenue impact of a new version.

Best practice: improve time-to-market and time-to-value by testing in production

Having a way of testing in production on real customer traffic allows you to significantly speed up cycle times, reduce testing costs and improve time-to-market. It also offers a fast feedback loop to how customers will respond to a new version. Here’s how it works:

  • Instead of trying to shadow customer behavior in pre-production, use technology that safely exposes your new version to a controlled subset of real customers in a live production environment.
  • Segment your release by specifying what part of your customer base you want to expose to a feature and under which conditions, such as location, device, cookie, IP address, basket value.
  • Release in a series of automated steps. The steps should include an automated rollback procedure if something goes wrong.
  • Make sure you have a way of tying the IT metrics of the release to the business outcomes you would like achieve, and that the result can be reported back to you in real-time. (At Vamp, we codify customer segmented rollouts, on-failure rollbacks and tie IT metrics to business outcomes in flexible release policies).
  • By cutting out the resource drain of extensive testing and acceptance cycles, releasing becomes iterative, cycle times speed up, and your organization can move to market faster.
  • Crucially, the results of this first stage of testing are the best predictors for the impact this new version will have on your premium customers.

But testing in production is just one part of the story…
Testing in production can help you improve time-to-market and time-to-value, but it’s just one best practice that can help you push the product forward. If you would like to learn more about how you can have real-time control over feature release, download our whitepaper ‘Free from the Department of ‘No’: Release Features, Test and Optimize Revenue Without IT’.

Vamp let's you safely ship changes to customers continuously, even on the weekend
Or if you would like to see how Vamp Cloud-Native Release Orchestration is specifically designed to give product owners direct control over feature release, without having to rely on IT, explore Vamp.io or book a guided product tour.