Feature fatigue and the risk of overcomplicating RFP technology with features
What makes an RFP management solution, or any technology, great? When I ask this question, or hear it asked, one of the most common responses is “features.” While this answer seems straightforward and obvious at first glance, it always prompts me to dig deeper. Because in my experience, an abundance of features doesn’t always lead to a better user experience.
As I’ve talked with customers and asked about their experience with other RFP software tools, I’ve noticed a trend. Often, programs that continually add flashy features end up creating an unforeseen problem for their customers — feature fatigue.
Below I will explore what exactly feature fatigue is, the research that’s been done in the area and the risks associated with software that has too many features. In addition, I’ll discuss best practices for feature development and how to avoid getting wrapped up in feature hype.
What is feature fatigue and why does it matter to procurement professionals?
Feature fatigue happens when customers are overwhelmed by a product that has too many features. Bombarded by these capabilities, customers then turn to software that instead prioritizes design, quality, usability and stability.
When considering RFP software, it’s important to think about how feature fatigue can impact adoption among procurement professionals. The easier it is for RFP issuers and vendors alike to use an RFP program, the more effective it will be. Software providers that tout countless features may lose sight of their core purpose — making the RFP process easier and more efficient for the user.
A recent blog by Chargebee discussed how SaaS technology suppliers should think about the true value of features saying,
“It’s the era of instant gratification, and every prospect or customer wants what they want as soon as possible. And in such situations, companies succumb to the short-term goals of satisfying a customer or converting a lead, while losing sight of the long-term objectives.
Before nodding yes [to a customer feature request], ask yourself if the feature will still carry weight after five years.”
The post goes on to advise companies to look for the issue at the root of a customer’s feature suggestion and focus on fixing that.
“So instead of solving one-off favors, dig deeper into the request, figure out the root cause, and then tackle that. Make a trade-off by disappointing a single user initially, to create a much larger impact for all your customers in general.”
How feature fatigue impacts user experience
When companies forget the essential truth, that software exists to serve the user, they set their customers up for confusion, frustration and dissatisfaction.
The science of feature fatigue
Don’t get me wrong, features are great (and absolutely essential to any technology), but there comes a point when you can have too much of a good thing. I frequently come back to this example of feature overload originally used by David Pogue in his excellent TED talk, Simplicity sells.
When I look at this screenshot, full of buttons and tools, I instantly feel a little claustrophobic and overwhelmed. Technology that tries to be everything to everyone often loses sight of the problems it intends to solve. In this illustration, the primary purpose of the software is word processing, which is entirely overshadowed by features. David calls this the software upgrade paradox saying, “If you improve a piece of software enough times, you eventually ruin it.”
The idea that too many features can lead to dissatisfaction isn’t a new one. In 2005, the University of Maryland and the American Marketing Association published a research study that explored feature fatigue. The results indicated that people who choose a product based on features are often disappointed when the experience falls short of their expectations.
“Thus, what appears to be attractive in prospect does not necessarily appear to be good in practice: When using a product, consumers may become frustrated or dissatisfied with the number of features they desired and chose before using the product. In short, product capability may become too much of a good thing.”
The study cites a Rockbridge Technology Readiness Survey that indicated that 56 percent of consumers are overwhelmed by the complexity of the high-tech products they purchase. RFP software solves a simple problem, how to quickly and efficiently get accurate answers from suppliers to buyers. Technology that focuses more on delivering new features than solving the user’s problems sacrifices customer experience.
5 risks of overengineered RFP software
Investing in an RFP management software, or any SaaS technology, that prioritizes features that dazzle over thoughtful functionality is a risk. Overengineered solutions can be plagued with issues that directly impact ROI.
Tips to avoid getting sucked into the hype
It’s easy to get caught up in feature comparisons. For many procurement professionals, it may be second nature to favor feature-heavy products. But features don’t always mean it’s a fit. So here are some tips on how to cut through the feature hype and select the right technology for your business.
Keep your problem front of mind
The first step in any technology procurement process should be to clearly define the problem you’re trying to solve. For RFP software seekers, it’s usually one of these:
Challenges for RFP issuers:
- Issuing RFPs to vendors is inefficient, repetitive and time-consuming
- Scoring and comparing supplier responses manually is cumbersome and leaves room for unintentional bias and human error
Challenges facing RFP responders:
- Responding to RFPs takes days of tracking down answers and getting approval from other departments
- Avoiding the risk of reusing previous responses from business stakeholders that are now out of date
Carefully consider the root problem, and with that information, outline what functionality your business truly needs. Don’t lose sight of what you’re actually trying to accomplish. Ask yourself if the features your vendors are pitching directly help achieve that end goal more efficiently. If not, set those items aside and compare only the features you will actually use.
A study conducted over a four-year period indicates that in the U.S., 37 percent of software is unused at a cost of around $30 billion. Many people believe the old adage, “you get what you pay for,” but when you’re paying for features you don’t need and won’t use, you’re better off saving your money.
Ask for references
One of the best ways to cut through feature hype is to talk to someone who actually uses the software, so ask for references. Any RFP software supplier should be able to provide a handful of current customers that will give you the real scoop. Be sure to ask for references in a similar industry or who have a similar use case to yours.
Capterra offers a helpful list of 25 questions to ask software vendors. From that list, ask the references these to help separate flashy features from thoughtful functionality:
- How does the system perform vs. expectations?
- What are the best features and limitations?
- What feedback have you gotten from the users?
- Describe the implementation project and team.
- How long did it take to implement the system?
- Describe the technical support process. How do you submit issues, receive help, etc…
- How responsive is the vendor to issues?
- What is the quality of support?
- What has the return on investment (ROI) been so far?
- Would you select this vendor/system again?
While not all of these questions ask directly about features, each is impacted by them. Asking these questions will give you an idea of how well new features are executed, whether they improved the software or made it too complicated for users and if the features are worth the cost.
Best practices for feature development
If some features aren’t worth the cost, how can you be sure your technology partner prioritizes the right things? It’s easy — ask them how they develop new features. When they answer, listen for these feature development best practices.
Feature development should involve:
- Listening to customers
Whether it is through support channels, engagement check-ins or product advisory boards — the vendor should offer lots of ways for you to send in your product feedback.
- Educating customers
After you provide feedback, your technology partner should be able to explain how they approach development. For example, they may dedicate 70 percent of software development to new customer features, 20 percent to visionary items and 10 percent to architecture. Based on this, not every feature you suggest will go into development. Weighing features across all customers and the organization is an art not a science, but you should always feel heard and understood.
- Conducting a testing program
Once developed, features need time to be tested by real users like you. Some companies roll out new features to their customer success team, or even a select group of trusted customers, for the beta or testing run. This allows well-versed users to work hand in hand with customers who will have a very close eye on how the new feature or functionality is performing.
- Communication and training programs
Releasing a feature is the exciting part, but it must be done right. Does your RFP technology offer new feature webinars, include training sessions, provide in-app updates or help articles that are actually helpful? This documentation should be an integral part of feature rollout.
The balance between features and function
Find the right RFP management software by looking for a company with happy, long-term customers as well as friendly, helpful customer support team. In this market of growth and opportunity, SaaS companies can’t afford to be stagnant. But there’s a difference between thoughtful evolution and haphazardly tacking on features to make a sale.
When it comes to technology features, it’s all about balance. I get just as excited as the next guy about a truly useful, elegant feature that meets my needs perfectly. But at the end of the day, features should never come before the customer experience.