In software development, people often talk about rollout plans. Here at Creditas, in the squad I work in, we created tools to facilitate the day-to-day of our crewmembers, and we very much believe in the phased rollout or feature rollout of a new feature or application.
But how does it work?
The easiest way to answer this question: it depends. It can be done in many ways. You can rollout a complete solution for a small number of users, or you can go about launching small modules every so often in order to collect feedback.
I’d start by focusing on the following:
One of our primary concerns are our users. At the end of the day, they’re the ones who transform our features into solutions. They’re also the ones who will need to adapt to the changes that the solution brings about. They need to understand the real reasons and benefits driving that solution, so that they won’t become intolerant or frustrated.
To do this, try to involve them during the development process, regardless of whether it’s in the discovery of the problem or tests of the possible solution. The less distance there is between the development team and the end user, the better.
In order to avoid becoming a victim of rolling out too much too quickly, it’s necessary to always keep a timeframe in mind. A solution that takes too long to produce benefits loses its value.
It’s also important to always remember that behind every solution is a large investment that, just like any other investment, needs to have returns.
When planning a rollout, remember a time period in which you would like to have (or the time you have available to have) a solution delivered in full, always making sure it is aligned with business goals and stakeholders. Once you’ve done this, you can break the rollout into chunks (phases) to ensure its success.
Example: If you planned to deliver the solution in full in one month for a group of 20 users, you can roll it out for a group of 5 users per week.
Often, the implementation of a new solution requires user training. If the rollout is phased, the training can also be phased. This way, lessons from the prior training are carried to the next training and, consequently, adherence to the solution is much quicker.
More with less
Testing a hypothesis becomes much more flexible, since, using a phased rollout, you can more quickly test, collect feedback, and validate hypotheses. This enables a valuable return with a smaller investment.
Any and every solution implementation, no matter how small it is, can impact a company’s productivity, numbers, and metrics until the learning curve stabilizes. The learning curve may be moderated if implementation is phased, making it possible to mitigate this decline in productivity.
Example: If we gradually rollout new solutions for small groups of users, while one group is “suffering” from a change, another might already be recovering from it and helping the new group, which stabilizes the productivity between them.
One of the great benefits of a phased rollout is the continuous improvement it provides.
Just like any other software rollout, there is always feedback and subsequent maintenance that needs to be done.
Always time and plan how your team will tackle this maintenance. The general idea is that it is resolved quickly so that the next phases of the rollout are smoother and less risky.
All this seems great, right? But how does it get applied in real life?
Here at Creditas, we recently created a new solution to help the day-to-day of our Customer Success (CS) team.
The CS team is responsible for servicing our clients who have questions and/or clients who want to know more about our loan modalities.
This support can be realized through several channels, such as chat, emails, and telephone.
Our solution aims to help and automate service via telephone through an integration between the telephone and our internal system. The client calls Creditas and after they pass through a IVR (Interactive Voice Response), they are put into a queue. Our representatives connect to this queue and start servicing clients.
In our solution, when a representative’s phone rings, a pop-up appears on the screen so that they can answer it.
The training took place and was rolled out for only 2 representatives, out of a team of 16, so we could evaluate the solution and collect feedback. When they started using the solution, the representatives noticed that a pop-up for the next call wouldn’t appear when they ended the previous one, making it impossible to answer it. Thus, this new call kept ringing until it went to the next available representative.
Consequently, our clients were in the queue longer, which compromised the productivity of our representatives and the experience of our clients.
We were able to quickly identify the problem and fix it, but imagine if we had launched for the whole team. We would have received feedback from 16 different representatives which we only needed to hear from 2 representatives. We would have compromised the productivity of the entire CS team, in addition to the experience of our customers. We would’ve had to rollback the solution until the problem was fixed, and the negative impact would have been much greater.
Through the phased rollout we were able to reduce negative impacts and risks. We gathered feedback and quickly acted upon them. All of this without having to rollback the solution, because we won’t have the same problem in the next phase of the rollout.
Not all rollouts should be phased — the purpose of this text is to provide you new tools so you can choose the best way to implement a new solution.
Below are some other tools that you could consider when implementing a solution:
I hope I’ve helped! If you enjoyed it, leave a comment! :)
Interested in working with us? We’re always looking for people passionate about technology to join our crew! You can check out our openings here.