The actual cost of new feature
When I picked up coding, technical software tasks immediately became less daunting. The unfortunate side-effect was that I started developing the unhealthy mentality that features were “cheaper” than they were in the past.
Features (even small ones) are not free.
Why is that?
Overview of Cost
We are incredibly biased towards short-term thinking. We get so caught up in the short-term pain that we lose sight of the long-term side effects.
When we contemplate new features, we tend to consider only the following costs:
(1) Time required to scope the feature
(2) Time required to design the feature
(3) Time required to develop the feature
(4) Time required to ship feature into production
When we have a competing backlog (and we almost always do), we consider an additional cost:
(5) Opportunity cost of not working on something else
That’s about it.
There are actually a few extra costs along the way.
Even in the short term, you should consider:
(6) Time required to train internal stakeholders about this new feature
(7) Time required to document new flows for internal stakeholders
(8) Time required to document new flows for customers
(9) Time required to market this new feature to new customers
(10) Time required to market this new feature to existing customers
If that list is hasn’t convinced you, here are the costs that accrue in the long term:
(11) A more complex workflow that your customers need to learn
(12) A more complex codebase for new engineers to learn
(13) A more complex codebase for engineers to maintain
(14) A more complex UX flow for new designers to learn
(15) A more complex UX flow for designers to maintain
(16) Slower future engineering due to more complex codebase
(17) Slower future design work due to more complex workflows
(18) It becomes harder for product marketing to describe what you do
(19) It becomes harder for support to support a more complex product
(20) and… coordination cost to support this
That new feature is not cheap
Why do we fall into this trap
In the best-case scenario, we scale our company whilst bearing all that long-term cost. The worst-case scenario is that we fall into the low-wage consulting trap.
If we recognize this, why does this still happen?
I don’t have a good answer.
My personal theory is that we don’t always have a clear “product vision”. BUT, I’ve seen companies that have a clear product vision, still fall into this trap.
If you can’t avoid it, manage it.
How do you “manage away” these feature requests?
The genesis behind these “new features” tend to be a certain workflow that hasn’t been previously supported and only 5–20% of your users really care about them.
How much of the end-to-end experience do you want to own?
You have to decide what percentage of the product experience you need to own internally.
Doing the sums - How much does a new feature cost?
The real cost of a software feature is going to vary wildly depending on the feature, the product, the team and so on … but I had a go at an estimate.
Example estimate of the total cost of adding a feature, over the lifetime of 3 versions
So, in this totally hypothetical (but based on software teams I’ve worked with), initial development is 27% of the total cost of the feature over 3 versions. And that’s without the inevitable feature redesign and its ensuing impact on testing, user documentation, internal training, marketing materials …
What do you think? Wildly over-estimated? Under-estimated? About right?
Maybe the numbers here are way off, but it does seem like it might be worth software companies having more of an idea of how the real cost of adding a new software feature adds up in the long term – and I very rarely come across anyone in software teams who does.
Author: Fu Fei Blog