View all the Divine Rules of Product Management here.
Law #2: On dealing with customers who can’t understand you don’t develop custom software just for them.
If a customer presents a detailed list of features, demands they be developed immediately, and then tries to extract firm commitments with specific dates for each feature, the Product Manager shall adroitly step around the trap as follows.
The Product Manager shall assure the customer s/he understands the issues by paraphrasing them back and sympathizing with the customer’s frustrations.
The Product Manager shall, in front of the customer, write the details of each issue, for posterity, inside a high-class notebook with gold gilded page edges.
The Product Manager shall frequently say phrases like:
- I can see why that’s important to you
- We’ll see what we can do
- I wish we had the resources to work on all these great ideas… which two are most important to you?
The Product Manager shall not definitively promise a feature will be developed nor its delivery date, unless the feature is already done, tested, and due for release within the next 2 weeks.
The Product Manager shall also take copious notes of the entire conversation and circulate these notes to the Product Manager’s boss and the customer’s account team, highlighting that NO PROMISES were made.
If thou does this according to THE SOFTWARE LORD’s wishes, the customer will calm down and perhaps take a less adversarial approach in the future. Even better, the Product Manager won’t get fired in 6 months for allegedly promising the customer something that can’t be delivered.
—————-
Have the Software Gods been speaking to you as well? Have any additional Divine Rules for Product Managers you wish to share? Share them in this post comments. The Cranky Product Manager will feature the best Divine Rules as posts on this blog, with appropriate link-backs to the destination of your choosing….
Also in Divine Rules of Product Management
- Divine Rules for Product Managers #1: Prepping for Engineering Meetings
- Divine Rules for Product Managers #2: On Dealing With Unreasonable Customer Demands
- Divine Rules for Product Managers #3: On Helping the Press with Product Reviews
{ 10 comments… read them below or add one }
My suggestion. Create a system where all feature requests go into a pool, that will be voted on by the broader customer base. This not only helps you prioritize according to customer needs, but also give you an out when a customers asks why their pet feature request is not high on your list.
More details on how to implement this can be found here.
http://www.pragmaticmarketing.com/publications/magazine/3/3/0505sk
Saeed
hi,
Though trivial,the link mentioned in the first line is broken.
My suggested rule : “Trust No One”.
When it comes to the product implementation the product manager must try out new features as soon as possible, even in early QA stages.
If the PM asks for a button , it is usually a link. If it should take 5 minutes, it usually takes 20 and so on.
Writing fully complete specs is nearly impossible, in many cases a short feedback mechanism is better.
PM can’t trust developers, because they see things differently.
They can’t trust QA because they never test against requirements, but against the developers design.They can’t trust support, because they don’t care about customers, they only care about tickets.
They can’t trust the customers, because they don’t know what they want :).
In short , PM can only trust the hard facts and the products itself.
Saeed – I like this idea of a “request pool” voted upon by all customers. This works fantastically in the open source world. See SugarCRM (www.sugarcrm.com) as a perfect working example. I also worked with a team where we created something similar that we called a support “cooperative” where subscribing members had voting rights to product requests.
This is also a scenario where I draw from one of my most relied upon movie quotes, “no job is too big, no fee is too big” (Ghostbusters). If the customer’s request is that far out of the reality scope for our road map, then I present the option to build custom functionality for them at a cost that covers development, and three years (or release cycles) worth of maintenance costs.
If I were working for a privately held company my primary concern would be related to the ability of my organization to profitably develop, test, deliver and support a given feature. In the case of a publicly held company, the rules are more strict because of the potential impact on my ability to recognize revenue from any business done with the customer between the time that I “commit” to a future deliverable and actually fulfiul that commitment by delivering. In my experience, finance will (if they ever hear about it) refuse to recognize revenue from a customer that has been promised anything that has not yet been delivered (or where there is any reasonable risk of the transaction being rolled back in a future quarter). One foolish verbal commitment can pennalty-box millions in revenue, potentially throwing off quarterly forecasts and making it impossible for sales reps (or anyone with a bookings/revenue-based varialble comp) to meet budget. This is a world of pain, and is usually a firing offense. I find that if I explain to my customers what the implications of my making clear commitments to future features are they are understanding, if not happy about it.
At my last plc of employ, I tried the whole “voting” concept with my customer base. Customers are a wishy washy bunch who really don’t know what they want or need. So if I tossed out “ability to process transaction using prior period’s data versus current period’s and take the lower of the two…” I couldn’t get two customers to agree on what prior period to use… So theoretically voting sounds good, but in practice, it doesn’t work. It’s our job as PMs to think strategically and help our customers see through their evolving business needs.
Lisa,
What kind of company did you previously work for where you tried the “voting” concept.
I dare say that if those customers were a “wishy washy bunch” who really didn’t “know what they want or need”, then the product couldn’t have been that important to them. In my experience, if the product delivers value and fills an important need, people have very clear opinions.
Also, when you ask people to vote for something, the answers you get depend on the questions you ask. The question you mention is an ambiguous one at best. Ask very specific questions, or get general info from the survey and follow up with a sample to get more detail as needed.
Keep in mind that surveys like that are only one source of information and need to be paired up with other data and insight collected through other means.
See this post for a bit more info on surveys.
http://ask.goodproductmanager.com/2008/12/23/how-can-a-product-manager-best-use-surveys/
Saeed
This strategy works, to a point. At times, though, you’ll still have to be blunt. The company needs to say no to the customer. However, as the person in the face of the customer, you’re not really in a position to say no without the significant risk of being hung out to dry, unless you get everyone else (sales, dev, etc.) on board first.
Ah. I can still remember the first time I heard that odious phrase “manage the client’s expectations”. And the first time I actually spoke it. Happy days, happy days.
Some good diversionary tactics there though. Will try to remember them and replace them with my standard ‘full contact management’ and ‘Dr Bat’ strategies.
How sweet it is… when the customer is a giant corporation that will never, ever, buy more than two copies of your software. No matter that other companies say “how high” when they say “jump”. I got to not jump :-)
{ 2 trackbacks }