The life of a product manager is a never-ending balancing act. Balancing between competing pressures, organizations, and needs. Invariably, we are bombarded from multiple angles on what the product ‘needs‘ to be successful.
This post is to describe how NOT to submit a feature request. This is pretty much an assumption that the request comes from sales.
First, if it is tied to a single sales opportunity, it is likely to get filed and forgotten. Don’t try to sneak it in as a “really great idea”. Honestly, we are pretty good at determining if a feature has broad applicability. Unless the customer is a lynchpin in our strategy to enter a new market, or is such a large customer, we wouldn’t say ‘no‘ anyway, just don’t bring it up.
Second, make your request really vague. Assume that we either know what the customer was talking about, or that we intuitively know what is being requested. One recent feature request came to me as:
Track administrator edits of:
Routing codes
Routing tables
Coversheets
Access Changes
Literally, no more description than that. Immediate questions I had were:
How to log this? In the administration log? In the user history (and presume we track the transactions in the system database)? Track it globally?
For the routing changes, again, associated with each user, or track all the changes done on users by an Administrator?
You get the hint. There are many ways to skin this cat, and if you can’t be bothered to find out some more details, I am going to prioritize this to Dante’s third ring of hell. If I have to do significant legwork, AND I don’t understand what you are looking for, straight to the round file.
Third, try to exaggerate how many more sales you are going to get for this. It is bad enough that the original sales case was a small system sale. But trying to tell me how this will lead to tens of system sales because this one change opens the door. I have a story of a special certification (think like CE) that we did 4 years ago. About $50K of consulting time, uncountable hours of Development time (5 hotfixes, a special SDK, and some significant documentation) that lead to exactly $0 of follow on orders.
Summary
There is a reason why internally generated requests for features get prioritized down. Product managers are constantly validating the inbound requests, and requirements with real customers. Sadly, sales and sales engineering have a very limited horizon. The most important feature is what is a stumbling block in their current sales scenario, or the one feature that caused the last “remembered” lost order.
Don’t be surprised if product management is less than enthusiastic about your “must have” enhancement.
(originally written in 2011)
