Blog Entry

(View Disclaimer)

In my last blog I promised to outline how we deal with Enhancement Requests that get submitted. The subject is a little broader and delves into what a Product Manager is, and the decision making process that we go through. I am currently at the Open Horizons EMEA Summit in Vienna, and it is events like this that remind me that most people don’t really know what a PM does. As a PM I can also tell you that it is one of the hardest jobs to describe easily. To boil down to a single sentence a PM “designs software”, but that does not do it justice, nor is it accurate, because a PM generally does not actually design the user interface.

The more long winded explanation is that a PM defines strategic product direction, based on market trends, customer input, partner needs and other factors. A PM also helps define marketing messages, product positioning, sales enablement and competitive analysis. In fact, as a PM, I work with almost every other facet of the Novell business. So what does this have to do with how we handle enhancement requests? What I am trying to show is that the factors that can influence the decision I make on individual enhancement requests are much broader than the merits of the request alone.

What happens to Enhancement Requests when they get submitted? I can only talk to what happens to the products that I am responsible for, but they do not disappear into some galactic black hole. Novell has recently been rolling out a new system for dealing with the requests, though it is still available at the old URL http://support.novell.com/enhancement, as well as at http://www.novell.com/rms. I get an email for every request submitted, and I have a Home View panel that filters my mailbox to show me any new ones that I have received – so I see the high level details of every request within minutes of it being submitted.

Once I have seen the request I generally do one of 4 things with it almost immediately.
1. If I know that this is a duplicate of another request I close the new one and mark it as a duplicate of the original.
2. If I see no value to the request, or I see value but the opportunity cost is too high, then I will just close it.
3. If I see value to the request, and it fits in with much of the feedback received on all of the other channels then I will assign it to be considered for a release
4. Finally I can choose to do nothing with it right now. This final one allows me to bear it in mind and use it for consideration on future requests.

Part of the goal of this new system is to be a closed loop reporting mechanism. As I change the status of the request the customer who submitted it is able to see the status, though maybe not all of the detail. This is probably the single strongest feature of this new system, as it allows customers additional insight that they didn't have before. There are various other features that enhance the experience for customers, such as feature voting, communication channels and design reviews.

To add some additional flavor to the discussion, as a PM I am not always in “product design” mode. GroupWise is developed using the Waterfall development methodology. This means that we define what the features are for the product, and then spend the next 12-24 months developing the product based on those features. This means that we have already defined what the “Windermere” release of GroupWise looks like, and we will not starting really nailing down all of the granular features for the “Monterrey” release for another year – in the interim I am involved in all of those other tasks that I touched on above, so the process is very cyclic. Right now there are around 5000 product enhancement requests for GroupWise alone so we clearly cannot implement them all – some are even mutually exclusive. This means that I have to make a decision, based on balancing all of those inputs, for every single request. I covered some of this in the comments on my last blog entry, but I hope that this sheds some light on what can seem a very nebulous process from the outside.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.