Feature fatigue and the risk of overcomplicating RFP technology with features

Written by
Graham McConnell
Graham McConnell
Updated on
  10 min read

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, research on the topic 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 a product that has too many features overwhelms customers. 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. 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.

Feature overload

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.

Overwhelmed by tech

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.

There’s no doubt that technology can improve efficiency within the RFP process, which is great for everyone. But no RFP issuer, or responding vendor, wants to use a system that makes them worry that they’re going to mess something up. Thoughtful, easy-to-use systems will enjoy much wider, long-term adoption. On the other hand, software that makes people feel dumb will end up unused. This costly shelfware delivers little to no ROI. RFP technology should be easy enough to use that you feel empowered, not paralyzed.

If people aren’t using your approved RFP management system because it’s too complicated, they’re almost certainly using something else to help them manage the process. Known as shadow IT, these technology solutions are deployed outside of the organization’s IT infrastructure. Typically they’re used by individuals or teams who like the simple, consumer-grade tools they are already familiar with. This practice introduces risk to your business. It creates a pocket of unprotected, potentially sensitive data. In addition, it places that data in an unsanctioned, siloed environment.

In fact, Gartner estimates that by 2020, one third of successful attacks on enterprise data will come through shadow IT. So it’s in the business’s best interest to select tools that are user-friendly and intuitive.

Shadow IT Risk

One of the defining benefits of SaaS technology is that updates and enhancements are frequent. With each new release, users enjoy upgrades to existing tools as well as access to brand new features and integrations. As mentioned above, many of these updates start as a customer request or suggestion. Ideally, these suggestions are thoughtfully considered and evaluated. Then, the features that are the most universally useful progress to development.

Unfortunately, some SaaS companies believe that more is more and forgo taking the time to evaluate a suggestion’s long-term value. Instead, they become a feature-genie, granting individual requests regardless of their merit to the larger customer base. This sort of on-demand model means that all customers pay to support the creation of features they don’t want or need.

For example, it’s great when an RFP software integrates with your CRM or cloud storage system. However, each business likely only uses a couple of these connectors. So, who pays for the development when a new customer wants to connect to an uncommon program that only they use? The unfortunate answer ⁠— you.

Beyond the cost that’s passed along from the initial development, new features also require ongoing support. Features can be a little like a game of Jenga, the faster you stack them on, the more likely you are to build an unstable structure. Unfortunately, the end result is that it’s even harder to isolate where the problem is.

Every feature added is another potential support ticket. Every support ticket is a potential bug that needs to be located and fixed. When features start stacking up, they can interact in unforeseen ways and without proper planning, something will crash, causing a loss of productivity for you and your team. This process is especially slow when an integration breaks and the issue could be in any one of three environments: the customer’s or either of the two integrating technologies. When your team relies on these connections, without them your process will grind to a halt.

Unnecessary or poorly planned features create a burden for customers as well. RFP issuers must retrain their teams and their responding vendors as they sift through the updates. Eventually everyone will adopt the useful features and find ways to work around the others that were clearly designed to meet someone else’s needs. The constant stream of finicky features can cause even tech-savvy super users to look for a more user-friendly solution.

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., unused software accounts for 37 percent of all software. This comes 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.

Cost of unused IT

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.

Graham McConnell

Graham lives in the B2B marketing space. He dabbles in writing, usually about digital marketing, but has other interests like the Portland Trail Blazers, the Portland Timbers, sci-fi films, video games and of course, response management.