We’ve been working with a client recently on a WordPress Multisite platform which allows businesses within a specific industry to create their own website while hooking into tools offered by our client.
A lot of our conversations with this client revolve around new features. Can we add them, should we add them, how much will it cost, etc.
Today I wrote a fairly substantial email to them about why we need to be careful about adding new features to their platform. I thought that it might be useful as a resource to point people to in the future.
Subject: New features
Hi all,
We’ve had a few requests recently for some new features on the platform. It seems that every time that this happens we have the same conversation. I wanted to try to explain our position on this, and maybe help to create a framework for decisions going forward.
The answer to, “Can we add feature X?”, is nearly always, “Yes”. It’s rare that you’ll request something that we don’t have the technical capabilities to deliver.
The question should then become “Should we add feature X?”. In this case, I believe that the default answer should be “No”, unless there is a very strong business case for doing so.
Adding new features has many hidden costs and complexities. The upfront cost is easy to estimate and quantify, e.g. “it will take us X hours to build Y”. However, the ongoing, hidden costs are much harder to see. Unfortunately, it’s these that can end up being more expensive in the long run.
The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product, and yes, we can “just” code any logic someone dreams up. What might take two weeks right now adds a marginal cost to every engineering project we’ll take on in this product in the future. In fact, I’d argue that the initial time spent implementing a feature is one of the least interesting data points to consider when weighing the cost and benefit of a feature.
– http://firstround.com/
Some of the costs of adding a new feature include:
- Increase in setup time
- Support costs
- Infrastructure costs
- Documentation
- Increased maintenance costs
- The cost of complexity
(http://product.hubspot.com/
Mark and I have tried to keep the system as simple, efficient, and streamlined as possible. Hopefully, the points above help everyone to understand why we have been doing this. Ultimately, it’s in [client name]’s best interests for the whole team to think in this way.
My concern is that Mark and I will eventually ‘give in’ and stop pushing back on these requests so that we’re not seen as negative. I fear that the whole system could easily spiral out of control if we don’t all work together to protect its simplicity.
I’m not sure exactly what a framework for these decisions would look like, but 37 Signals wrote a famous book which included the following:
We’ll hear about “this little extra feature” or “this can’t be hard” or “wouldn’t it be easy to add this” or “it should take just a few seconds to put it in” or “if you added this I’d pay twice as much” and so on.
…your first response should be a no.
…the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember.
– https://basecamp.com/gettingreal/05.7-forget-feature-requests
When deciding whether or not to add a new feature we need to consider:
- What is the potential financial upside to this?
- What is the initial development cost?
- What are the potential ongoing/hidden costs?
- Increase in setup time
- Support costs
- Infrastructure costs
- Documentation
- Increased maintenance costs
- Does the potential financial upside outweigh the costs?
- Is it worth the added future complexity?
If the last two answers are ‘yes’ then we should add the feature!
Hopefully, that’s useful. Let me know if you have any further thoughts on this.