User Generated Requirements - Part II
In the last post, we looked at how blogging could be used as a means of requirements elicitation for customer facing web sites. In this part of the post, we will extend the concept outlines in the first post and take a look at the specifics of how to blog for requirements.
Float an idea
The start of any new business requirement is an idea – an idea that your customers, your business analysts or you may have. For a dotcom portal, when a new idea is conceived, it could be tested in waters by floating it on the official blog. This could be accompanied by providing freedom to provide a ‘Yay!’ or ‘Naah!’ vote buttons or by letting other users comment on it using the pure blogging mechanism. It is up to the business analyst to collect comments, analyze responses to ‘Yay!’ or ‘Naah!” float new threads to clear up the topic, if it was a little ambiguous.
Facilitate a Discussion
Floating an idea is just the first step. For any good, concrete requirement to be finalized, the idea needs to be brewed for a while. During this phase, the business analysts will need to make sure that they keep adding fuel to the fire, maintain the interest and activity while collecting useful information about the requirements along the way.
In certain cases, when the requirements are a little tricky or hard to visualize, it might make sense to put a small prototype out for the users to test drive and give their comments. These prototypes could range from non functional screen shots or visual drawings to a semi functional live application which demonstrates the concept and its uses. The business analyst would again have to track the user feedback – implicit (web analytics) & explicit (blogs) and shape up the requirements accordingly.
Collect & Rationalize Feedback
The last leg of this requirements gathering exercise deals with using the collected feedback to reflect on your system. The approach could vary based on your starting position – if you were planning a new release for your system with limited budget, then you’ll need to come up with an opening moves matrix the following:
The first three columns of this matrix are self explanatory – they talk about the categorization and cost of these requirements along with their brief description. The fourth and fifth columns specify the results from your blogs. The fourth one has a factor of Yay! to Naah! ratio, which implies that for every 100 users that said AJAX requirement should be implemented, 65 said, it should not be. The last column gives an idea about how many people participated in these discussions.
How to Interpret the Matrix
The factors that will decide which requirements should land up being part of your release will be dictated by the last three columns. The requirements that have a Yay! To Naah! ratio of more than one can become candidates for being shelved; unless the ratio is marginally above one and number of votes are extremely high. Such a spread indicates a 50-50 opinion and it can be left to the business sponsor or business analyst’s discretion to can or to go ahead with such a requirement. The low Y to N ratio requirements are the ones that the customers are holding their breath for, the ones that could provide your application an edge over others. These should be considered for development right away.
Other forms of Feedback
Besides the opinion votes, other valuable feedback can also be received from the user which can be used to refine the requirements. Let’s consider the Personalization requirement in the OMM matrix above which had a price tag of $800K for instance. Your original idea of personalization might have been to provide customizable themes and skins, a stock portlet and a weather portlet. From this blogging activity you may realize that most of the users do not feel that they will come to your portal for a stock and weather portlets. They would rather go to a specialized portal for these services. However, they are interested in the themes and skins functionality.
Although this feedback does not give you a go, no-go decision; it does you provide you an opportunity of trimming down your requirements and the associated cost before a single pence was expensed in its development. This kind of feedback can be crucial to keep your costs under control and effectiveness at an all time high.
Not a silver bullet!
It is prudent to mention at this point that this approach is only applicable for your functional requirements – not the non-functional ones. I can’t imagine a dotcom portal discussing its security and availability requirements on a public blog for obvious reasons. NFRs belong to different category and are best discussed and acted upon, internally. Besides, it will be difficult for your end users to understand, relate to or contribute to these requirements.
Support Mode
For most dotcom portals, the support service is offered through a toll free telephone number or through an email. Since both of these mediums need some effort and at times - hassle, they are usually employed only by users who have a problem. They inadvertently shoo away people who may have an idea for making things better. In today’s world, it is difficult to imagine customers picking up a phone to call in with their advice. Besides, the easier option for them is to hop on to an alternate portal which offers the functionality that they need in the manner that they want.
Now, let’s see what could get the users to speak their mind and why. First, the ‘how’ part – Instead of emailing their feedback, the users can post it on a blog on the portal. This has an implicit answer to the ‘why’ part embedded in it. By giving the users a platform to voice their opinion, you are also giving them an opportunity and a medium to get a social reaction to their opinion. I could write pages about why it is important and how it has worked in the past, but it will make more sense if you look at your favorite socialization website – orkut.com, facebook.com or what have you.
So, in the new world, our support service will also take shape of a blog – where users can list their problems, support staff can reply to queries, other users can respond to issues and users can rate the responses that they get. The beauty of this approach is that besides providing the support infrastructure, this medium automatically builds a knowledge base for the users that new users can search when they have a problem, other users can update and keep it up to date. Or in other words –knowledge base of the users, by the users and for the users.
Comments
Good thoughts. I do not necessarily agree with the post, but it got me thinking anyway.
A few points.
A typical blog response is never going to be over a few hundred responses. And that too when you are looking at a blog that is wildly popular. So to get any meaningful results from a few posts might be a little bit of a stretch.
Second, assuming a public blog, I would not share the costs of implementing features in the blog post.
Third - you do not know how much weight you can apply to a particular customer's yes or no vote. That is important here, because, hey - your business is not a democracy. You need to implement only those things that are extremely important and useful to your entire set of customers and not only to a handful of customers.
Fourth - there could be areas that you cannot talk about publicly before they are released because of competitive reasons. So you cannot get feedback on that using a public blog.
Thanks
Posted by: Siddharth Sethi | October 8, 2008 09:34 PM
Thanks for taking time out to review this post, Siddharth. The idea is experimental for the most part. I have tried to address some of the concerns that you have raised in the third and final part of this post. On blog responses - it depends on how you run the blog. If you can include a very small side bar on the blog which lets readers vote, you could get a lot more responses than conventional blog comments. On the second point - the costs are not meant to be shared with the public at large and would not be published on the blog. They are for the reference of the business analyst who collects and rationalizes the responses. The idea for this table was to give an approach on how responses could be linked to features.
I absolutely agree with your third point. And that's why it's the business who gets to decide how much weight to apply to a response. In addition to this, as I have mentioned in my third post - this technique is not apt for any and all kind of requirements gathering. It should be used for a few new features that the business is not sure about.
Your last and fourth point is also addressed in my third post.
Thanks again for your comments,
Amit
Posted by: Amit Jnagal | October 21, 2008 03:53 AM