The real cost of feature sprawl

I was going through this interesting post from Ashish Kashyap on how productivity reduces when we have more people in a team. One of the reasons that Ashish hints for the drop is the maturity of the team to handle more work. For most of the leadership phase of my career, the toughest battle I have fought is to prevent an increase in the headcount of the team I manage. I agree with Ashish that structuring a team better can help minimize the dip in productivity; but even well structured teams struggle when all the resource constraints are off and that is what we are doing to talk about.

Scarcity forces us to prioritize; to separate what is important for the customer from features that you add to a sprint because a PM needs to generate work. You take away scarcity; and what you end up with is feature sprawl; a huge number of features on a product of which 90% are never used or used by an occasional customer.

Feature sprawl is irreversible in most cases and it takes its toll in multiple ways.

The most obvious challenge with feature sprawl is it leads to a messy architecture; If you have a large number of features; some of them inconsistent with each other and others that overlap with each other, then the underlying technical system is bound to get more complex. Consider a consumer platform that supports coupons, wallets, coins, loyalty points, gift cards, pricing discounts and dynamic personalized pricing and different product managers responsible for growing each of them. What you will end up with is a tangled payment and reconciliation stack; and that is even if all the individual systems are set up as separate micro services; all of these nice and modular services will eventually impact the way payment is collected, refunds are processed and reconciliation happens.

Different teams handle it in different ways; I had setup a system where every PM needed to define a target metric for every feature and the engineering team had to come up with an impacted metric for implementing the feature. For example, if we introduce a new discounting option like coins, the target metric would be "increase conversion by 1%" and the impacted metric would be "increase in response time for cart and payments by 30 milliseconds". This, coupled with the sizing of the feature, helps quantify the negative impact of adding a feature to the platform and often leads to better understanding of the ROI of the feature. This, frankly, requires a lot of effort and driving compliance was a challenge.

During the merger of Makemytrip-Goibibo, I discovered the GoIbibo (GI) approach. GI engineers could just say "won't build it" for features that would add a lot of complexity to their architecture. The empowerment that GI engineers had was refreshing; and kudos to Vikalp Sahni for building a team like that. This approach also captures some of the future cost; adding the next feature will take more time because this feature is adding some complexity to my architecture.

However, architectural complexity is just one of the costs of feature sprawl. Over time, I have realized that are more significant costs and that is what I want to take about.

There is this popular catchphrase that many engineers use "think twice, code once". I think what really happens is "think twice, code once, test every single time". You build a feature only once but you to test it every single time you send a release. In the earlier example, the payment stack has to test all of those nice discounting options and that will take its toll. When smart engineers encounter a set of features, they design smart solutions; micro services, separation of concerns, caching to keep the architecture as clean and latency as low as possible. But, even the smartest of engineers can't really avoid the testing part. Yes, you can build automation but anyone who has built automation over a noodle of services knows how fragile it is and the effort needed to maintain it across teams. This testing cost is a cancer; it kills you slowly; forces you to add more people but you still don't see the velocity you were looking for. Always remember "you code only once but test it multiple times".

Feature sprawl adds clutter and that has a direct business impact. I have personally seen many online platforms that have become just too hard to use; for the same customer pain point, they give multiple solutions. If I have a question about a product, I am not sure if I should check in "description", "detailed description :-) ", "reviews", "Questions and Answers", "FAQ" or "click on the chat" button. When I am looking for a deal, there are so many different kind of coupons available; some visible, some hidden that I have no clue what I should be doing.

Feature sprawl not only puts a huge cost on developing new features (via technical debt), testing a platform for a release but a huge cognitive load on the end user. Having no constraints on your head count will inevitably lead to feature sprawl and at some point you will have layoffs. Scarcity is so much better; a smaller productive and engaged team building the features that really matter; at a velocity that your customers love.

Less is often more.