We are living in the age of continuous delivery, and many developer teams have mastered the art of releasing new features quickly -- from a technical perspective, at least. They have their CI/CD pipelines down to a science and can move code from unit testing to production in a flash.
But not all teams excel at another crucial component of continuous delivery: introducing new functionality to the marketplace. It’s one thing to develop and release a new feature; it’s another to make it available to users in a way that makes it easy for them to find and adopt the new feature.
That’s why it’s high time for developers to make a plan for releasing add-ons that is as robust and reliable as the CI/CD pipelines they rely on to deliver those add-ons. Keep reading for tips on this process, with a focus on developer tools that designed for use by other developers or IT teams (as opposed to generic end-users whose needs and expectations regarding new functionality tend to be a bit different).
The challenges of add-ons
Adding new functionality to an application or platform is usually a good thing. However, regardless of how technically sophisticated or useful a new feature may be, there are several challenges related to the way the feature is released that can make it difficult for users to take advantage of it:
The feature may be hard for users to discover. Indeed, if you simply add a new feature to an existing developer tool without notifying users of the change, there is a chance they might miss it altogether -- which would mean the effort your team went to to design, create, and deploy new functionality was for naught.
If users do notice new features, they may not be sure what they are for or how to take advantage of them.
The constant addition of new features can overwhelm users by imposing an ever-steepening learning curve on them.
Sometimes, add-ons require effort on the part of users to set them up or integrate them into an existing application or workflow. The developers using your tool may not always welcome this requirement.
New functionality always poses some risk of degrading application performance. You can mitigate this risk with testing, but at the end of the day, the more an app does, the more resources it usually consumes, and the more slowly it probably performs.
Your new feature could come with an additional cost. Without the proper level of discoverability and understanding of the feature, developers may see the additional charge as a downside, or a reason to consider a competitor’s tool.
For all of these reasons, it’s important to think not only about how to build a new feature or new functionality for a developer tool, but also how to release it in a way that makes it easy for other developers to find, understand, and use.
Releasing new functionality in ways developers appreciate
How can teams who create developer tools solve this dilemma? One essential best practice is to consider releasing new feature in the form of an add-on or extension rather than baking it into your core application.
That’s not the best approach in all cases. And typically, when you are dealing with applications used by generic end-users, packaging new functionality in the form of an add-on or extension is often not the best strategy, because non-technical end-users don’t always understand how to install or manage add-ons easily.
But when you are adding new functionality to a developer tool whose users are technical, implementing the feature as an add-on offers several critical benefits:
It makes it easy for other developers to opt into using the new functionality if they want without requiring them to use it if they don’t want it (or don’t want to pay for it if it comes with a separate cost).
Because the functionality is offered in a standalone package, it is much more apparent to potential users what it does and why they want to install it. In this way, it’s harder for users to miss the new functionality simply because it is added to a part of their application where they don’t look.
Documentation can also be bundled with the add-on so that users can easily find any information they need for configuring or using the add-on.
The add-on can be distributed through multiple channels -- such as your website, as well as marketplace platforms where target users look for solutions -- to maximize visibility.
That last point is especially important. Today, developers are unlikely to start with a blind Google search when they’re looking for a tool to solve a new pain-point. Instead, they will first search within the ecosystem of tools they already use, looking to see if that ecosystem offers any other functionality that might solve their problem.
For that reason, having new functionality available as an add-on in a marketplace means that developers stand a better chance of finding the functionality than they would if it were baked into the core of an application. In that case, they’d only discover the new feature if they were to visit your website (which, again, is unlikely, because that’s not how developers shop for tools), review your release notes, or sift through your documentation -- tasks that require much more effort than simply browsing or searching a marketplace.
A parting note
I don’t mean to say, of course, that this is the only approach you should ever take to adding new functionality to an app. But it is a strategy worth considering -- especially in today’s world, where developer tool functionality moves so quickly that it’s easy for new features to go unnoticed if the team that releases them fails to make them easy to find.
By packaging new functionality into add-ons and promoting those add-ons through the portals where other developers already look for tools, you can maximize the ability of users to find and adopt new features that you add to your developer tool.