Building features to close deals
A friend had come to me with this particular question the other week:
How do you manage situations where a specific “feature” is “needed” to close a short-term deal that’s worth significant revenue, but isn’t necessarily on your short-term roadmap?
Below, I’ve written about the examples I shared with him to consider when dealing with the situation.
The feature that didn’t make a difference
A few years prior, we had been in talks with a certain prospect that was interested in first doing a pilot with our product. The value of the pilot would be around what we normally charge, but if their usage were to be successful, they’d roll us out nationally, ballooning the annual contract value by 5x-10x, if not more.
They had requested a feature that was not on our immediate roadmap, but was on our long list of ideas. Without it, they claimed they wouldn’t sign on even for the pilot.
So we went ahead, spent a few weeks building and testing it out, before releasing it to all our users.
However, throughout their pilot, they had tremendously low adoption of our product from their users and after a few months, they decided to go with a competing vendor and never ended up rolling out nationally with us.
Because we hurried into the contract and didn’t take the time to properly validate the feature, we were left with a rushed feature that no one was using.
Not to mention, even though we had built the one feature the prospect had asked for, its existence didn’t impact the success of the pilot.
The feature that was “never asked for”
More recently, we had a prospect that did turn into a paying customer. During the sales process, they had asked for a particular feature. This is one that we had thought about before, so we said yes since we suspected we’d get to it eventually.
After we had built and released this feature, the customer came back to us and said they couldn’t recall ever asking for it. When I asked the sales rep who closed this deal, they were also very confused because in all of their meeting notes, this was a feature they claimed was a deal breaker.
My last example is with Zach Holman. He is a former developer at Github, who wrote how a certain prospect came to them saying they’d signed on for a huge deal (more than he was even being paid at the time) if they had made their requested changes.
Though he didn’t think the changes would take much work, it was obvious to him that GitHub didn’t want to add them to their product.
Eventually, after humming and hawing, Zach wrote back a tactful response outlining that they wouldn’t be able to accommodate these changes. Three minutes later, he received a response from the prospect:
Cool, no problem. My boss made me ask that. We’ll have a check in the mail later today.
Now you may be thinking — “surely, there’s at least one company that has said yes to a feature request and had it work out.”
The one counter-example that I’ve found and appears to have generated some success is with Mattermark. Danielle Morrill, their co-founder and CEO, wrote how they got these annoying requests that “felt like one-off opportunities that were getting in the way of our existing product roadmap.”
However, they were easily persuaded by the money and took on customers that offered to sign a $50,000 contract to build functionality further down in their roadmap. Ultimately, this would end up being hugely beneficial to their customers as well as strategic to opening up future markets.
When feature requests come from prospects or clients whose contracts depend on them, they tend to come with a sense of urgency and importance. Sales teams have goals to hit for each quarter, so as a product person, they’ll be more than delighted if you just say “yes.”
But when deals come in hot and fast, you generally don’t have enough time to fully understand the job the customer is trying to do with the feature. And as a result, as you make these quick decisions under pressure, your product’s quality is the first thing to be diluted.
Not to mention, as you’ve read about in the examples, there’s sometimes a lack of substance behind these requests. In the examples, executing, or choosing not to execute, on a particular requested feature had no impact on the long-term success of that customer or the company.
And though Danielle seems to have had luck, I’d suggest that this is far from the usual experience. Ask any product person and I’m sure they have a handful of stories of when that “feature” that was “needed” was far from necessary.
To wrap-up, the folks at Intercom have written a great analogy that I’d love to share:
Building one-off workarounds or features for important customers is the same as building temporary bridges for each driver to access their riverside home. A single, permanent solution to a problem is far more desirable rather than wasting bandwidth and resources on constantly providing your customers with a temporary patch.