Product Management and RFPs
from PRODUCT MANAGEMENT CHALLENGES
A Weekly Newsletter of Tips For Companies that Develop Software
One of the biggest headaches for software companies of all sizes is the creation of RFPs. RFPs are labor intensive, exhaustive and exhausting efforts to tout the product. The effort to produce RFPs can be a drain on precious resources in Sales, Marketing, and Engineering. And Product Managers get involved more often than they wish they did.
The blood, sweat and tears expended on an RFP is all the more frustrating because you're left in doubt about whether it really makes any difference in winning the sale. Often the RFP is a cruel exercise in jumping through hoops for a prospect that is using you as 'column fodder.' You're column fodder if your purpose is to provide a point of comparison, a systematic review with the pretense of objectivity that only serves to back up an emotional decision, made long ago, to go with a product they like--somebody else's product.
Yet despite what they tell people in sales training, you can't exactly blow off the whole RFP process and still hope to win a sale. While it's up to the sales rep to make sure that you have not been selected as column fodder, your company must create an RFP that:
- Stands out from the others,
- Demonstrates the uniqueness of your product,
- Wins over the doubters, and
- Gets you to the next step in the sales process.
So if you've got to do RFPs, how can you make the whole experience a little less painful? How can you streamline the process so that fewer resources are spent on what is arguably an ineffective way to make a sale? Read on for some guidelines to focus the RFP process.
Sales Owns the RFP
Lots of people help with RFPs, but Sales has to own them. Yes, it's business for your whole company, but it's their commission checks we're talking about. The head of Sales must be the one ultimately responsible for making sure RFPs happen, and happen well. Everyone is tempted to pass along the RFP like a hot potato, so don't let Sales foist it off on Marketing or Product Management.
Marketing Ensures the Messaging
Marketing, while not owning RFPs, helps review the wording on both a surface and a deeper level. First, Marketing ensures that the content is okay on the surface, with correct spelling, punctuation, grammar, and style. Deeper in, Marketing weaves the correct messages about benefits and differentiation from your competition.
When there's a new question, one you haven't had to answer before, Have Marketing draft the first version and review and approve the final wording.
Product Management Provides the Benefits
The Product Manager understands the benefits of the product, and can tell good stories of how others have used it to their advantage. The Product Manager also knows what to say to undermine the selling points of the competition.
The role of Product Manager is to intervene when needed to augment existing materials or draft new materials here and there. Use your understanding of the product on both the technical and marketing levels to explain how good the product can be, without overstepping the bounds and committing to functionality that it doesn't do.
Sales Engineers Do the Footwork
Sales engineers are the ones who work with the sales reps (on an on-demand basis, as with so many sales activities) to build the RFP. This includes:
- Assigning who provides which content,
- Scheduling work and review meetings,
- Answering all the questions,
- Requesting help with specific answers,
- Riding herd on all the content providers, and
- Dotting the i's and crossing the t's.
A sales engineer should be the one to put together the first draft of the RFP, getting it as complete as possible, following the guidelines from the initial strategy discussions, before sending it around for review and filling in the holes.
Build a Knowledge Base
If Marketing and Product Management are going to spend the extensive amount of time it takes to strategize, focus the content, and write appealing answers, all that hard work better be put to good use over and over again.
Build a knowledge base that collects, categorizes (and even indexes) all answers to past RFPs, incorporating content from each RFP as it is sent out, to be used as the knowledge base to answer future RFP questions.
This can be as simple as a word processing document, perhaps with a table of contents or an index, or a number of documents that are categorized and indexed using a spreadsheet that lists the appropriate filename next to a key word or under a category.
The sales engineer's job is to use this knowledge base to build the first draft of the RFP.
Create Small Building Blocks
Don't try to create large templates or entire sections of answers. Break your answers up by individual question, because each RFP is going to require that you sort and order these blocks of information in a different and unpredictable way.
If you find that you're frequently breaking up blocks of standard content from the knowledge base when you go to use them in new RFPs, take those blocks and break them down further.
When you put an RFP together in this way, your first draft will probably read like it was slapped together. That's okay. The next step is to take a pass at tying together and unifying.
It's the Online Age
My, how technology makes it easy to publish and link information these days! The knowledge base is a perfect example of something that belongs on an Intranet, where everyone in the company can access it as needed.
You can even set up your index as an Intranet page, where you click on categories, or listed questions, or index words, to jump to standard content.
Answer the Question, Please
Although you're using standard content, it's critical that the team reads each question and adjusts the content to specifically address everything that is asked in each question. No reader wants to puzzle through a response to a question only to realize that it didn't answer what was asked.
Which leads us right to the next topic ...
It's Never Really Cookie Cutter
RFPs aren't cookie-cutter (fortunately or unfortunately. I'm not really sure which side to weigh in on for this), so your responses to them can't be either. An RFP has to read like your company sat down and wrote a specific response to the questions, concerns, and priorities raised in the guidelines and questions.
You can take care of much of this in the Executive Summary, where you highlight what the prospect has indicated are the most important concepts, directing readers to more detailed sections in the body of the RFP.
And if you do your homework, focus your effort, work hard and get lucky, your RFP will get you to the next step in the sale. Never mind that the final scope of work may sound nothing like your initial proposal. A closed sale is a good thing.Copyright © 2003 Jacques Murphy. All rights reserved.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.