As the old adage goes, two minds are better than one. Now I generally agree with this saying, but when two minds become four become eight and input is overflowing left and right, things can get out of hand.
Feature creep, a result of too many features being added to a product, is an unfortunate byproduct of excess input. It's also probably one of the most fundamental challenges for a product designer or product manager to contend with. As you develop a product, it's easy to get personally invested in what you believe is the right feature set for a product. Unless you’re part Vulcan, you probably can’t help but get emotionally attached to what you believe will make or break a feature or product introduction.
One of our ongoing objectives on the product design team at Flite is to limit feature creep. From my experience, I believe there are a handful of tools to help counter feature creep:
- Agile development
- Usage metrics (both qualitative and quantitative)
Alan Cooper, the inventor of design personas, describes a persona as “like a stage actor who understands the motivations of their character and can then express them.” Making the most out of personas is a great first line of defense to keep feature creep at bay. Truly understanding user motivation when working with your product or feature will help guide you and the team as to what needs to be included and what doesn’t.
Something that our team invested in about three years ago was the notion of agile development. While it can be challenging to consider moving to agile development if you’re on monthly or longer release cycles, I can’t tell you how much developing and releasing weekly has changed our mindset on product development. Although there’s an art of knowing what the minimal viable product (MVP) and/or minimal desirable product (MDP) to release is, having a weekly sprint can also provide a comfort level as to what these terms translate to. Get the release out there in the hands of your customers and really measure and learn what is working for them and what isn’t - I can't stress this enough. To me, feature creep is usually a select set of customers or your internal team imagining what is crucial for a product. Not real life users and customers giving you real life feedback and telling you what is crucial.
And to complete the circle of life, once you get your MVP out to your users, you have to measure it to see where it’s hitting all the right notes and where it’s failing to meet expectations. Usage metrics, qualitative and quantitative, are helpful to inform what features you should build next. Qualitative metrics mean getting out of the building to meet with your users. See what’s working for them and what’s not. You can then back this up with quantitative metrics, which are analytics you've added into your feature set to see if the data points line up with what the users are telling you. If you’re releasing weekly or in an agile manner, you can quickly bring back the learnings from your users to the product team and make small but carefully measured iterations. What’s great about all this is that the team can feel good about the learnings and know they’re building a product their users are actually using.
By using these processes and tools, you remove the emotional components and instead shine a light on the features your users can make use of. The guesswork and debate over whether a feature needs to get into the product slides by the wayside as real data aids in making the best possible product prevail.