Feature Listicles: A Former Necessity

In striving for quality, it’s easy to fixate on software features. In practically every sector, the software sales and marketing process inevitably fixates on solution features. This is because prospective customers have done their homework regarding what they need and create shortlists based upon these capabilities. We all appreciate lists by nature. Otherwise, why would “listicles” be so popular? Compiling a list of wants and needs is a long-standing practice. It is an easy way to compare one solution to another. Unfortunately, these feature lists and often RFPs can be used as proxy to understand a solution’s true promise.

In document automation, it is no different. We often get questions such as “Can your software classify and separate documents?” “Does it support zoned fields?” “Does it support keyword-based field location?” “Regular expressions?” “Is there validation against third-party databases?” The list of questions regarding features can be highly detailed. (By the way, we answer “yes” to all of these.)

The Whole Story

Do features tell the whole story? Ultimately, we make purchases based on expected outcomes. We buy our cars to satisfy a need or set of needs. It might be to have reliable transportation. It may be to signal success. It might be to save on gas. Or, it may be a combination of these. And yet while there are always exceptions, we rarely purchase a car based upon the type of gas it requires, the type of radio it has or the size of the radiator. We “hire products” to borrow a phrase from Clayton Christensen to “do a job.”

Milkshakes and Disruptive Innovation

When buying a milkshake (also borrowed from Mr. Christensen) you purchase an outcome to enjoy it and to satisfy a hunger. Unless you are planning to make a milkshake, you aren’t concerned with the proper temperature, the manufacturer of the cup or the source of the flavoring.

Manual Handling of Financial Documents

Let’s take a situation where you are hiring someone to perform data entry from financial documents. Do you ask them if they can find the invoice number regardless of where it is located on the invoice? Do you ask if they can tell the difference between an invoice and remittance advice? Do you ask them if they can work with poor quality documents? Of course not. You are interested in whether they can work in the office or remotely, if they work well with others and if they are reliable. Since the data entry person is a human being, you assume they can do the basics of the job.

Self-Learning Software Leads to End of Feature Wars

With the advent of self-learning, software can be treated the same way. With software that can learn your documents and improve over time, regardless of document type or data involved, you no longer have to spend time understanding whether the software has the ability to find data that is located in different places or use text to classify one document from another. You no longer need to identify if it can use regular expressions to identify and validate the data type or work with documents that are highly variable.

Self-learning employs concepts based upon human learning and thinking. Instead, you can spend time understanding if it can work with others (integration options), if it can work in the office (on premise) or from home (the cloud), if it will be reliable (scalability and options for high availability) just as you would with a real person, and assess if it is a high-performer (data accuracy). Even better, you don’t have to worry about staff turnover – your self-learning system will be a happy employee forever.

Self-Learning Software: Attributes that Matter

These are the attributes that really matter now and in the future. Systems that cannot learn on their own will be viewed as ripe for replacement. Features don’t matter – outcomes do and this means the main question should be is “how smart is your solution?”.

>>Find out more about self-learning software for document automation here and watch the video.