1 person found this helpful
Not sure there is a "right" answer, but a few things to consider on the con side:
- Any documentation you create with a limited feature set will need to be updated later to reflect your changes. This is in addition to whatever changes Jive makes in upcoming releases.
- You'll also end up needing to re-do training for users to bring them up to speed on things when you launch more functionality.
Maybe worth testing it out with a few employees and see what they think? Don't outright ask them if it is too overwhelming. But watch them interact and speak out loud about what they are thinking and feeling. Record what they say and take notes, and I bet you'll learn some interesting things!
Although slow and steady has some benefits, be prepared with a process and message(s) regarding the features that you have elected to disable and why (and if/when you plan to enable them). This is also true when you are on an outdated version.
People come to expect a certain feature set of this type of a platform based on their personal social media use, but if something is disabled or hasn't been installed, they may be discouraged and adoption may differ. But if you are prepared with good news "this is only the beginning, more is coming, more is possible, etc.", that can help. And Voice of the Customer - "we are listening to you" also goes a long way.
And yes, as you stated in your other post - being able to announce new things can drive some engagement or re-engagement. But that first impression is incredibly important. There are some people that unfortunately may never return if they weren't happy with what they initially experienced.
Using your example of projects (in your other post), users may ask if there is a task feature inside of Jive. It's important to not say "no, there isn't". But rather listen to their use case and discuss the value of enabling that feature - and when. And then sharing your decision with the user along with any short or long-term workarounds. (and of course, when the question of tasks comes up, I tend to push Action Items..) And if you already have a timeline of when you'll enable something, maybe share that ahead of when people might ask the question.
Ultimately, I'd suggest some user experience testing prior to your decision-making process to get some end user feedback on the features. (leave all features on initially and then based on what you observe and hear, that can influence what you disable). Also, use cases are what drive features, so as long as your features support what you expect people to use it for, then disabling some features shouldn't cause too much of a negative impact.
What other features are you considering disabling?
Thank you for your careful and considered response. I had been thinking of our current intranet as the point of comparison for the new one, but you suggest that a more valid point of comparison is the user's familiarity with social media in general. That makes sense.
I believe, though, that if someone asked for the ability to track tasks, we would simply switch it on and let 'em have it. We're agile enough that this can be done without multiple levels of management approval. I think the only other feature I would delay is Polling.