The real cost of feature sprawl
Sprawl

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.

Nishant Kumar

Product Strategy Consultant | ex-Zynga,Livspace,MakeMyTrip

2 年

Very well articulated Akshat. Diminishing returns is perhaps an indicator to revisit the strategy. There will always be a time when the focus of an org have to shift from experimenting more to building just the right thing. The answer will lie in what is more important for the organization at a lifecycle stage or whats the path for next 10x growth.

Arun Dudee

Chief Technology Officer

2 年

absolutely true Akshat Verma

回复
Nitin Malhotra

Senior Director of Engineering

2 年

Nicely articulated ????

回复
Zafar Ahmed Ansari

Engineer ? Philosopher ! Writer ?

2 年

Managers should love smaller teams. They are easier to control, much clearer demarcation in responsibilities, and rewards per individual are also high. However, in the corporate world I see that managers often tout that they grew a team from x to y, and higher the y-x, greater are their promotions. Going by the observations that you have posted here, these should perhaps be the last things they should be advertising! A case in point of your observations is the product Whatsapp. They managed to keep their team small for many years, and perhaps it was therefore easier for them to keep the feature set small but only of the essential variety. It has been the defacto standard for minimum design. I got reminded of a meme I liked recently. It said "adding manpower to a late software project makes it later". Perhaps it is true after all, I have seen that happen personally too.

回复
Anant Kumar

EVP Engineering and CIO Digital

2 年

I personally feels we focus a lot on metrics. If only we could understand what is customer pain and how the experience will come alive across all touch points. Even if it does not move a metric or is hard to measure but it gives good experience. Then that should get prioritised over everything else.

要查看或添加评论,请登录

Akshat Verma的更多文章

  • The MVP conundrum

    The MVP conundrum

    What should be the scope of our MVP? This is probably one of the topics that is the most debated, while building a…

    2 条评论
  • Layoffs, hiring and staying true to yourself

    Layoffs, hiring and staying true to yourself

    This has been the season of layoffs - the worst we have seen in a while. A network like Linkedin has been useful as…

    5 条评论
  • Can you be an excellent architect without product management skills?

    Can you be an excellent architect without product management skills?

    One very welcome change I have seen in India is the rising trend of engineers aiming to stay technical for a longer…

    3 条评论
  • What a head-of-engineering is meant to do?

    What a head-of-engineering is meant to do?

    Recently, a person who was earlier part of my team and is transitioning to a head of engineering role asked what a…

    4 条评论
  • Visual Maps - the key to solving complex problems

    Visual Maps - the key to solving complex problems

    Visual learning has been in vogue the past few years - learning via images and videos. The logic for visual learning is…

    1 条评论
  • Resisting the urge to overfit

    Resisting the urge to overfit

    I drive back via NH8 from Gurgaon to Delhi on a daily basis. For folks familiar with the drive, the entry to Delhi…

    1 条评论
  • Why "First Principles" thinking is so hard

    Why "First Principles" thinking is so hard

    "First principles" is quite in vogue these days. One can find a lot of articles that extol the virtues of "first…

    7 条评论
  • why your tech architecture needs to adapt to your team team

    why your tech architecture needs to adapt to your team team

    Many many years back, I was taking an interview for a principal engineer position. As is the norm in all my senior…

    3 条评论
  • The fine line between solving a painpoint and being creepy

    The fine line between solving a painpoint and being creepy

    Being a product manager is a hard job; being a product manager at a cross-sell company is even harder. A cross-sell…

    4 条评论
  • When vendor lock-in makes sense

    When vendor lock-in makes sense

    Flexibility - it is one of the most important aspects that we care about when evaluating technologies. Flexibility is…

    1 条评论

社区洞察

其他会员也浏览了