How Are Product Management Decisions Made? Guest Blog by Mike Lazarus

[#1]

How Are Product Management Decisions Made?

by Mike Lazarus

Recently I have been trying to explain to users in a couple of forums why the feature they want might not be likely to make it into the product. For a couple of examples of this, see:

• "ACT! for MAC" on the LinkedIN ACT! Fanatics Group
• "Merge - Combine - Copy Opportunities" on the Sage ACT! Community Site

So I thought I might try and explain simply how I see the product management decision process. However, please note that I’m not actually privy to the process used by Sage (or any other company other than my own) and am only going by the experiences of what I’ve seen and heard. Members of the Sage team have confirmed that “this is directionally close” to the process as used.

First, all the requests are split into two areas:

• Bug Fixes and improvements – defects where the product does not perform as designed or intended as well as compatibility with other new systems and usability
• New Features and Enhancements – functional improvements to the actual design of the product

For each of these, a priority must be allocated. The priority would depend on a number of factors:

• How many users would be affected by the bug or benefitted from the enhancement
• If it’s a bug, it is data damaging or prevents the use of a primary function of the product
• Also for bugs, can the issue be replicated in-house to determine the cause
• For enhancements, would it just be a nice-to-have for current users or would it sell more product by being part of the decision making points of potential users
• Is there a competitive need for the request – are other products in the market doing it
• Are there manual workarounds or third-party products that could deal with the request now
• How will the request integrate or interfere with current code and user interface design
• How they fit into market trends/visions that they want to focus on
• Usability and compatibility with adjacent products

Then, for each, a time-frame and cost must be determined. For this, a specification document must be created with much thought being given to looking at all the possible scenarios, data types and values that are considered likely. This is done by consulting users and developers for their input.

Finally they can decide which to approve now, delay for a future version or discard. Obviously, the higher the priority, the higher the allowable cost would be for it to be approved.

So, in order to have the best chance of getting your requests addressed, you should try and put it in terms to answer as many of the points mentioned.

I would write more, but the challenge limits us to 400 words….

[#2]

As always Mike, thanks for your contribution and insight.

[#3]

Mike, there needs to be a new category besides 1)Bug Fixes and 2)New Features.  It needs to be called "Things that worked for years and we've broken them."  But there probably only needs to be one priority: "Our users are mad and getting madder with each new thing we break - we broke it in minutes, let's not take years to correct it."

[#4]

I agree, Kevin ... but those should be considered to the bug fixes.

I think one issue with the annual upgrade cycle is that there is a financial need to have some "New Features" added each year that takes away from the dev/QA resources that should (IMHO) be directed to these bug fixes.

Regards,
Mike Lazarus
ACT! Evangelist
GL Computing, Australia
http://Blog.GLComputing.com.au
http://twitter.com/GLComputing

GL Computing Facebook Page - http://www.facebook.com/GLComputing
LinkedIN ACT! Fanatics Group - http://www.linkedin.com/groups?gid=49896

[#5]

I agree with both of your comments.  Annual Releases are the root of all (ACT!) evil.

[#6]

Many of Sage's problems with ACT! come from the fact that, at heart, sage is an ERP firm ... annual releases and artificially enforced rationalization work in that industry. But they are both a hindrance in the CRM world.

Releases should be done according to dev/QA cycle, not to a marketing and financial analysis schedule

Regards,
Mike Lazarus
ACT! Evangelist
GL Computing, Australia
http://Blog.GLComputing.com.au
http://twitter.com/GLComputing

GL Computing Facebook Page - http://www.facebook.com/GLComputing
LinkedIN ACT! Fanatics Group - http://www.linkedin.com/groups?gid=49896