Nando’s customer focus

May 16th, 2009 · Rahul Dighe · Customer Research No comments - Tags:
Nandos Customer Feedback
Nandos Customer Feedback

Nandos Customer Feedback

Restaurant reviews are not new. However, I found a very interesting example that takes it up a notch. While visiting Nando’s website to look at their menu,  I chanced up their implementation to collect customer feedback for individual items within a menu. I haven’t seen many restaurants providing such opportunity for their customers to leave feedback. Given that most restaurants have menus that one can look up online, this seems a logical next step.  It would be interesting to see if restaurants and other food establishments pick up on these over the next few years.

When studying for my MBA at Oxford, I did think about a website where one could do exactly the same for local takeaways and other restaurants. However, the logistical issue surrounding gathering menu information proved a hindrance. However, as more restaurants go online, it would be possible to scrap information off their website and build such a website. Imagine being able to search for which restaurant has had the more favourable comments for a dish that you devour or being able to look up a restaurant and find out the most popular dish on the menu. I for one am certainly watching how this space develops.

Continue reading »

Qualitative & Quantiative Research – Example

May 10th, 2009 · Rahul Dighe · Customer Research No comments - Tags: , ,

Research Example

To demonstrate how quantitative and qualitative research can go hand in hand let us consider the problem. Based on quantitative data you realize that email functionality within your product is being seldom used. Such quantiative data could come from usage analysis of the website or online poll that marketing conducted on your website in which “email” ranked as the least useful feature.

A quantiative research in this case only takes you so far as to appreciate that some features of your product is less used than others. From a business perspective, it is in the companies interest that users use the “email” functionality, as it helps spread the word about your excellent content which in turn might attract new users to the product.

The next logical step is to start the process of  qualitative research. First step is to identify customers who fit your profile of ones who would are more likely to use the “email” functionality. This could take the form of groups of users who used to use it before but have stopped doing so or it could be ones who use it very infrequently. The users you choose to visit would depend on the the personas that you have identified. By visiting customers and observing them  you might learn.

  1. Customer tend to copy paste the link and send it through their own email systems as that way they can have a conversation with the person they are sending email too.
  2. Your product forces the receiver to have an account before they can see the emailed link.
  3. Customers complain that email delivery is not instantaneous and the receiver is unsure who has emailed him/her
  4. …

Based on your learnings you would then be in a position to form a hypothesis -  “if the product has a reliable email delivery system and the receiver doesn’t have to sign up there is a good chance that users might find the ‘email’ functionality more useful”.  The next step is to test the hypothesis – through quantitative research. For some products it might mean  quickly changing the functionality and through usage statistics identifying if there is an uptick in use. For others where change is difficult or risk too great it might be a case of using a quantiative research technique such as survey to appreciate the potential benefit.

In conclusion, Quantitative research that is not informed by insightful qualitative research may end up being precise but lacking in customer insight. On the other hand, customer insights that are not validated with quantitative research may end up being interesting but not representative of mainstream customers”[1]

“Qualitative research provides the eyes but quantiative research provides the legs of validation”.

[1] : Source: Insights into Customer Insights, Mohan Sawhney

Continue reading »

Difference between Qualitative and Quantitative Research

May 10th, 2009 · Rahul Dighe · Customer Research No comments - Tags: , , , ,

The best way to appreciate difference between Quantitative and Qualitative research approaches is to contrast them.

Quantiative Research

Qualitative Research
Also Known As positivist/hypotetico-deductive interpretative/responsive
Type of Reasoning (usually) deductive (usually) inductive
Objective Validate insights by testing hypotheses Generate insights that lead to hypothesses
Outcomes Accept or reject a proposed theory, or get specific answers to well-defined questions. Illuminate a situation to create deeper understanding and insights
Methods Quantiative, rigorous Qualitative,eclectic
Approach to Validity truth seen as objective and universal truth seen as subjective and socially constructed
Source – Mohan Sawhney , Catherine Dolan

The key point to note when undertaking Customer Research to build/improve new/existing product is that: it isn’t simply a choice between choosing either a Qualitative and Quantitative approach. As Mohan Sawhney rightly puts it

Qualitative research and quantiative research need to go hand in hand for true customer understanding. Qualitative research generates insights, while quantitative research validates insights. You need both research traditions, and in the right sequence

Continue reading »

Bloated products

May 9th, 2009 · Rahul Dighe · Product Features No comments
Feature Creep

Feature Creep

For a Product Manager receiving regular customer feedback is crucial and is integral to the good product development process. However, it is essential that each request be evaluated on merit as opposed to it being based on how soon we can get the guys in IT to implement it.

The rigor applied to deciding if a feature, which takes 2 weeks to implement should be no different to one that takes 2 days or 2 hours.

A simple and effective way to literally “push-back” on features is simply to ask details about the customers asking for them. It isn’t unusual to find statements “Many customers are asking for it”, “I have had many customers ask for it within the last 6 months” to be exaggerated. It is often the result of comment received in the last meeting + ones personal preference.  The simple fact is that a business case cannot be based on anecdotal evidence.

Although, there is a danger in “pushing back” and being branded as unresponsive and forever stuck in analysis. It is important to note that its an effective way to stop your product from being bloated with too many features. From a efficiency/usability perspective too many features are just as bad as too few features.

Continue reading »

So whats the Problem ?

April 13th, 2009 · Rahul Dighe · Product Design No comments - Tags: ,
Whats the Problem

What's the Problem

I don’t seem to get enough of  “so what’s the problem?”

I was in a discussion with a web designer recently who was showing me the designs for one of the products he was working on. Apparently, the users were not aware that there was a section in the product in which they could download ready made reports. The sales group thought that the current product design wasn’t helping the users to get to the reports that they sought.

Fair enough, I thought -  “Users can’t get to the reports they are looking for”….and waited… er…. is there a discussion on how the users look up a report, any use cases, any preferred mode by which user accesses the reports. No not really – is the answer I get.. Thats all that the brief said.. and the sales like the new design. I can’t stop myself for asking so how and what did you design for if you didn’t actually know about the users and the challenges they face in retrieving the reports. Furthermore, how would anyone test the efficacy of the solution if there is really no measurable test that can be defined for it.

If the problem perhaps, was such that 5 times out of 10 when users search for a report they get a message “report not found” and hence cannot get to the reports they are looking for. At the very least, we could test it with the same set of search inputs and verify if the number is any different or the results “better” or design the products to give helpful hints on searching if no reports are found. In the absence of such crisply defined problem there was really no objective way to evaluate a solution.

In all fairness, the solution did look “better” than what they currently had but that was just my personal opinion. A proposed product design needs an objective way of proving that it  meets the needs of the user. However, to do so one needs to have a deeper understanding of the problem. I see the statement “Users cannot find the reports” as the conclusion, the often difficult bit is – Why is it that they cannot find the Report?  – The answer’s to this question will help define the problem ! .. So there we go again – Whats the Problem?

Continue reading »