Share Your Secret Moves

Just in case you haven't figured it out, the Cranky Product Manager is extraordinarily lazy for someone who works 65 hours per week. She will do whatever she can to get other people to do work for her. It's one her mad Product Management skillz -- foisting work upon others despite having little formal authority to do so.

So, in keeping with her (lack of) "character", the Cranky PM is about to do that crappiest, saddest, most pathetic of blogging moves -- she's going to ask you, the reader, to contribute and make this sad little post worth reading.

So... Audience Participation Time. 

Questions for the Cranky Product Manager's crew (and by "crew" she means all you fellow PMs):

1) What's your favorite PM breakdancing move for telling (or avoiding telling) an important customer that his favorite feature is not planned for any of the next 3 releases? 

2) What about for telling the same thing to a sales droid who claims a multi-gazillion dollar deal is going down the toilet because you don't have Feature X? (You know... Feature X.  That's the missing feature the sales droid will blame if he loses the deal.  Of course, if the droid wins the deal because it turned out the product has a superior way of accomplishing the same thing, the win will be credited to the droid's sparkling personality and superior "closing" abilibites, not the product's wicked awesome feature set.)

Comments

[Neil Henry]

The other to way to bring larger perspective to a difficult conversation (or soften them up) is to present fallen features in the context of the "date-based release". Running a date-based release is our first priority, motherhood & apple pie. We all live and die by this. You remember how hard life was before we knew how to keep to schedules...

[Eugene Cuprin]

As a PM I know that the R&D guys are bussy enough. Roadmap and good planning helps. But...
It is sad to appreciate, but sometimes there is no alternative. You have to ask sales droid to follow the link: http://lleo.aha.ru/na/en
That is a painfull move, but sometimes it is really necessary.

[Bruce McCarthy]

Stephen's got it. It's about getting underneath the feature request to the problem the customer is trying to solve.

Quickly move the conversation off the feature and on to the real problems the customer faces by asking about why they want the feature in the first place. Don't assume the salesperson or even the contact person at the customer has a clear idea of this or of what alternatives there are to solve the rot problem. Be their problem solver and the need for the feature may go away.

Sometimes, of course, they really do need the feature (or another feature you don't have). That's where you talk about workarounds.

If that doesn't work, then you just have to head for the truth. When the real and final answer is no, often what the customer really wants is:

1. An audience - they want to be heard by someone with the power to affect the roadmap.

2. The truth - too often the salesperson is too afraid to say no and will spin vague yarns about priorities and alternatives. The customer is usually relieved when you just so "no."

3. A reason - its easier to swallow a "no" when you have an idea why things are the way they are.

Customers are grown ups. They can handle it. Few sales have been lost over a single feature, but if that single feature really is the difference between a sale and no sale, you've lost the sale anyway.

[Ron Kaplan]

I have been a PM for 12 years. I think this problem happens more often than I can track. I see this as two separate problems.

1. Sales staff are not focused on solutions to problems.
2. Features have names, but these names do not translate into solutions.

Beating the "solution selling" drum is common for management. It has become cliché in high tech companies. However, sales staff believe that if they throw enough features at the customer, the customer will be satisfied enough to evaluate the product and go to the next level in the sales cycle. This process works for many products in the under 1000-seat range. As the prospective client gets larger, the compexity increases. It does not take many seats at a client's site to reach a point where some customization is required by the customer. Or is it? Often, by identifying the current manual process and the problems the customer wants to solve, we can find a way for the product or service to solve these problems. If you work with the customer to solve these problems using your product or service as the toolkit, you will be amazed by the success rate.

When customers request a feature by name, they are trying to give a solution a name. Sales staff too frequently think the name is a solution, but they do not identify the problem. Sadly, without turning the feature discussion into a problem-solving discussion, the sales person makes the sale hinge on a named feature. The path is paved, and it is difficult to recover.

At this point, the PM gets involved with the client, and the first question goes something like this, "What problem do you want feature XYZ to solve, and how do you solve this problem today?" Then, we have a second conversation. We explain how we can solve these problems today, and how we will solve them in the future. At this point, feature names mean nothing and the conversation places our product or service at a competitive advantage.

[Stephen]

I think you gotta get beyond the "feature" and get the real "benefit" the customer is looking for. Normally, this won't come from the droid - Feature lists are much easier to sell from. The "benefit" normally comes easiest from a conversation directly with the customer and from asking the 5 "whys".

Keep asking "why"...

If they stop at the first "why" with "because I just want feature X" then you're SOL. But if you can get to the root and find out WHY they want it and what they'd do with it, you can propose your mucho better solution.

Then you've got em hooked.

If they stop at the first "Why" with "because all the other products have it", you can get the droid back on side with "if we do feature X just like all the others, we're replaceable". With your whizbang implementation that accomplishes the same thing, you can lock the customer into a NEW Feature Y, that they'll bug all the competitors about from then on. And you're one step ahead.

[PM in ATL]

I guess I am the weird one, but I never have a problem saying no. No, No, NO. I am known as the No Girl - which brings great joy and bliss to the room when I say Yes.

My best friend? The Product Roadmap. I share it and share it often. This is what is in the pipeline for enhancements for the next 2 years rolling. It was agreed upon by the User Advisory Board (UAB)and is reviewed 3x per year to make sure we are still on track.

Then I can say - it's not on the roadmap - or - it is on the roadmap but it is 3 releases out. And, Mr Customer, a jury of your peers (the UAB) made those decisions.

[Another Cranky PM]

This is a tricky situation for sure, but I have a couple tricks up my sleeve. One of my favourites I'll call the "Diversion Technique". The idea here is to start out your conversation by playing up some other feature that IS in the release as a clear 'must have' for them, and so 'of course' that had to take priority and oh yeah .. [mumble mumble] that other feature they requested didn't quite make it in.

Now - if you don't have a feature you think you can sell like that, don't fear. Pull the 'security' rabbit out of your hat. This basically boils down to explaining that their feature didn't make it in because you put your priority on security enhancements (or performance or extra quality checks or some other non-functional attribute of your product) A customer will be hard pressed to argue their feature is more important than something fundamental like performance or security. The real beauty here is that those aren't features you can actually demo, they just have to take your word for it that you improved them !

Now - I'm not saying you should outright lie but you probably won't be. You know those bugs that the developer submitted themselves that were full of technical jargon ? You didn't really know what they meant but note attached to the bug report said 'already fixed - just assign to me so I can check in the code' You had some of those right ? Well those were probably something to do with security, performance or general system stability, so you're in the clear !

[bob corrigan]

Saying "no" is the hardest thing a PM has to do. . .but it is often the most important thing you have to do. You damn well better have a good reason for saying no - and you need to deliver the news yourself.

All of this talk of "coaching the sales person" and "executive sponsorship" is an excuse for your not having enough solid business justification for your decision. . .and a boss who will back you up.

You *can* turn "no" into "opportunity". You just have to add OPPRTUITY. So come loaded with those letters and be prepared to talk turkey.

Man, I do *not* miss being in the software business.

[Don]

The salesperson is almost always wrong that a deal hinges on Feature X. First, because customers don't make buying decisions on the basis of one feature, for or against you.

Second, the salesperson took the customer's requirement verbatim. I've found that coaching the sales person to facilitate a conversation with the customer about the quantitative business value of Feature X almost always leads to i) the feature wasn't that important anyway or ii) the customer has a legit need that could be solved in another way

