In previous blogs, I’ve stressed the necessity of maintaining an engagement strategy with your community of users. Many clients I have spoken with have a level of customer communication; however, it often lacks key elements that their customer base needs to know. Obviously, there’s no magic formula on what that level of communication should be, but here’s one violation I see surface the most often: communicating version updates.
Note: I’m going to assume you’ve already obtained the Trailhead badge for upgrading your AppExchange application, as this won’t be a “how to” blog.
APIs need upgrading, it’s just a fact of life. While working with one of our clients, an upgrade was made that resulted in months of work for their Salesforce application. The process also went through an exhaustive testing process before we released the product. The release went out on a Friday afternoon, and by Monday, inboxes were slammed with exception emails.
In the post-mortem, it was discovered that there was no strategy by our client to communicate the release to their users. Their rationale for no communication seemed reasonable enough – there were no new features to discuss, just cleanup and back-end changes. Their users, however, felt entirely different about that. Communicating to your community of users about a new version release is considered a common courtesy.
With that said, the following recommendations are best practices I strongly encourage you to utilize.
1. Provide Release Notes
Each of your user org’s system administrators have several other applications they are juggling within their org – in addition to a myriad of their own business operations. Play fair with them by giving them plenty of time to adjust to any upgrades to your application. In the Salesforce universe, it’s considered extremely rude to just push an upgrade without providing several weeks notice to your users. Even if you are pushing a patch out to your users, provide them with a clear understanding of what is involved and how this will affect the application.
I cannot emphasize enough that documentation to your community of users should be provided well in advance of your new version release. Your users will very likely have cloned the profiles and/or permission sets within your application. Therefore, any new objects or fields within your release will not find their way into their cloned permissions. They will need advanced notice to resolve this when the new release arrives, otherwise users in their orgs won’t be able to use your new features. Remember, permissions aren’t the only things that could be impacted within a new release.
Any customization an org has against your application can be impacted by your new release. From something as simple as custom reports, to more complex business operations involving process builders, flows, and even custom Apex triggers or batches. Therefore, provide your users with ample information about what is new in the coming release, and what has changed from the previous release.
As a general consideration to the various timetables your users could be operating within, provide at least two weeks notice of the new release with your release notes. And provide that update only after all the testing on your scheduled release is complete – including beta testing – which I’m about to discuss.
2. Leverage Beta Testers
Introducing beta testing within your community is a fantastic way of engaging with your community because it shows you have an attentive ear to their needs; which enforces the mantra that “your community has a place at the table.” The more they feel involved in the product, the more they feel a sense of ownership to your product.
Pay attention to the champions within your community and provide them an opportunity to be beta testers for future releases, prior to releasing to your overall community. Their feedback could save you not only time and money, but will also build your relationship with your users. And in the end, that’s what it’s always about.
3. Openly Communicate Your Product Road Map
If your community of users are well-informed of your product roadmap, then your release notes won’t come as too much of a surprise. Sounds obvious, but it’s an aspect of release management that seems to fall between the cracks. Your internal stakeholders are likely well-informed on the product roadmap, but often the true stakeholders (your customers) are left in the dark.
At the very least, engaging with your customers about the product roadmap of your application will help you significantly reduce your churn rate and extend the life of your customer. This is because the customer can clearly see that they have a seat at the table of application decisions. If you’re presenting it to them, and they are communicating issues, concerns, and suggestions to you, and these are finding their way onto the application’s roadmap…they have a stake in the product as well because you are listening.
Does this sound familiar? It should. It’s the model Salesforce has been leveraging for many years now. And if a company as complex and as large as Salesforce can successfully execute this, then so can you. And, more to the point, so should you, because the Salesforce community expects it.
4. Provide a Push Upgrade Window
Salesforce encourages ISV partners to push their upgrades to users within a given window, since it provides you with time to respond to issues that may arise from your new release. This means you’ve limited the exposure of said issues to that first batch of users, instead of your entire community. On the surface this is sound advice, but I find that if you leverage the beta testers within your community, you’ve pretty much already done this part.
Providing a window to your users is still a good practice in that it gives you the breathing room to manage the release in a timely manner and still address issues should they arise. It’s been my experience that when an ISV has less than 100 orgs to push to they tend to overlook this aspect. I encourage you to consider it even if you only have less than 100 orgs you are pushing to.
In the situation I mentioned earlier, there was still a possibility that even leveraging beta testers, we still could have ran into issues releasing to the community. So, sequentially releasing to your community within a given window of dates still has value.
5. Summer ’17 Enhancement to Note
You are now able to exclude orgs from your push upgrade process. In the package details section there is a place where you can enter in the org IDs (comma separated) that you’d like to be on your Push Upgrade Exclusion List. Adding an org to this list means that the next time you push an upgrade, the orgs on this list will be excluded from the operation.
Final Thoughts
In closing, note that the central tenant to the recommendations above revolves around the concept that establishing and maintaining an effective community engagement strategy for your product development will save you time and money in the long run. Community engagement is not a part of your customer support solution – though it shapes it, it should never steer customer support. Effective community engagement is also not part of your marketing solution – though, like customer support, it can play a part. Effective community engagement is firmly entrenched in the realm of product management, and will always remain there since the single greatest stakeholder will always be the end-user.
So, as you’re building out your product roadmap, add some time in there to better manage the release process by utilizing the recommendations mentioned here to ensure your release goes smoothly. Yes, you’ll have hiccups along the way – everyone does. But the more personally engaged you are with your users, the less likely those hiccups will be. And, when they do happen, your community will be far more forgiving.
