Skip to main content

Quantify those product changes/feature requests

One of the biggest benefits of cloud software is that customers can avoid the effort and cost associated with upgrades, security, hosting etc.  The tradeoff is that unlike (most) owned or "on-premises" solutions, customers don't have the ability to customize the software to meet their very specific business requirements.  As most cloud software solutions operate under a "shared" model (multiple customers using the same version of the software simultaneously), it means that any changes could likely impact just about every other customer that uses the solution as well.  Generally, everyone (vendor and customer) benefits by providing a solution that is relatively uniform across the board, thus making upgrades, security etc easier to manage.  

What this means to customers in these cases is that features that they may need, which are specific to their use case, are unlikely to get implemented unless numerous similar requests for the same feature are submitted by other customers.  

Often cloud software vendors offer some form of "Feature Request" process by which customers can indicate what they’d like to see added to the software, and ideally, the vendor's product management team can provide feedback on if/how/when said features will be implemented.

Here’s the thing though customers;  be thoughtful about what you include in your Feature Request.  If you really want to show your cloud software partner that you care about and really need a specific feature, be sure to quantify the impact of NOT having it.  This can be done in hours wasted (lost productivity), lost opportunities, and additional expense incorporating workarounds.  

Adding this critical, but seldom considered level of information will help highlight your case for that feature to be incorporated into the software, and (if properly tracked), will give you more clout at the renewal negotiation table.  

Presenting a spreadsheet of features you want with no indication of the value they will bring you only serves to frustrate the product management team, as the perception tends to be that you just want things your way and/or don't fully grasp how a cloud based solution in a shared environment works.  As such, it'll seem like you’re just listing out your grievances with the solution.  Instead, by quantifying the impact, you are clearly articulating how those missing features are adversely effecting how your organization operates.

Making your cloud software partner aware of these in advance, and aggregating/summing them up, in the lead up to the renewal will help to show that you are looking at the use of their tool and the reality of whether or not it drives the value that was promised at the time of purchase.

Don’t just build lists of issues, build a thoughtful, prioritized log of missing features and the impact they have on your organization.  And be sure to include what you’ve tried in order to work around the gaps in the meantime.  A conversation that includes language like:

 “Over the past year, the following 3 most important missing features for our organization have negatively impacted our teams efficiency by 35%.  We've tried the workarounds proposed by your support team, but our staff still struggle with adopting your solution fully.  We'd love to partner with you to find a meaningful, long term solution."

Is substantially more useful as opposed to:

“Here’s a list of 20 issues we have with your product.  When can they be fixed?”

 One is collaborative, the other isn't.  From what we've seen, the former approach simply yielded better results in both the short and long term.




Comments