A very common method for selecting print software from a set of vendors is running an RFP (request for proposal) process which typically distributes a document and/or a list of features that you require to solve a particular business challenge. Buyers who use this methodology often believe the quality of their purchasing decision is directly related to how thorough their RFP is written. I wish it was that easy. In this case, more is not necessarily better; in our grasping to capture every feature we might ever need we create a bias in the purchasing decision. You are indirectly saying that the most feature rich product is the best, when often the business challenge you face requires very deep functionality in some areas and very little functionality in others.

There are so many challenges about the RFP process; I’m not sure where to start. How about the most glaring and obvious, most vendors say yes to everything, and they can because the way RFP’s are written always leaves room for interpretation. Hence, vendors read the question and then interpret it in a way that makes it possible for them to say yes. This is unavoidable in a written document without a tremendous effort from the buyer. So you spend a lot of time crafting an RFP document and a list of requirements and at the end of this process you have responses from many vendors all of which say they can basically do everything you’re asking. What have you actually learned in this process?

The second weakness of the RFP process is that you require a few customer referrals that are hand selected by the vendors. This also produces very predictable results. Guess what the customers who are selected to be references for the vendor say about the vendor? You guessed it, all good marks and maybe one bump in the process to make it feel real. So again you’ve exerted effort and spent your time and money to get feedback from many customers which all say the same thing. What have you actually learned in the process?

The third weakness in the RFP process is that the actual document fails to describe the challenges you have but instead recommends a specific solution and asks if the vendor supports that solution. What do I mean by that? Let’s say you were doing an RFP for a web-to-print solution. You have a specific client in mind for this solution but you also want it to be the solution for other clients as well. Your specific client needs you to support some unique kitting and fulfillment functionality. Your RFP is written exactly how your internal IT person thinks this should be solved, describing specifically how each product in the kit should be captured and the pricing calculated. You might think of this as being very prepared or proactive, but what you actually did was limit the vendors from coming up with better, more efficient ways to solve the problem. When you’re really specific in an RFP you limit your vendors into yes/no answers which leaves no room for innovation or differentiation. A business challenge that will be solved by print technology is best solved by a combination of two resources; someone who has full context over the problem and something who has full context over the technology. Only when you bring those two understandings together do you have a shot at getting to the best outcome. This means you (who understand your business) need to partner with a print software vendor (who understands their software) and then together you can come up with the best way to solve your challenge using their technology.

What’s the alternative to the RFP process? I have a four word answer: voice of the customer. The best way to understand if a particular solution is a good fit for your business is to find a business like yours that is already using the solution. This is what makes peer groups, user groups, and industry associations, so important. You don’t want to know the “theoretical” truth about the product. What do I mean by theoretical? How about this question; “Can this Print MIS integrate with this web-to-print system?” Yes, it can theoretically, but you have to buy the very expensive API module, get a 3rd party developer, do some customization, and the integration won’t survive upgrades). Do you see how a “yes” on an RFP about integration could be misleading? You want “ground truth” – a term borrowed from the military, what is happening in the trenches? You believe peers way more than you believe sales people, even if they say the exact same thing. The Edelman Trust Barometer reports, 84% of decision makers begin their buying process with a referral.

The B2B buyer study, which surveyed over 600 B2B marketers, also reports: Peers are the most trusted information sources, second only to industry analysts. Your peers are your most trusted information source; use them extensively in your buying decisions. If you want to send out an RFP, challenge the vendors to bring you innovative ideas, rather than a checkbox of features. Describe your business challenge in detail and then ask them how they would best solve that challenge with their technology, services, and company. This is a way better test of your potential future technology partner than an extensive feature list with all positive answers.