AWS, HPE, Red Hat on 8 secrets of customer success with your SaaS vendor
- Summary:
- FinancialForce PSA customers AWS HPE and Red Hat talk about working with Customer Success Managers to get the best results from your SaaS vendor
In common with many other SaaS vendors — and indeed a growing number of businesses in the broader Everything-as-a-Service (XaaS) economy — FinancialForce has a team of Customer Success Managers (CSMs) that work with customers to help them make the most of the relationship. For its larger customers such as the three on this panel, it appoints a named CSM that keeps in touch with them.
On the customer side, each of these organizations has an internal product manager responsible for the internal roadmap for their PSA instance. They spoke on the panel about how they work with the vendor and with their own internal organizations to keep that roadmap aligned with the needs of the business and its users. Here are eight recommendations that emerged from the discussion.
1. Keep users involved in the release cycle
Because a SaaS vendor typically updates its software at least twice a year, there's a constant flow of new functionality coming available. Since FinancialForce runs on top of the Salesforce platform, that means four releases a year from the two vendors combined. Keeping users informed about new functionality that's rolling out — and giving them a chance to influence what's coming — is crucial, says Curtis Gold, Planning and Innovation at HPE, where there are 5,500 PSA users:
That gives us a quarterly opportunity to communicate out to our user community, 'Here's the latest improvements, here's the latest enhancements, and of course in part we've been listening to you, here's some additional items from that roadmap that are here to further optimize your experience.'
We've developed a pretty robust process to ensure that every end user has a voice in helping to influence that whole release mechanism. We want to empower them to submit their ideas, their complaints, their enhancement requests, no matter how out of scope they appear to be.
2. Have a mechanism for listening to users
When there's a large user base within an organization, it's essential to have some kind of community tool for collecting feedback. At HPE, the preferred vehicle is the Chatter messaging channel, which is embedded in both Salesforce and FinancialForce. While surveys can sometimes also be a useful way of proactively collecting feedback, the value of Chatter comes when it's used as a two-way channel, says Gold:
We have several Chatter groups, based on your role and your profile, and those are monitored — which again is very key, because they don't want to feel like their suggestions are going into a black hole — so we do have a governance team that is actively monitoring. Even if the answer is 'No thank you,' [they] reply back and say, 'No thank you' ...
If everything plays out nicely, some of those requests will make it into our internal release schedule. And then again, you can just communicate that out and that again becomes a wonderful enabler, for every end user.
3. Carefully prioritize your feature requests
Any feature requests coming forward have to be reviewed carefully to see how much value they'll have across the organization. They must then be evaluated against other competing claims on resources, including fixes and other ongoing maintenance that IT has in mind.
At Red Hat, regional admins are the first point of call for resolving issues surfaced by PSA users. Some issues turn out to be simple fixes, training issues or business process questions that are dealt with locally. Others become feature requests that go forward for review by a body called the Prioritization Council, which takes a business view on what areas make most sense to progress, explains Kathlyn Williams, Product Owner, PSA:
We have monthly meetings with our Prioritization Council. We've moved to a theme approach so that [for each meeting] we're talking about a specific topic. It makes it easier for everybody to focus on what we're trying to achieve. It makes it that our regions aren't just pushing what they want. They all have to agree that it's a priority for the business.
It also helps our developer team and our QA team so that they can focus on one thing at a time and get more done on the whole sprint forward, and that makes a difference.
4. Badger your vendor customer success contact
The vendor CSM is an invaluable resource for getting help with issues or finding out what features may be in the pipeline in future releases, says Gold:
If you aren't in constant communication with your CSM, shame on you, because that's what they're there for. Keep in touch with them, keep a pulse on what's coming, and sharing your pain points. Whatever it happens to be, I go to my CSM, [and they'll say], 'Let me have you talk to so-and-so on product. Let me get you in touch with so-and-so in professional services. That goes a long way to helping to communicate back to our user community on what's next in the queue.
5. Don't hold back from asking for new features
HPE has quarterly meetings with the FinancialForce PSA product team and even maintains a feature wishlist with them on a shared spreadsheet. This has led to certain features being delivered in the product, says Gold:
We've developed a simple shared Excel document where we are tracking what we consider some very key capabilities that maybe we could develop internally, but it just seems generic enough that why wouldn't FinancialForce consider it for their own product program? We get quarterly with their product team and as a result, we have actually influenced the roadmap on three timecard requirements.
Granted it was a long journey, it actually took well over a year to get to that point.
But it is just a good feeling to know that we have that partnership, that engagement, that commitment from our FinancialForce team to deliver on what we feel is important. Also that they can share in what the customer wants, not necessarily what they think we want. It says that they are interested in making this very customer-centric in terms of what we want to see happen.
6. Know what's on the vendor roadmap
One of the most significant wins from that close relationship with the CSM is the forward intelligence it provides on the vendor's development roadmap, says Jay Shah, Senior Manager of the AWS CRM Program at Amazon Web Services:
There's tremendous value in defining and reviewing your roadmap with the vendor. We have our internal organizational priorities, we have a vision in terms of where we want to go, but a lot of times, we need to make sure that we're level-setting, [that] we're having realistic expectations.
Then there's going to be instances where we may be exploring a capability that may entail custom development, but when we do have the actual roadmap review with [the vendor], we can say that's actually forthcoming in six months or a year out ... It helps us align on priorities.
Once we've had the conversation, we may need to revisit our internal roadmap, based on what's forthcoming in the product, what does the timeline look like. Then also stack ranking each one of the things that we're trying to do, what is actually feasible with the time and resources that are available, and so forth.
7. Set realistic expectations with users
As part of the dialog with users, it's essential to be realistic about what can and can't be delivered, says Shah:
One of the other very important items is setting realistic expectations. This is super important because it enables you to earn trust with your internal constituents as we start to deliver against roadmap. Not only do you have a plan in place, but you start delivering against it. As you're doing this activity year over year, you're earning that trust.
8. Build an internal network of user champions
At Red Hat, communications are channeled through a network of 'champions' who play an important role when rolling out new features, says Williams:
The champion structure is basically comprised of SMEs [subject matter experts] — power users on the platform as well as process experts in their respective areas.
They're providing us feedback that, here's what's working, what's not working. Then conversely, as our team is working with new enhancements that we're releasing into the field, we can use them to cascade information.
[We use them] to cascade enhancements that might be geo-specific, and also utilize potentially a train-the-trainer approach, because there may be nuances in some of our markets or geos that they may want to customize or tailor the messaging.
My take
This discussion gives an invaluable insight into some of the elaborate mechanisms that are evolving to manage the new continuous delivery model of SaaS and other connected digital products. This connection enables a virtuous cycle of customer engagement, monitoring of their usage, and consequent ongoing improvement of the product or service, at the heart of what at diginomica we call the XaaS Effect.
Many businesses, both customers and vendors, underestimate how far-reaching these changes are in comparison to the old product-centric ways of doing business. Buyers need to put in place new processes to help them realize full benefit from a product that continues to evolve iteratively over time. Suppliers must re-orient their product development and delivery to engage much more proactively with customer needs. This is the emerging new reality of the XaaS economy.