Increasing your chances of a successful feature request!
At yieldHUB we find that our best innovations come from customer requests. They use our tools everyday and are best placed to recommend enhancements. As with most things, how you ask is as important as what you ask. We thought we’d give you the inside track to managing queries, to help you get the most out of your software providers.
Beyond requesting enhancements of current features, B2B software vendors are regularly asked to add a new feature. These would be considered initially as feedback to be taken seriously. They wouldn’t treat them as a requirement straight away but provide their own feedback to the customer as soon as possible. The response much of the time might be to arrange additional training or to point out a video in the Help section of the product. The software product might be a very comprehensive system built over many years and sometimes features may be more hidden than one would like. But sometimes the feature is genuinely new and can even influence the roadmap and even inspire the designers to create a completely new tool.
Feature requests by and large are submitted via ticket systems and a gatekeeper replies before consulting with product management as he or she sees fit. The answer could be something like (A) Yes, we will review the request as part of our roadmap or (B) we accept we need to do this urgently (in the next or a near sprint) or (C) No, am afraid we won’t be doing it with an explanation.
Whether and when the feature is added depends on a few considerations.
Yes or No?
Firstly, what features are we likely to say No to?
Where the feature request is not part of the core objectives of the product. For example: in the case of a web-based thin client tool you might get a request to provide an offline analysis feature
Where it encourages the use of third party software outside of the product. For example, a customer wants to integrate an SAAS product even more with Excel when what they want to do in Excel is doable already in the software itself.
OK, what features are a software company likely to say Yes to?
Where it’s a no-brainer improvement furthering their core objectives. An example might be a new type of interactive chart
or Where more than two or three customers have asked for it. An example might be something these companies have seen from a competitor or because some new phenomenon is happening in their industry
or Where they are willing to pay for a customisation. The customer might need a particular integration which is specific to themselves and they have the budget.
Just because the vendor says ‘Yes’ doesn’t mean they work on the request straight away of course. This is often the order of priority of development work:
Bug Fixes
Features, prioritized by a combination of (i.e. in no particular order) :
Benefit to the community of customers, not just the requester
Paying customers (vs “tyre kickers”)
How urgent the feature is (eg competitors can do it and business could be lost
Cost of development
Cost of ongoing support
Funneling Requests
With larger customers, the software provider would ideally work through a small number of key users who funnel requests. It’s less likely then that they are bombarded with nice-to-haves or pet requests. Such customers typically prioritise their requests effectively. The higher paying the customer, the more likely they get ahead in the queue of course. At the end of the day every customer benefits.
The optimum chance of having your vendor work on something new and valuable to you is the closeness of the relationships you have with the vendor. Getting to really know each other, the constraints both companies are operating under and the vision the respective companies have are all key. So building close working relationships will help prioritization and the vendor can appreciate the real story behind a new request. Even if a request comes from only one company it could open up a new vertical market for the vendor while solving a real customer problem they haven’t seen before.