A recent issue of the newsletter was called TLC for the RFP. It was all about creating materials along with a system and roles that would allow a company to generate high quality RFPs with less effort.
A subscriber writes in with an interesting question about the best length for answers to RFP questions. Many questions can be answered with a simple Yes or No. Is this a good answer or should you offer more detail if it is a strong suit of your product? What about if it’s a weak point? Also, if you don’t know if you’re a serious contender for the business (rather than column fodder), should you take the time to expand on an answer?
These are important issues to consider. Given that there’s the potential for a Product Manager to spend significantly more time writing responses when they go beyond one word answers, it’s crucial to determine how much effort should be put forth at the expense of other projects. Read on for some tips on how to answer RFP questions.
[private] Note: RFP stands for Request for Proposal. RFP officially refers to the document sent out by a prospective buyer to vendors to solicit information on their product. However, the term is often used to designate the actual proposal that gets sent off in response to the RFP. That is how the term is used in this article. Others call the second document a Proposal.A Big Waste of Time
One of the hardest parts about writing RFP responses is that you are bound, at some point, to wonder whether it’s a waste of time. You will always have to balance brevity and speed with the need to impress a prospect with the details of your product.
Both Ends Against the Middle
As a rule of thumb, longer answers are more useful at the extremes, meaning for features where your product has a sizable lead over the competition, or a strong disadvantage. Areas where you are middle-of-the-road can do okay with shorter or yes/no answers.
Just the Facts, Ma’am
Cultivate the fine art of providing a helpful, factual answer with no hype. “Lightning fast response” is hype. “Faster response” is factual. “Subsecond response time” is factual while being as impressive as “lighting fast” as long as it’s true.
Factual answers are generally a little shorter, since you cut out words associated with hype, including many adjectives. Here’s another example:
Hype: “The Campaign module lets you make lots more money by selling to your best customers.”
Factual: “Use the Campaign module to target the customers with the highest profit margin.”
(Okay, so factual isn’t necessarily shorter.)
If your answers end up being longer because you’re adding hype, it’s not worth it. With factual answers, you leave prospects with the impression that your RFP is objective and informational, not a sales pitch (even though it is in fact a sales pitch).
Painting a Picture
The most effective way to get an idea across to a prospect is to help them picture it where they work or live. If the RFP requirement in the Administration section is Backup Utility, your answer can state “IT support staff use a single screen to schedule backups ahead of time, specifying whether they are partial and full, how frequently they occur, and at what time of day. Designated individuals receive email alerts to insert backup tapes.” This provides a relatively succinct, factual image of who uses the capability and how.
“Yes, And” vs. “Yes, But”
The big pitfall for Product Managers who are hell bent on being precise and correct in an RFP, so as not to set expectations incorrectly, is to respond with “Yes, but.” As in: “Do you have a backup utility? Yes, but it can only be scheduled in advance.”
You can move away from “yes, but” by changing to “yes, and” answers. “Do you have a backup utility? Yes, and IT staff schedule all backups in advance.”
That’s Not What I Meant!
In your answers, you want to use “No” as little as possible. One way to do this is to think a little more deeply about the need behind a question. For example, the RFP says: “One-button email blasts from Campaign screen.” Probably a relatively rare capability. But when you think about it, this is asking whether you can easily send out email campaigns. Your answer might be: “Email campaigns are generated by using the Export button on the Campaign Details screen to create a list of recipients, then using the email engine of your choice to format a message with effective graphics and send it out to those recipients. Once the message is ready, emails can be sent out for a Campaign in under 10 minutes.”
Notice that the above answer didn’t even have “Yes” or “No” in it.
Yes or No Will Do, Thank You!
On the other hand, you don’t want to give your readers “feature fatigue” from too many explanations. Perhaps for certain sections, you can confine your descriptive answers to the overall section, then answer with a simple Yes or No on each line of the section.
How Many Ways Can You Say It?
One frustrating thing about RFP questions is that they do not allow you to express your product’s capabilities in the way you normally would organize and present them.
You may find that a given capability, say, reporting, is covered in three sections from three different perspectives: operational, historical, and analytical reports. In such a situation, you may be forced to write the same thing, with slight differences, three times. It’s quite possible that a given reader will only look at a single section, and they need to understand the capabilities.
You can also make the full explanation about reporting capabilities the first time the subject comes up, then refer to that section in the other sections. For example: “35 Historical reports are provided with the same drill-down and formatting options described for operational reports in section 5.2.3.4.”
How Does It Feel?
Finally, I use a very subjective litmus test to determine if I’m answering in enough detail or too much. I quickly scan the document to see what kind of impression it gives. Does it appear to be informative? Does it provide instructive information about a given feature, perhaps discussing an aspect that isn’t really mentioned in the list of yes/no questions? Is every answer long and convoluted?
Sometimes the effort to provide detail can be a success when you provide detail only in a few strategically selected areas. You may not need more than that to give the impression of great thoroughness.
Are You Column Fodder?
This brings us to another reason why you often find yourself wondering if all the effort for the RFP is a waste of time. You may be wondering whether you’re “column fodder,” where your product has been selected for comparison against another product that the prospect has already made up their mind to buy. They just need to appear objective in their selection process.
For this, your sales reps are your scouts, and they must determine this and let you know. They’ve got to come through in this area or your RFP efforts may be wasted.
One sign of being column fodder is when the list of requirements appear to be written for a specific competing product. It is likely that the sales rep for that competitor’s product has set the expectations.
If You’re Column Fodder
If you are column fodder, your chances of winning are more limited, plus you are required to prove yourself in a different way. If the prospect has another product in mind, you must be certain to provide answers that demonstrate your product matches all the capabilities requested. Then, you need to pepper your answers with topics that provide food for thought (see next section).
Another classic Solution Selling tactic is this: if you know you are column fodder, study the requirements to pick out capabilities that are omitted (because Competitor X doesn’t offer them). Then return the RFP with a cover letter stating that it is your company policy not to respond to RFPs when you feel the information is insufficient to give you a full understanding of how to fulfill the prospect’s business need. Then ask pointed questions around capabilities that Competitor X doesn’t have.
For example: “We are unclear why the Administration requirements do not include a scheduled backup capability. How does your company intend to minimize time spent by technical support resources backing up your applications?”
Food For Thought
It’s always good to give a prospect Food for Thought about a capability where your product has a competitive advantage. This is a variety of the old Fear, Uncertainty, and Doubt tactic. When the RFP asks for an email blast capability, explain that experience with your customers has led you to conclude that it is risky to provide an email capability that allows users to send blanket emails to customers without going through a well defined approval and staging process. And therefore you do not recommend an Email Blast button on the Campaign Details screen.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]