“How many elephants can you get into a car?”

The answer is four: two in the front and two in the back.

Well, everyone knows that. But nobody knows what happens next – now that the elephants are sitting in the car, what would happen when you start the engine and drive?

The answer to the above question is very relevant to product development and product management. Why? It will be clear in a moment.

The answer to the second part of the riddle is: “very slowly”. The car will move very very slowly. Quite often this is also the case with a small and lean product, after a few years of adding more and more features, attempting to answer all customers’ needs. These features are much like the elephants in the car. They slow the product and it becomes a bloatware.

“Very very slowly” also well describes other things that might happen. For example – the time it takes to release a new product version. It is likely that every change affects many unexpected areas so development is a slow and error prone process. But this is not the only thing that would happen. Think, for example, of the installation process (gee we really messed up this one. Need to do it very carefully) or the overall response time (ho my, it is so slow), or the number of key strokes required to complete an operation (wow, it takes so much time).

I had the opportunity to work on such a product. It was an excellent, well known product with thousands of customers, where we reached a point where we simply said that no matter how small and insignificant the change request was, it was not going to take less than two months to implement it. We had to spend a lot of time stabilizing the system after each and every change so eventually, the important stuff, those features that bring real added value to our customers, remained out of the version scope due to lack of resources.

On the other hand, let’s face it – it is what it is. Everyone expects products to grow from one version to the other. Customers always want more. The competitors are constantly closing the gap so you must keep improving. Anyway, that’s exactly the reason why we are here. Product managers always look at the market, listening to what’s going on, checking with customers, identifying new needs and adding them to the product backlog. So what can you do?

One option would be to retire (I mean to retire features, not developers…). But this is not a popular alternative. That’s because no matter how hard it was to develop a feature, getting rid of it is always by far harder. There will always be a huge account or critical deal that depends on it. Yet, please take a look at the picture above. Wouldn’t you agree that the option of not doing anything might be… hmmmm… a bit more painful?

So here are the five steps for keeping your product thin and in shape, even after the first ten versions:

• Choose the right candidates – it’s not a good idea to drop the main functionality of the product. The right features to choose are those that are:
  • Expensive in terms of maintenance (bugs, complicated, etc)
  • Used by only a small percentage of the customers.
  • Not serving the product’s strategy.
  • Without any real added value.
  • Remember that small things cost a lot. For example, sometimes a small change such as reducing the support matrix (de-scoping operating systems, web servers, application servers, etc.) makes a big difference, with little effect on the users.
• Find an alternative – The approach of “dear customer, what you had in the previous version… doesn’t exist anymore” might not be welcome. Be prepared and offer alternatives to the feature you intend to retired. You may consider offering professional services to apply the necessary changes for strategic accounts.
• Communicate – communicate with your user base as soon as you can and be honest. Share the reasons behind the change, the pros and cons and what are the alternatives.
• Share – tell the users why you chose to remove functionality. Show the alternatives and explain this change will allow them to get new stuff which is much more important for them.
• Put it in a bottle – “If you can’t kill it, make it go away.” You can’t get rid of a problematic feature? Hide it deep in the product so that only a few experts could find it, and even if they do, make sure to limit its function. If you can’t retire it in this version, it may be easier in the next one.

In the world of SaaS and the cloud, things change. Developing a service is different than developing a product. With a service, you may find it easier to remove functionality. The items related to “sharing” and “communicating” are not relevant or may be addressed in a blog.

To conclude, here are two additional little suggestions to make things easier:

• No matter whether it is a product or a service – it is always beneficial to add a component which measures what is being used. Just remember to verify the data being collected contains only statistical info with no personal data in it. After clearing all potential legal obstacles, you will have a gold mine in your hands. This information will  turn the process of retiring features into part of your development culture.
• Think twice when building the product’s backlog. Would these new items serve the product’s vision? If the answer is no, maybe they should not be there.

Good luck!
Ilan