Features aren’t free - the hidden costs of adding cool stuff

According to Silicon Valley Product Group founder Marty Cagan, at least half of all features in the average software roadmap are never going to work for customers.

The core premise of the SaaS revolution is that products are no longer static, offering evergreen roadmaps of updates in exchange for regular subscription payments. This has worked well for developers and customers, but as the above statistic demonstrates, the SaaS model by no means guarantees that product roadmaps are what customers actually want. The problems for users are well discussed at this point, but all those wasted features pose plenty of risks for developers as well.

Subscriptions have cut off a vital source of feedback for these firms. When Microsoft released Windows Vista, there was immediate feedback in the form of poor sales. With Windows 10 and 11 being released for free, it’s much harder for Microsoft to know how the products were received. Is every new update proving useful to their customer base? How many of the new Windows 11 features have proven popular and worth the development effort?

After all, as the title says, features aren’t free. There are a variety of costs that can be tracked, though even in these cases the lack of clear start and endpoints for SaaS can muddy the waters:

• Development Costs: Adding new features requires time, labor, and monetary investment. These costs aren't just associated with the initial development, but also include potential redesigns and bug fixes. The more complex the feature, the higher the cost.
• Maintenance Costs: Once a feature is live, it needs regular updates, bug fixes, and compatibility checks with other features. This ongoing maintenance can be a significant expense over time. In addition, technological advancements might necessitate upgrades or even a complete overhaul of the feature, adding to the cost.
• Training Costs: When new features are added, both internal teams (sales, support, etc.) and end users may need to be trained to use them effectively. This is especially true for complex or non-intuitive features.
• Support Costs: More features can lead to more customer support queries, as users might face challenges in understanding or using the new features. This increases the load on your customer support team and can require additional resources to handle effectively.

Eventually, if a product keeps releasing features that no one wants then users will simply abandon it. Many SaaS products make it hard to switch with lock-in effects, but this exacerbates the problem since there won’t be a clear separation point. Users churn seemingly at random and it won’t be clear if it was due to X feature, Y feature, or the lack of a Z feature. And all the while, companies have poured money into their roadmaps without really understanding how each feature contributes to customer satisfaction.

Most readers will have some idea of the above. What about the hidden costs that were promised? Hidden costs can end up being the biggest risks to the long-term success of a SaaS product as they are hard to notice at all, let alone track consistently:

• User Experience (UX) Costs: Every new feature adds a layer of complexity to the product, potentially making it more difficult for users to understand and use. If the features are not intuitively designed, this could lead to a poor user experience, resulting in churn, bad reviews, or a damaged reputation. Similarly, even if new features fit in well with the rest of the product, existing customers may feel exasperated at the lack of focus on the features they really use.

• Opportunity Costs: When you spend resources on developing one feature, you're inevitably taking those resources away from another potential feature or project. If the feature doesn't provide as much value to your customers as anticipated, or if it doesn't align with their needs, this could be a significant cost.

There isn’t a solution that will completely eliminate the risks of developing a SaaS product. Even if you have a great understanding of your customers, their pain points, and how to solve them, you can be completely blindsided. Consider Adobe, whose transition of Photoshop and the wider creative suite is one of the great success stories in SaaS: the arrival of image generation AIs might completely take away their business, even if every other feature they released is perfect.

But not every SaaS product is going to become AI (...yet), and the day-to-day development of features still has a lot of room for improvement. What’s needed in feature development is a method that can at least take care of the “known-unknown” problems as described above, delivering features that can consistently improve the product and removing those that fail to find an audience or give a quality experience.

That’s why we built and launched Bucket, to solve the problem at the heart of SaaS products that disconnects the power of incentives and leaves you at the mercy of your roadmap.

The STARS Framework

One of the first things we did was create a method for businesses to understand feature satisfaction, even without the Bucket application. The STARS framework is that method. STARS stands for Segment, Tried, Adopted, Retained, and Satisfied. Most SaaS companies have the concept of feature activation but metrics often neglect to go beyond that, nor do they incorporate qualitative feedback into their evaluations. 

With STARS, every feature can be visualized with a funnel showing exactly how many of your target users are not just using a feature, but using it long-term, and how much they appreciate it.

STARS in Bucket

STARS was designed to work independently of Bucket, but it is built into our software as well. Every feature you start tracking is measured via the STARS framework, as shown below:

The Segment for a feature is decided at release; not every feature is useful for every customer, so the first stage in getting useful results is to decide who a feature is actually for.

From that segment, we move through the funnel. To try a feature, you simply have to use it once - this is where a lot of metrics get to but fail to move beyond. If you can’t get users to try something, then either you have mistargeted the feature or have failed to communicate.

Users adopt a feature once they use it multiple times, instead of a one-off. Now we’re starting to see how successful a feature really is.

In the long term, are those adopters still using that feature? Then they have retained it. With Retained, there are actually two metrics we care about: not only do we want to know how many users converted in the long term, but we want to see who has churned out of the feature. How many users entered Retained, but then dropped back into Adopted? This figure can tell you if a new update has turned people off, or a competitor has started to eat into your feature’s strengths.

The three quantitative metrics above are great, but with enough time and effort (and lines of SQL) they’re not beyond current analytics solutions. The key to bringing the STARS framework, and Bucket, together, is the Satisfied step, which surveys users to get a qualitative rating of your feature from long-term users. 

Both Bucket and the STARS framework are ready and able to be added into your product development approach now. We’ve open-sourced the development of STARS and welcome any contributions at starsframework.org. If you’re looking to get started with Bucket, you can sign-up for a free trial right here.