A Hard Lesson Learned
I’ve been in software selling roles for 30 years now. In that time I’ve run many pre-sales engineering organizations. All software is going to have some warts. A feature may sound good on the surface but have some very real limitations in practice. Other times the software might depend on another library (like open source) that purports to provide functionality but this has never been tested end to end. I’m sure there are other examples.
Software sales depend on two complimentary pillars (at least from a product standpoint). Does the software have features that are relevant to the customer and is the presenter credible. It’s like multiplying the two numbers together determines the strength of the presentation. If I say that the software has amazing features but I come across as not credible (perhaps unrealistic implementation claims) then my presentation will not be as effective. At all times I must be credible to the customer. If the software has a limitation I must concede it (assuming it's relevant to the customer) and hopefully I have pre-thought of workarounds. Without credibility I can’t have a good presentation/demo to the customer. Thankfully this is also the ethical approach. I’ve taken this approach to heart so much that I’ve often explained it this way, “Knowing what I know as the vendor, if I was in the client’s shoes would I buy the software?”
A true story
Years ago I worked on an RFP from an existing client. The RFP was a slam dunk for us. The requirements were well within our wheelhouse and we had the right products to use for the implementation. On top of it all this was a large deal ~$7M in software and services. It would definitely move the needle for our company and I’m sure our senior management would be very happy.
The client wanted an onsite meeting to review the RFP answers. I sent one of my very best engineers to run the meeting who also happened to live in the area. I had little worry about the meeting, we were set up well, we were practiced and all prepared. I felt like this deal was ours to lose.
The meeting happened on the appointed day and I tried not to obsess over it. The engineer assigned was very good and she could handle anything. My engineer called me during lunch break; the meeting was not going well and was ending early. My engineer then explained something to me that none of us knew.
Apparently some years ago my company had sold a piece of software to this same client. I’d heard of this software but my team didn’t demo it or really know much about it. I didn’t want my team to waste any time on this other software product. In the marketplace there were well entrenched competitors who could do this functionality far better than us; plus it wasn’t core to our business it was way off to the side. I didn’t see the point of bashing my team's head on a brick wall.
Well in the heat of the fiscal year sales cycle some years past, somebody sold this software to the client. Apparently we gave the client an attractive deal on this software to help us make our numbers. The problems started right away. Our business had little expertise on how the product worked and what it could do well or not. The implementation was a disaster and, as far as I know, it never came close to expectations. Obviously the client remembered all of this during the RFP meeting and stated to my engineer, “we don’t think you know how to write software.”
We tried and tried to get the customer to change their mind but there was no convincing them. As a team we were devastated. We had put in substantial effort in the RFP and prep work, we were well aligned to win the business and then this happened.
From this lesson I learned a couple of things. I already knew that credibility is important to the presenter but it’s also important for the company. With regards to a portfolio of software products to sell, the company needs to decide if it’s in or out. Don’t half support (or less) a product hoping that some client will come along and buy it. The chance of this incremental revenue can also burn some serious bridges. Plus your sales team will not be invested to demo/sell the product, your implementation team won’t know how to deliver it. With regards to selling individual software products, companies need to be all in on a product or all out; anything in between is wasting time and leaving you at risk of losing the even bigger deals. This lesson hurt but I never forgot it all these many years later.
Please reach out to peter.j.accorti@gmail.com if you want to discuss these kinds of issues.
