Avoid Ginger Growth in your Products

Does your product look like this?

Usually, GROWTH is a good thing. However, there is a very common problem of unbridled feature growth in both B2B and B2C products.

Feature ideas typically come from everywhere but the problems most dear to the HiPPO, and those of the loudest customers get much more attention than other real problems. So over a period of time, the products undergo a skewed growth in size, complexity, and utility. At Artoo, we used to call it the GINGER GROWTH. For those who did not get the connection - Ginger root is a leguminous stalky root used as a spice. It grows very erratically - from just about everywhere, that's not what you want to happen to your products. And for some of you familiar with Bollywood would know - "Adrak ho gaya hai ye aadmi..." If you don't get it, just ignore it.  

We realized there are a small but a significant number of features that were unused, under-used, un-released, not-so-useful, not-used-as-intended and even unusable. In most cases, making products leaner is a more painful exercise. It is hard to say NO to feature requests, and even harder to say it when there is a client using it already. Killing a feature is harder than deciding to build the new ones.

Why not?

Wasteful: One should avoid Ginger growth to save efforts now and more so in the long run. Ginger growth is an indication of lack of focus, which means you are building features users may not care about. That's wastage on steroids.

Onboarding/Training the users take longer - New Users find it complex, Trainers spend more time and overall it directly increases the costs.

In B2C products it may cause an early churn in acquired users, In B2B it may lead to slower adoption, user dissatisfaction, falling NPS/C-Sat scores.

Re-engagement/Monetisation is difficult as the users may not be able to leverage the full potential of the product.

Your product is more likely to get disrupted by newer simpler products. Very likely that's how you acquired your clients - by presenting a simpler solution to their existing problems.

Examples of Ginger growth

Featuritis or Ginger Growth has plagued every org and every product I have known. However, here are some examples from the consumer apps so that everyone can relate to it better:

• Facebook - How many features do you see on a facebook page? I stopped counting after 50 visually apparent ones on the homepage, did not count recommendation algorithms. How many do you use? I counted 7 that I frequent. 
• Evernote - A designer friend once claimed that only 15% of the Evernote app is used by any user, but it's not the same for every user. That means that the 15% most used features are spread across the entire feature-set. It sounded interesting and believable. However, I could not find any evidence to support the claim so I did a bit of a survey myself. It was hard to gather clear quantifiable insights, but it was very clear that most people focus on their favorite set (20%-50%) of the product, and they ignore the clutter. Now Evernote has been able to survive and thrive in spite of its ginger growth, but it's not a nice model to follow. 
• There are more examples of Linkedin, ShareIT, Hike Messenger and Truecaller which are getting obese with more features regularly being added to the clutter. Fortunately, they have large smart teams to find these issues and they also keep killing them regularly.  

Identifying Ginger Growth

Here are a few simple but strong signs that indicate Ginger growth.

• Engagement spread thin: A few features are widely used, but a lot of features are mildly used. It's hard to find a clear set of features that no one is using at all. 
• Discoverability is difficult: It's getting hard to highlight what's new in your product for the users to start using it, they mostly remain undiscovered.  
• Who worked on this?: The question comes up every time they want to fix a new issue or enhance a module. None of the teams is confident that they know the entire product well. Usually, the PMs, QA, Support and some sales guys must have a pretty good command over the product/module/feature that they own. 
• Product Documentation is in the head and in the code: More than 50% of the product documentation is very stale and almost useless. This is not a necessary condition, but is a strong sign and is unfortunately very common.  
• Increase in a number of support calls from new users: Typically when the feature set is a large the training/onboarding is not enough. End-user ends up seeking support for multiple small things.  
• Onboarding/Training is taking longer: It takes more than the onboarding to make user find their Aha moment. Training sessions might have become longer and less effective. 

 Reasons for Ginger growth 

