The True Cost of a Feature
It's much more than the development effort to deliver the first version.
👋 Hey, it’s András here! I write about all things product management: concepts, frameworks, career guidance, and hot takes to help you build better products. Subscribe for each article to be delivered when it’s out!
When building new product functionalities or improving existing solutions, often an effort estimate is needed to figure out what’s worth doing. That’s not surprising—no company wants to invest heavily into ideas that might not bring new customers or improve retention.
But how do you figure out the true cost of a feature?
Before I present my take, let me ask you:
How do you calculate the total effort required for a feature today? Does your team estimate it in days, weeks, story points, or in some other units? Do you consider anything else beyond that?
First part: development effort
Most people think about the development time as the cost of a feature. The amount of effort it takes to develop it from start to finish, the number of days/weeks/stories. Maybe including research and design activities.
And this is already good, as you want to ensure that you’re not comparing pears to apples when discussing competing options. But it’s not the full picture. And especially when considering building something big, you should consider the next parts too.
Second part: maintenance, support, bugs
The feature is shipped, customers have started using it, and maybe they even like it! What’s next? Are you focusing on building the next best thing? Or are you stopping for a moment to monitor adoption and other signals that might reveal how the solution is performing?
In any case, now you’ve extended your product with some additional functionality and might have introduced some extra complexity. As the feature is out in the wild, questions, bug tickets, alerts, and other support needs will start to arrive. You realize that some time needs to be spent on these activities, instead of building other great things.
If your team has done a great job, this time is minimal. They’ve designed a feature that’s straightforward to use, left close to no room for bugs, covered most edge cases, and provided enough support materials for both internal and external stakeholders.
If that’s not the case, you’ll know soon enough. And it won’t just affect the team who developed the feature but everyone else who needs to work with it (customer-facing stakeholders, support, marketing…). Plus, the time you’ve saved on building the functionality will be spent on fixing the holes.
(To be clear, I’m not promoting building features to perfection, but there is a reasonable balance between speed and quality. And different organizations might have different standards on these.)
Third part: enhancing, replacing, or killing it
Every solution has a shelf life, at least the original version that you’ve built. Depending on its impact and value, that might mean different outcomes for the future:
enhancing the functionality,
replacing it with something different,
or killing it.
Improvements are made to a feature if it has already proven itself, or if you’ve identified something that would unlock its true potential. For the first, you need data-backed evidence. For the second, at least a lot of hope and some positive signals—you don’t want to captain a sinking ship.
Alternatively, it’s worth investing in a replacement if the team has identified a better opportunity to solve the original problem. Or if they’ve found synergies with a similar solution to merge efforts. As this also requires development time on top of the original ask, the customer problem needs to have established value at this point.
And last, it’s hard to kill a feature (as there is usually a healthy resistance against it), but sometimes it’s necessary. Removing code, handling data, and informing customers also takes time. But it’s still better to swallow sunk costs than to continue investing unjustified.
So what’s the true cost of a feature?
The true cost of a feature is not just the early development effort but everything that will arise during the lifecycle of the functionality. I’m not advocating for changing how you estimate the effort, but I recommend thinking beyond the initial investment.