Discuss the concept of “feature creep” and its potential negative impact on product development. How can product managers avoid falling into this trap while addressing eager sellers’ demands?
The concept of feature creep, or more commonly referred to as just “creep”/”crawl”, can be simply explained as getting sidetracked from the “main” goal of a product. For example, imagine you have a Salesforce visual application used for your customers to securely input personal information like credit card info, addresses, etc. The main objective of this product is to do exactly that, capture information in a secure manner, while also causing no additional friction that’s unnecessary (this one is implied).
Your developers get on the job ASAP, and your seller suggests some features they think should be apart of the product. One stakeholder recommends to have a card info verifier to make sure that card information inputted is valid. Not a bad idea, could be potentially useful and a good edition. You approve that since you can “see the vision” and send it the developer’s way, but after another stakeholder suggests that you should be able to check the balance of your card when inputting your information— their argument is that by allowing customers to check their card balance before saving their information, you could avoid the headache of your card getting declined because of insufficient funds, making it easier for users.
This is where “creep” happens. Both of these features, although varying in their levels of usefulness, were not captured in the original product scope and causes it to drift away from its main, imagined goal. By allowing creep to happen, product development can take longer (because now you have to incorporate these new “features”), costs can increase, the original market fit may no longer be applicable (these new “features” can turn off users you were targeting)— there’s a lot to go wrong with feature creep.
As such, product managers can avoid this trap by noticing creep when it happens. You can take in ideas over time and set up a meeting to discuss them with multiple groups, stakeholders, and others to figure out whether such ideas are within the product’s umbrella or not. When a new idea/suggestion from your seller’s stakeholders come in, check whether this idea could cost excessive time or money, and whether the practicality of it in the product is necessary. If you allow creep to happen, you could fall into the trap of losing your target market‚ so noticing it when it happens and being moderately strict about the intended goal/purpose and disallowing drifting away from that is enough to combat creep is most instances. Remember, the article highlights how product managers overestimate the usefulness of a new feature within a product is when it really isn’t, especially when you’ve already successfully captured your target market and push these changes they’re unwilling to adopt— if it ain’t broke don’t fix it.
Additionally, it’s important to remember that the market and your userbase is always changing, and striking a balance between rapidly evolving and too rigid puts you in a flexible business model that allows you to avoid creep by staying true to your values/goals, while also recognizing market changes and adapting to seller’s demands.
