Subscribe by Email


Showing posts with label Facebook. Show all posts
Showing posts with label Facebook. Show all posts

Sunday, July 14, 2013

Checking for updates on social networking sites, and deciding whether to go ahead with them or not ..

Around 15 years back, the ease of getting user feedback on a software product was not easy, even for the large ones such as MS Office, Adobe Acrobat, or Photoshop. The principle way of getting this feedback was through the tech support route where users would call up tech support or deal with the support through email, primarily to provide some sort of complaint in a feature or look for some sort of health. Through this process, the support team could also get some sort of feedback on the product and the performance of the product with respect to the needs of the users. As for forums such as social networking, there was hardly anything that was available.
However, if you look at the current day situation, the forums where users can report problems (or more rarely, come out in praise of a product) are widespread. There are user forums, there are Facebook pages, there are email discussion groups, there are Twitter accounts that are used by users for reporting their feedback. When you consider a large product such as the ones in the first paragraph, the number of such forums and comments within them can be awfully large. Even for a team that puts in dedicated attention to looking, consolidating such feedback and respond to feedback that may not be so positive, it can be hard to catch up and respond to such feedback.
And therein lies the danger. When there is feedback and yet no reaction from somebody from the product team, it can seem odd, and lead to complaints that the organization and the product team do not care about user feedback, and so on, leading to something that is negative in terms of perception. Does this mean that you should put in a lot of effort on monitoring and responding to such kind of feedback ? Well, it sounds good, but monitoring and responding to feedback across different social networking forum can be pretty difficult and time consuming, and you might not have enough resources dedicated for this work (and resources with some amount of expertise in such new generation forums can be expensive, since it is not just monitoring, but actually feeding them into a system that lets the team figure out responses and strategies).
The idea situation would be where you have a broad user base that takes on most of the work of responding to such feedback. If you take Photoshop, complaints and criticism from users are many times responded to by other users, which also has a high ring of authenticity to the responses, and shows the commitment of members of the user base. In that sense, a committed user base is worth a large amount of effort and money.
However, there does need to be effort put in for building up such a committed user base. The team needs to be prompt in responding to issues that are gathering track (it would be very difficult, if not impossible, to respond to each and every issue) and show some quick responses. The team also needs to make the users feel that the product and support teams are responsible and geared towards the needs and concerns of the users (this may seem subjective, but it is necessary for this kind of feeling to be generated, as projecting such a feeling through actions inspires confidence in the team from the user community and every satisfied user can then become another committed member of the user community).
Other actions would be for the product to have its own specific Facebook page and Twitter account, maintained by somebody who has an appetite for the kind of enthusiasm and social skills that are required for social networking (if there are no tweets for many days or no Facebook updates, it tends to put off users and also seems to show the product and organization in a poor light). Further, members of the product team who are more well know can also have their own social profiles and send out updates of their own, and these also help.


Wednesday, April 24, 2013

Learning about external dependencies - getting information from external teams by getting on their lists

We had a huge problem around the start of the year. Our product is a greeting card application, which allows you to take your images or some standard images, add text or standard greetings, add voice which can be customized or taken from some standard greetings, and then you can convert this into a rich content greeting card that can be sent via email or via social networking. For integrating with social networking, we used the API's that were publicly made available by these platforms. We were not big enough that we could establish a direct contact with the social networking platforms, so we would just use these API's.
Near the beginning of the year, we started getting customer complaints that the product would just not work with a particular social networking site. They would try to use the product to send it, and they would get back an error that was basically saying something like: "Resource not found". This was reported on the user forums that we had for our product and once one person reported such a problem, others were able to confirm. This was good since it confirmed that it was not just a problem with one user, but also meant that people who were not using that particular feature also started feeling unhappy.
However, what really caused us a lot of problems was when one of our more technically oriented users pointed out that this could be because one of the API's that we were using was no longer in existence, it had replaced by another such API. And even worse, the user pasted the relevant notice from their technical forum where it was mentioned, pointed out the tweet where it has been pointed out, and so on. All this was repeated by more users who started making fun. How we had not bothered to keep up, how our problem was affecting a product that they were using, and whether we could finally get our thumb out and do something. Boy, was it embarrassing, and the problem was, nobody had much of sympathy for us. After all, we should have been on the ball, and should have known that the API was going to be replaced. The social networking platform had been talking about that for around 6 months now, so that people had enough time to do something.
The good news was that we could replace the API without needing to make a change in the application that users had, since the API call would in turn look at a piece of code on our website, and we were able to redirect them. It slightly decreased speed by around 5 seconds, but that was acceptable rather than try to roll out a patch to all the affected users.
Another policy was set in place as a result of this. From this point onwards, any external technology that we used was tracked in a database where we also tracked the site of the technology, we tracked all their accounts (twitter, facebook, forums, email) and once every month, we had a person assigned to review these so that if there was any notice, we could something rather than finding out later. It was good that we did so, since we ran into a possibly bigger problem later, but we were prepared and handled it so well that nobody noticed any problem.


Facebook activity