Friday, June 20, 2008

Making Product Decisions

Recently, I conducted product feedback and evaluation session, separately, with two customer groups. Both the groups had same Beta product to evaluate and worked in same department but on different projects [clients].

During the first feedback session, the group unanimously rejected a major feature suggestion / expressed indifference. They needed more time to understand the applicability of the feature. During the second feedback session, the other group found the same feature suggestion quite useful, or apparently so.

It was very interesting to note how opinions are emotionally driven and how group dynamics work. It was very easy to fall in the trap and accept the second (positive) feedback to be true immediately [without further considerations]. In fact, engineering actually started considering to stop some other development work to fix some issues in this new feature, based on just the feedback an accompanying developer had witnessed in this session.

I went back to writing my report and considered the following driving factors for the difference in reactions:

First Group
1. Had no emergency in their current project
2. Things were working just fine in their current product suite
3. There was no urgency to scale their current client requirements
4. Were a satisfied bunch!

Second Group
1. There was a gap of a week between the sessions and in between, there was a major outage in the same product suit for this group
2. There was a big frustration and they needed some immediate solution
3. The client was demanding / scalability was important
4. Needed much more than what they had to be satisfied!

When, the second group was shown some features that would solve their immediate problems, they were ecstatic. With the already set "happy mood", everything else shown next was considered to be a major improvement on what they currently have and with group dynamics in action, they went ahead expressing positive feedback for all features, including the one that was not quite accepted / understood by the first group.

It was also interesting to note that the second group found just one aspect of this new feature conclusively useful. However, the tempo of the room was such set that this fact was apparently ignored.

I found this exercise very enlightening! We just cannot make our decisions based on Enthusiasm. However, intuitive it may sound, but it is very important for the Product Managers and Decision Makers to understand not just what the evaluation results were, but also the process in which the evaluations were made.

As for this particular case, I will still want to keep the major feature on evaluation / beta and not invest in developing further. At least in product decisions, first impression is the last impression, does not hold true always! I need to validate the first reactions.

PS: These are my personal opinions and do not reflect the opinions or stand of my company.


Anonymous said...

"First impression is the last impression, does not hold true always!"

As far as I know, for product no impression ever is the last impression. I believe it is naive to make an impression itself. You come up with a set of features and deliver (even that is 99% of the time delayed). Again next round, next round and so on.

Honestly, to me the product you have mentioned looks more like a management stuff as I can not call it a product (from the article) then a software product! And no wonder techies (not from services type) with or without a management background make a good product manager than from any other. Perhaps, the respect Steve Ballmer commands (actually no respect at all!) at Microsoft, hits the nail on the head.

Chelsa said...

Keep up the good work.