Part 2 of The Seven Day Blogging Challenge - Answer one question I think people visiting my blog may have.
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.
Update: 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….
No comments:
Post a Comment