Monday 5 October 2009

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!

4 comments:

  1. Hey Ian,

    Good topic.

    Larger vendors will always struggle with RFEs. They have not agility to flexibility to incorporate client generated functionality. For some also it is a culture thing, as in:

    "Just had Bob on the line again with another 12 ideas to make MY product better" Stu Dent (Redundant Functionality Edicts Manager)

    We also work with Apple. How many RFEs get through that vendor do you think ;-)

    Some clients will see agility and domain expertise as a real benefit to ensure a solution fits their workflow and thus are likely to choose a smaller vendor.

    We are small enough right now to react to RFES (doubled performance for one client in 6 weeks) but will this be the same once we grown significantly? Hope so.

    www.twitter.com/om_nick

    ReplyDelete
  2. Nick,

    thanks - to me it's not fully about getting products changed, it's the comms & handling of the process that's so utterly borked.

    I could name another very large IT software company that didn't know what their RFE process was or if they had one.

    Perhaps if they stopped feature yanking against the tick list 'arms war' and actually asked the customers and then shared with other customers for feedback / refinment / priority in a reasonable process, we may actually move forward...

    Fully accept large company drudge & confusion - indeed one of my employers certianly is far from great on this, but vendors need to recognise in a commoditising industry that it's service, communication & agility all factor heavily into retention / investment decisions.

    Thinking of a t-shirt design for storage-expo now...

    ReplyDelete
  3. Would be interested in the ratio of user generated features vs IP creating , secret squirrel, R&D that also needs to happen to keep products out front.

    Is it 50:50 or would a heavier bias (75%?) towards user generated always keep products relevant to clients needs and thus more likely to be chosen?

    You should be thinking of who is going to sponsor your crutches at Storage-Expo ;)

    "Object Matrix: enabling Grumpy bloggers" ;-)

    ReplyDelete
  4. Great topic. I personally would like to see a two-step vendor process for RFEs.
    1. Post them internally on a vendor wiki so that employees can see them all and comment/collaborate on them.
    2. Open the wiki up to customers so that they have visibility to the comments (or lack thereof) and can participate in the collaboration.

    ReplyDelete