How to Implement a New Feature?
Feature Rollout and Release Strategy in Software Development
Have you ever started to answer a question is an interview and you can just tell you are missing something? Your answer might not be wrong but you get the feeling its not exactly correct either… Its ok, it happens. As a junior software developer, new to the industry theres bound to be aspect of the industry I’m not familair with yet. But, when I come across a new topic I make sure to read up on it so I’m ready for the question next time.
I was asked at an interview: “What steps would you take to implement a new feature? How would you validate engagement and success?” I answered the question talking about testing and the developement lifecycle. However, I could tell I was missing some key knowledge. What I should have talked about instead is a feature rollout process or release strategy.
So, I decided to learn more about the steps in the feature implementation process in software develeopment.
Feature Implementation Process
Ok, let's say you know the new feature you want to add and you've built it out. It's now ready to be deployed. But then what? You can’t walk away after pushing to production. How do you know it worked? Or that it’s really solved a problem, or that users will engage with it? How will you measure success?
To answer these questions, companies will usually have a release strategy. This outlines the steps of a feature rollout and how that will be incorporated into the development cycle. One common strategy in web development is using feature flags. A feature is “flagged” and therefore instead of being just pushed into production with all other changes, it can be launched, controlled, and monitored. Basically, developers can choose which features to show and not show.
Normally, companies have a phased release strategy. By not releasing the new feature to all users, they can test the effects of the change on a subset of users and then if all goes well, release to more over time.
Here are steps that may be involved in a feature implementation:
Step 1- Feature Design
This is where you would come up with the user story for this feature. Design what the feature will do, who will use it, and how. This part can involve some user feedback as well. What are the priorities of the user? What features do they want? However, you can't rely solely on user feedback since users don't always know what they want.
Step 2- Build and Test
This is the development phase. Using a feature flag, the feature’s progression through multiple development environments can be tracked. Once the feature is completed, a software testing and QA phase are involved here.
Step 3- Implement Phased Release
Now it's time to start releasing the feature and conduct essentially user tests. After all, putting the new feature in front of users is the best way to validate it and gather feedback. There are many ways to do this but most companies here will do a limited rollout or phased release. This allows for controlling the size and types of users. The feature is only accessible to a subset of users and this is determined on factors such as usage time, account type, or geography. It could be released to a certain percentage or target individual groups of users. It is a good idea to keep the sample sizes small to start to allow for quick feedback and development.
Types of phased releases include: dogfooding (employees only), beta testing, invite-only rollout, or A/B testing.
Step 4- Continue Rollout or Decide Against Implementation
If all goes well with the first phase of users, the feature can begin to be released to more and more users. It could go from 5% to 50% to 90% users over time. However, if the metrics show the feature is not doing so great it might be time to redesign, shelf the feature for a later time, or throw it away altogether.
Stage 5- Full Rollout
If the feedback to this point is positive, it is time for a full rollout of the new feature. The feature can now be considered fully rolled out and all users have access. Sometimes, companies leave 1–5% of users without the feature even at the final stage to monitor long-term impacts and aid in troubleshooting. This is normally called the holdback group.
Additionally, not all features are released in a phased manner. Some features skip the above steps when it is a major product launch or the feature cannot bring value without consistent experience for all users (eg. some social media features).
Conclusion
By using a release strategy for feature rollouts, companies can ensure quality and engagement in their new features. With a combination of quantitive data and user feedback, the product can continue to be improved upon. This can allow for further improvements and iterations on not only the single feature but the entire software as a whole. The life of a new feature does not end at release. This is when the validation process starts.