Failure To Deliver Is Not An Option

But sometimes, it happens anyway.

The Cranky PM started a great thread of conversation asking how product managers deal with the job of telling customers (and sales folks) that a feature is not going to be available in the promised release.

CPMs Question

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?

Cranky PM, in Share Your Secret Moves

Several Answers

The readers of that article really stepped up with nine responses. Check out CPM’s article for the details – but here is a summary of the answers. Some of these are bad ideas, and some are good. Usually, the bad ones were written as “I used to…” Our thoughts about each are also included in the list.

• [Bad] Wait until the last minute, then deliver the bad news. We agree – about the only way to lose credibility faster would be to not admit the feature was missing until after the release, when the customer calls to ask.
• [Good] Tell the customer that the scope and priorities have been updated, as soon as the decision has been made. This builds on, or at least sustains a cooperative trust-based relationship.
• [Other] When a customer has multiple features slated for a release, ask them to prioritize them, and try and include them in priority order. This should be happening anyway, before finalizing the schedule – but if it hasn’t already happened, it definitely should happen when the realization occurs.
• [Other] Think outside the box – outsource to get the to-be-missed features included anyway. Deal with the integration hassles internally. This can be good or bad, depending on both your team and the partner.
• [Bad] Re-characterize the release as a “get the basics in place” release, explaining that the to-be-missed features need to come after the basics. There is some validity to the logic behind this (that you can’t really know what you need in detail until you start using the application). But to suddenly discover this after having already committed to a schedule is not good.
• [Good] Restructure the release schedule and add a “next” release to include the to-be-missed features. This is one of the tactics we identify when over-filling a time box.
• [Good] Don’t make promises you aren’t sure you can keep. This is a preventative solution – set expectations appropriately, don’t make promises of content until you near the release. If you’re using iterative development, for example, you might be creating a build every month. You may only be releasing once a quarter to your customer. If you are using continuous integration, and testing effectively, you know you can avoid regression bugs – so you know you can release all of the features from the previous interim builds. Let the customer know that those features have been completed. You’re reducing (perceived) risk for the customer – only the last (and ideally, lowest value) features are still undecided.
• [Funny] If the feature is for sales bigwigs, you’re fired. If the sales person has less clout, make them follow procedure (justify the business value and document it, etc…).
• [Good] Challenge the premise that a sale is dependent upon feature X. Push back on or work with the sales folks to identify the true requirements – not the proposed solution. From what I’ve seen of enterprise software, sales are made based on relationships, not features – and not even price.
• [Other] Distract the customer by emphasizing all of the stuff that is important to them that will be in the release. Softens the blow. Done well, this can really work. If you are implementing the most important stuff (to the market) first, the odds are that it is also the most important to this customer. And by the reverse, the better aligned this customer is to your market, the less effort you are spending on “one-off” customizations. So this redirection technique, when you’re doing everything else right, could also be classified as “put it in perspective for the customer.” When you do that – this is definitely good. If, on the other hand, your priorities are messed up, this can be a bad thing.
• [Bad] Make the excuse that the feature slipped because of “security enhancements” (or other ‘sounds more important’) taking priority at the last minute. If this is true, then this is just an example of ‘more important stuff is slipping’ – if it is false, it is lying. Again – the ‘rabbit out of a hat’ thing should not happen in a positive relationship. Maybe this is an ethical gray area for some folks, but we choose not to take this approach.
• [Good] Share the product road map regularly with customers. Use the road map as an artifact to set delivery expectations. That practice is a good one, and is effective in working with sales droids. It doesn’t help with to-be-missed features, however.
• [Good] De-value the feature request and focus on the benefit request. Another good one for the feature-X request. Work with sales to identify the reason why behind the feature. Then incorporate a solution into the product plan.

Really some great answers. How do we mix these into a recipe for success?

Success Recipe

Unfortunately, fire-fighting seems to get more attention than fire-prevention. We tend to get rewarded more for fixing problems than preventing them. This of course leads us to get better at extinguishing fires than avoiding them. But a good software product success strategy is built on fire-prevention, with some contingency plans.

Do the following to prevent problems:

• Prioritize goals (aka needs or problems) based on market value. This is the strategic, multi-customer view of your product.
• Communicate release schedules based on the use cases that enable your customers to achieve those goals. Note that you may be scheduling improving versions of the same use case.
• Share that schedule with your customers. Since you should be continuously refining this plan, you should also be continuously sharing it. Use this road map in discussions with sales folks.
• Make sure that the release dates are not arbitrary. If you’re releasing regularly (monthly, for example) – this is less of an issue.
• Establish expectations that your sales-support activities are market-focused, multi-customer activities.
• When a sales person approaches you with feature X, work to uncover problem X and then assess and prioritize it for the market relative to everything else. There are limits to how quickly you can include it in the development schedule without being disruptive. If you need to be disruptive, make sure it is justified.

And when you do have to slip something from the current release:

• Let the customer(s) who are really dependent upon it know as soon as you suspect.
• Keep them appraised as you make progress (or lose ground). Think of the status report you might give to your manager about a project’s status. Well, you really work for the customers, right? Let them know.
• Put things in context. When you slip something, it better be the lowest priority item. And if your customer’s individual needs are aligned with the overall market needs, this is easier to deal with. When the customer does not represent the market, you have to determine what expenses you are willing to absorb to service the customer. Not every sale is a good one – especially if one customer detracts from your ability to sell to multiple customers, or pulls you away from your strategy.

Another form of slippage is when you re-prioritize future features. Now you’re saying “here are the changes to the roadmap.” The same tell people right away, focus on strategic value, and put things in context ideas still work the best here.