An RFE for RFEs

In this brief blog I'd like to discuss the topic of product RFEs (Requests For Enhancements) - now as far as I'm concerned this is very much one of the most ignored and abused topic areas of the customer / supplier relationship.

Some tiny examples :-

• One supplier I know took 4 years to process an RFE that they admitted was both useful and easy to do, but somehow it never quite made the development release train - and nobody could explain why.
• Another recently updated their internal RFE system, and in the process simple deleted the details of all previous RFE requests
• With one supplier I have at least 3 different ways that I'm required to register RFEs - as the method is different for each product (but feels like it's totally random)
  
• Heck, at the time of writing, even the mighty WikiPedia doesn't have an definition for RFE http://en.wikipedia.org/wiki/Request_for_enhancement !!

Frankly the status of RFE management staggers me. In @SteveTodd's recent book Innovate with Influence he quite rightly points out that a lot of innovation comes from customer demand - and yet for many vendors the method for accessing and capturing the customer requests is opaque, fragmented and often best described as broken.

Suppliers rarely seem to demonstrate they include consideration for a product's existing customer RFE lists when designing next generation products - this may occur but the communication & dialogue with the customer is sporadic and often after the next product has been 'feature locked'.

The process seems to be normally 'handled' by the local technical representative on the account, resulting in a lot of human processes & resource consumption, interpretations, delays (always dropping down the priority list), difficulties for global orgs (customers & vendors) to align on RFE priorities etc. Thus sorting this out will not only help get (some of) the right features progressed in the right timeframes, but should also save both parties money due to less people effort associated with the 'process'.

Some simple things here could make a big difference, for instance :-

• Operating the RFE handling under a clear process and SLA
  
• Publishing a document explaining the process and SLA
  
• Using a standard electronic template for information capture
• Having a common format for agreeing & valuing the benefit and priority to both customer and supplier
• Understanding that it's key to have regular communication and update on the status of the RFE
• Committing to a finite time-line for a decision (ie yes now, yes future, possible, private funding, never etc)
  

Of course, exactly the same comments and disappointments exist for most vendor's Interop & RFQ (Request For Qualification) handling as well - some key additional points that would help here are :-

• Up-front published & consistent clarity over the information required when raising an RFQ
• Clarity over the terms & definitions of an acceptance or rejection
• Maintaining a customer accessible database of their existing RFQs so that they can be tracked over time and checked for ongoing validity, updates, being superseded, and included within support contracts
• Putting RFQs into the standard interop documents ASAP after qualification
  
• Providing a customer accessible and downloadable version of the interop matrix/documents - including maintaining customer access to historical versions (as a large number of RFQs are with older tech)
• Providing a greater level of detail within the interop documents for those products that don't have a 100% fully supported status (ie tested but failed, not tested, worked but no longer commercial support etc)

It also continues to surprise me that at vendor's customer council sessions they rarely, if ever, discuss the topic of RFEs - both process and/or content. I'd have thought these would be an ideal forum for suggestions, discussion, refinement, prioritising & voting on RFEs - I know one user forum where this happened and in effect the 30 customer companies jointly agreed on a 'prioritised top 10' RFE list for that vendor and issued it as a single entity. Surprisingly enough that list got focused work on and all the entries were completed within 6 months - a win-win for all!

The topic of more public and peer reviewable RFE lists certainly intrigues me - again most vendors have online web portals of some description for their support forums, yet rarely do they allow customers to view, comment & contribute on RFEs. The exception appears to be some of the newer/smaller companies, who make use of web technologies to perform this. One such technology is http://uservoice.com/ which allows customers to submit, comment/refine, and vote for RFEs - a perfect example being the RFE list for tweetdeck at http://tweetdeck.uservoice.com/pages/1192-general Once again my question is why major vendors don't make use of such simple and positive customer engagement methods?

Yes there is a danger of 'shiny bauble' syndrome, or indeed 'vendor bashing' with RFEs - but if managed and facilitated well, with the right people, then this really is an area that massive strides can be made in short periods of time.

Yes of course there are some interesting areas re IPR ownership, but they tend to be handle by the inter-company framework agreements, or for smaller relationships the terms & conditions etc.

Naturally this is also regularly overlooked in the TCO/ROI cost and benefit calculations - and anybody that's had RFEs eaten by the 'chaos demons' or RPQs impacted by the 'time-delay elves' would certainly agree that there are costs & benefits to be measured here!

Now show me a supplier that openly promotes and communicates a single RFE (& RPQ) process, with user self-serve & transparent status checking and that operates under an SLA - and I'll be a very happy man waving purchase orders!