Routes de l’impossible Pérou (CC 2.0 license, some rights reserved, by Attraction Voyages Pérou & Bolivie)
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 TweetThere were ten (OK, eleven) tactics that we used – and you can use – to have a chance of winning in this situation.
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.
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.
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.
Your host and author, Nils Davis, is a long-time product manager, consultant, trainer, and coach. He is the author of The Secret Product Manager Handbook, many blog posts, a series of video trainings on product management, and the occasional grilled pizza.
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.
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?