• No Compass - Usually, everyone driving a product has a plan. But, if it's not clearly defined, and well-drafted as a data-driven roadmap and is clearly evangelized with the team, it simply cannot be executed by a team. It might work for smaller teams, but not for teams more than 10+ members in it. Imagine navigating through a jungle. You either need a common compass that clearly shows them one true-north or a road-map that everyone can clearly see and follow. Usually, you need both. Creating the right product is quite like navigating in the jungle. If the team doesn't clearly see a road, they will end up beating their own paths.  
• HiPPO - (usually the CEO/CTO/CPO) - In the book Throwing the elephant, the Boss is frequently compared with the elephants. E.g. However young, thin and naive it is, an elephant is at least 10 times heavier than you. The Boss is not an elephant but has super-powers that can make her weight-in like that. Usually, the HiPPO will exercise their powers to keep changing the plan because "they can". The reasons may be lack of discipline, lack of focus or lack of understanding of how it impacts.  
• A few loud stakeholders - Sometimes some of the internal or external stakeholders (clients and sales) are louder, more nagging than others. And in the absence of a transparent, data-driven, mutually agreeable roadmap, the team can give in to their demands. 
• Chasing vanity metrics: This is a distraction that anyone might have. Product and Growth guys get it often. If you are going to build features to hit numbers that your product does not need in long-term, you will accumulate a lot of deadwood very soon. .   

How to avoid Ginger Growth / Featuritis

Saying NO to features is hard - whether it is your idea or theirs. It's almost never a possibility for product guys have "Saying No" as a tool. But, there is a lot that you can do to check whether you are ready to commit for a feature or not. One way I do it is to keep a checklist right as a part of the PRD that I or anyone in my team creates. This document is referred by everyone from sales to engineering and sometimes even clients. See my PRD template here.

This enforces asking the right set of questions right at the beginning of the ideation process.

Don't take "solutions" from your customers

This is particularly evident for B2B software. You create a roadmap and in the next customer visit it seems to be useless. You re-do it, and another client visit brings you back to square one. Remember that we are hardwired to think in terms of solutions - instead of elaborating or articulating our problems better. So when you meet clients of your customer-facing stakeholders don't take solutions. Ask a lot of whys and understand the problems and design your own solution.   

Find the right metrics to chase 

Does it align with the vision? This is the most cliched question everyone would suggest asking, and we usually have no way to clearly check for alignment. The solution is to find the right metrics that help you achieve the vision. The basic metrics are related to Acquisition, Conversion, Monetisation, and Engagement. However, we need to choose a metric that marries business with user-experience. For an e-commerce site, it could be the number of repeat transactions, for a utility product it could be the turn-around-time. Basically one should focus on optimizing for one of the following - attention, transactions, or productivity. Decide on a north-star and the levers that affect it - chase them.

Ask: is it core to what we do?

You often build features to please that one client, close that one sale and end up getting some half-assed features. This is because we often view the product as a monolith. We should split the product into multiple layers for simplification. This helps in logical separation, better technical architecture and keeping things robust. The sooner you start thinking of product in this way, the better and easier it can be.

Simplify your Products into different layers

With this approach, it gets easy to make decisions when a client/stakeholder makes a new request. You can decide what's core and what not and treat it separately.

Ask: will it still matter after 5 years?

If it will, can you afford to not do it well and carry the technical debts for that long? If it wouldn't matter in the long run, how much time do you want to spend on such a thing right now? This helps in seeing things from both a short-term and a long-term perspective. You can treat the short-term things differently and have a phase-out plan for them even when they are not live. This gives you a strong focus. And this also keeps the product clear of featuritis.

Execute your Roadmap!

Enough has been said about creating useful roadmaps. Executing the roadmaps needs very strong intent from the owner and other stakeholders who can act as potential saboteurs of the plan. Product guys need to train-up and train-down their hierarchy about the importance of planning and sticking to the plan. However, it makes sense to expect changes and plan for them. I'd always keep a 20% flexibility.

MVP Everything

A feature idea/request usually stems from a pain point. You may not want the most elegant solution for it immediately. As a product guy, I would always ask how can this pain be solved without building a new feature? Sometimes the workaround works wonders and gives me enough breathing room to decide what needs to be built and how impactful would it really be. And also enough data points for the stakeholders to see.





If you have reached this far, you should totally leave a comment for Ujjwal Trivedi's post.