Your Competitor Wrote The RFP You’re Bidding On

I think it was due to overwhelming boredom with the RFP process that I once partnered with my sales leader to say Yes to every single requirement on every RFP bid during the summer of 2020. We called it The Summer of Yes.

It didn’t matter. Our win rate didn’t change.

Here’s a few things I’ve learned about RFPs over the years.

Your Competitor Wrote the RFP

A common sales process in B2B enterprise looks like this:

• Our outbound sales ‘warm’ calls a prospect. They get them on a demo. This probably takes multiple calls and other marketing touches.
• We bring in a solution consultant who does a killer demo, amazing the audience with what seems like purpose built features for this prospects extremely ‘unique’ needs. There's often multiple demos.
• a pricing quote is prepared by the sales rep and we’re finally going to see if we wasted our time.
• the prospect sees the number and says something like ‘Because it’s over X we’ll have to go to competitive bid'
• They like our software. We built the relationship. We’re almost friends now. We all think we can influence this RFP such that we will win.
• We offer to consult and provide them a list of things that should be requirements. These include things that are specific to our application or service offerings. These may or may not be actually important requirements for this prospect to be successful. It will be really difficult for competitors to appear competitive on a side-by-side feature compare that RFPs tend to generate.

I know this happens because I’ve been a ghost writer on an RFP that a prospect would be distributing to a dozen other vendors.

It’s also very easy to identify proprietary terminology that competitors use.

Here’s a couple examples.

• application must have real-time configurable smart widgets
• application must support job stacking

What is a real-time configurable smart widget? What is job stacking? I have no idea. If it sounds like marketing speak, it’s probably coming direct from a competitors website or one-pager. Do some digging.

So if I am lucky enough to be ghost writing my prospect’s RFP, at least we’re going to win right? Not quite.

The Email Chain of Requirements

Something that happens inside your prospect’s org when they begin defining requirements, is that your champion takes the requirements that you worked on together and circulates those to dozens of other stakeholders in their company.

In a bizarre game of one-upmanship, it’s now a competition to see who can add the most requirements. Who can make the bidders lives the most hellish of hellscapes? You can often clearly see the shift in language and terminology used in RFP requirements where a different stakeholder pasted their needs into the doc.

It's common that, after this requirements dump, no single person reviews, consolidates and does a reality-check on the needs outlined.

Nearly every RFP will have:

• The same need described 6 times using different phrasing
• Requirements to integrate with one or many proprietary or niche systems
• Requirements to migrate data. All of it, with all relational data properties intact and as it was before.
• Pages of IT requirements that have no understanding that SaaS is a thing or that that the cloud exists. -- Speaking of IT, this is often where they introduce confusion between Java and Javascript
• Must-have requirements that will never ever be used by anyone
• A complete lack of concern for end-users or their ability or desire to use the system described
• Impossible implementation time-frames

You’re Buying a Logo

As a vendor, your job is to determine whether you want this. It’s costly to bid and often more costly to win.

Spending absurd amounts of time across your org doing RFP submissions is rarely quantified from an ROI stand-point. If you’re in a type of business where RFP bids are involved from time to time, do your best to understand if it’s worth it. A typical RFP bid could take many hundreds of hours, from start to finish, especially if you progress past initial phases. Not only does this have easily quantifiable real costs, but the process also has runaway opportunity costs involving the product team, engineering, sales, legal and marketing.

Also keep in mind that you’re probably not scaled to address the implementation needs and will need to ramp up hiring immediately if you win. It’s also highly likely that your bid price is 50% of your list price.

In the case of RFPs, think of it like you’re buying a logo. You want this nice logo on your website, in case studies, in press releases and in CEO powerpoint decks. What is this logo worth to you?

By Saying Yes to Everything This Will Bury Product and Engineering Right?

Often you assume that by saying yes you'll be penalized down the road when you get found out. Did we lie? No, we selectively understood the requirements in a way that we could meet it. The thing is, nobody really needs 80% of the shit that's in an RFP, and they will never hold you to that. The implementation will take 3x longer than promised and your champions will no longer be with the company by the time you’re rolled-out anyway.

By winning large RFP contracts, you will get buried, but not by the requirements you said Yes to. You’ll get buried trying to implement and retain this customer. Every week will be a new urgent requirement that was never covered in the RFP. We need to integrate with Qlik!! We need a data warehouse! We need to restrict access to the app to certain IP ranges!

Proceed with caution.