[Lepperchraun]

Yeah you got a problem. Fortunately I don't promise anything until I really know it's going in (usually about a few weeks before GA). I find that a nice way of figuring out how important the feature is, is to ask if the customer is willing to pay for it? 95% of requests disapear at that point. If they will pay I can usually get professional services to do the work. Win win!

Sales is a bigger issue. Usually it's exec management who will side with the sales guy. Then you're f'ed. Although it amazing how resources can free up to assist on the project at that point. If it's still at the drone level I just tell them to f* off and put in an enhancement request and then ask them to prepare the business justification and prepare their detailed presentation for the product steering committee. They usually find another way to solve their problem at that point.

[Vince Wicker]

Ideas (in no apparent order)

Depending upon the degree of account control and parter eco-system (and how deep in the code or infrastrucure this feature goes), find a real honest to goodness trusted partner to spec it out and build a bolt-on for you. It has implications, I know. However the confidence of the vendor in said partner and your willingness to solve their problem could go a long way. This adds a layer of fun to feature and bug tracking but it could make the sale.

The "Business Release" approach: This is a great feature but first we need to get the basic-Barney stuff in first. "Once we stabilize, we can get this moving..." Fact is that in a sales cycle, no one has a flipping clue how to spec software. Its not until the business process is in place with your implemented solution will you have it. Can you add it? Yes. Will you add it before you get in-process use? Maybe. Will what makes sense during the dog-in-heat throes of a sales cycle make sense in the implementaion manager's first meeting when he meets the people who will really do the work? Ha.

Break it apart as a phase -- wont said droid have a revenue recognition issue if you sell something that's not released? Decouple it into pieces.

This all falls down if this "feature" is the ticket to dance... and how much of a weight this is on the probability of a close -- really not what is said obliquely in weekly sales calls.

[Ivan Chalif]

When I first became a PM, I was afraid to tell customers when their requested enhancements or bug fixes "fell out" of the release that they were promised. I would procrastinate and wait until almost the GA date then tell them that we tried to get it in, but ran out of time. That was usually a very painful call where I had to hold the phone away from my ear for extended periods of time.

Now, I try to tell customers as soon as I know that I had to re-prioritize/re-scope. This gives them advanced notice if they need to modify their schedules to accommodate (many of the customers of my current company build on top of our software, so delays on bugs/enhancements can impact what they plan to do in their own development cycle).

If they have multiple features/bugs in the affected release, I ask them to identify which are the highest priority so that I can try to get them at least some of what was committed to in the release (this doesn't always work, though).

I have found that just being forthcoming with customers is better than any dance that I could do. They are way more forgiving 5 months before the release date than they are 2 weeks before the release date.