Ten Tactics To Do The Impossible

by nils  - September 25, 2013

Routes de l’impossible Pérou (CC 2.0 license, some rights reserved, by Attraction Voyages Pérou & Bolivie)

It’s easy to be a product manager if your backlog only contains features your team has the capacity to deliver. But what 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. This happened to me recently. During 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, that were already all in our backlog, but uncommitted. They said we’d need those five features in order to win. We had capacity to do one, maybe two, in the short term. How could we handle this situation?

There were ten (OK, eleven) tactics that we used to prepare a response.

  1. 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.
  2. Look for synergies between the features that allow you to do two for the price of one (or one and a half).
  3. 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.
  4. 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 – their original requests will end up not as important as they originally thought.
  5. 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.
  6. Get another customer as a sponsor for one or more of the features, to enable you to put more resources on it.
  7. Investigate whether delivering partial versions of one or two of features will get you enough credit to win the deal.
  8. Convince the customer that one of more of the features is actually NOT important to their success, usually due to some other capability in the product.
  9. Sometimes you have to tell the customer that you will never commit to, or even consider implementing, one or more of the requested features – if it just doesn’t make sense for your product and value proposition.
  10. Consider if there is a staging of the features that makes sense, where you wouldn’t want to deliver the later one until the earlier one was done anyway.
  11. Create a Services engagement to do some of the new features manually, rather than automating them. This can especially help if a feature is really part of a change management process and you are confident that the desired feature will not really be important once the customers starts using your product.

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.

bonus

Get the free guide just for you!

Free

Product Management Rule of Thumb: Revenue To Developer Ratio Should be About One-to-One

nils

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.

  • 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?

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    You may be interested in

    >