We were in a sales engagement for what would have been our largest or second largest ever deal (very big!). The prospect told us we were losing the deal because of five specific features – all large, all valuable, all useful to many of our other customers. These features were even already all in our backlog, but uncommitted!
The prospect assured us we’d need those five features to win. We had capacity to deliver one, maybe two, in the short term. How could we handle this situation?
Of course, it’s easy to be a product manager if your backlog only contains features your team has the capacity to deliver.
But if you have five large must-have features but your team only has capacity to do one or two?
This is where PM becomes an art, rather than a science.
They said we'd need those five features to win. We had capacity to deliver one, maybe two, in the short term. How could we handle this situation? Ten Tactics To Do The Impossible Click To Tweet10 Tactics
There were ten (OK, eleven) tactics that we used – and you can use – to have a chance of winning in this situation.
- Make sure you understand what the customer is asking for, because until you do enough requirement gathering at least to get realistic usage scenarios from the customer, what you think they mean might be quite different from what they actually mean.
- Look for synergies between the features that allow you to do two for the price of one (or one and a half).
- You can commit to delivering one of the features in the near term and the others later. This sometimes is good enough for them to make the commitment to buy from you, especially if they expect to get a lot of value from your product overall.
- You can commit to making the features over time and in the meantime get the customer into the product – start the onboarding process – with the expectation that their priorities will change. It’s likely their original requests end up not as important as they originally thought.
- Get the customer to fund work on one or more of the features. This can work if you have additional resources that can be added simply by buying them.
- Get another customer as a sponsor for one or more of the features, to enable you to put more resources on it.
- Investigate whether delivering partial versions of one or two of features will get you enough credit to win the deal.
- Convince the customer that one of more of the features is actually NOT important to their success. Often an existing capability in the product can take up the slack, at least for the short-term.
- Sometimes you have to tell the customer that you will never commit to, or even consider implementing, one or more of the requested features. You have to do this if it just doesn’t make sense for your product and value proposition.
- Consider if there is a staging of the features that makes sense. Maybe you wouldn’t want to deliver the later one until the earlier one was done anyway.
- Create a Services engagement to do some of the new features manually, rather than automating them. Sometimes the purpose of a feature is to ease a change management process. If you confident that the feature won’t be important once the customers starts using your product, you might be able to use Services to help with the change management.
In this case, I was confident that a combination of a few of these – in particular 3, 6, 7, and 11 would have enabled us to win the deal, and we made good progress with the prospect on making that case.
Knowing What To Do Doesn’t Always Mean You Win
Unfortunately, my company executives decided to do none of these, and to double-down on another product initiative (not mine!) that they felt was going to result in much more business. They were wrong, sadly. (We sold $0 of that product.) And the customer ended up buying from our competitor.
But, We Got A Second Chance
The postscript to this story was that the customer was not satisfied with the competitor and later came back to us to see if we’d addressed any of their issues (which of course remained important to them and to our other customers). But we’d continued the investment in the other product, and did not address any of their backlog, so we ended up losing a multi-million dollar deal twice.
There are lessons learned here, in addition to the tactics. I’ll talk about those in a future post, you can be sure.
Holy cow. I swear you must have been a peer at my last company…
LOL – wink wink!
Shit, I saw the tweet, read the post, and was going to comment something about how we must have worked at the same company, and I see that I already did.
LOL – I found that in the wayback machine and thought “still relevant!” Cleaned it up a bit, thought people might enjoy it. I noticed that you had already commented back when I originally posted it 🙂
Great tactics. That #1 is key because learning what the customer is really trying to do – what they really *need* to meet their business goals instead of what they say they want — gives you a lot more latitude and credibility to work with the other 10.
I would also add a 12th: bring in professional services to (charge to) build what they need just for them on top of your base platform. (This is similar to #5 except that the work is owned by the customer, but at least it doesn't take away your engineering resources.)
I'll tell you a story about how I once pulled off a combination of 8 and 9. A large prospect insisted that we support our product on some obscure (and obsolete) version of a 3rd party platform. The sales rep didn't know how to say no, so they called me in. I successfully convinced the prospect of why it was not in their interest for us to support that platform.
What I said was that our ability to support their implementation depended on us having experience with the platforms we supported and the ability to reproduce their issues on our systems. We could certainly run some one-time tests to verify that our stuff ran on that platform, but we'd never be able to train our people on that platform well enough and have it set up and ready just in case they called.
If they went with one of our standard supported platforms, on the other hand, we'd be able to (and obligated to) quickly try to reproduce and address their issues. This made a lot of sense to the customer's head of IT, and the deal went through.
Just another case of using our product powers for good!
Thanks Bruce. Great story about convincing the customer that they didn't really want what they thought they wanted. Can't do it all the time, and it takes great skill, but when it works, it's very beneficial!And your #12 is an excellent addition. The last two companies I worked for didn't have those technical capabilities in the Services arm, but when you do have it, it's a powerful tool.Nils
Use open development to specify those areas on your roadmap that cannot be addressed by your developers. Then, when you need those features, use those created by your open developers. Ensure that your open developers are able to leverage your marketing efforts even before you've incorporated them into your offers. Make it make sense for others to develop your features for you. Help them get done on time to suit your future whole product offering. And, don't eat your third-party developers or steal their income stream. Make the effort make economic sense for them now, and deeply into the future.
David – I'd like to hear more about this. In our case, we were not resource-constrained, but funding constrained (i.e., my project wasn't funded). Can open development help in that situation? Also, what are the prerequisites for enabling open development. Some of these features – many – would have involved "core" changes – not only could they not have been done via API, but they would require deep knowledge of what was going on in the core. Have you had experience with open development for situations like this?