The cost of saying "yes" to feature ideas
The cost of saying "yes" to feature ideas
We built the wrong thing because a customer asked for it. Learn from our mistakes.
A little while ago, I wrote about how when we started Tanda, one of the catalysts was that another vendor tried to sell us a fingerprint scanner that cost tens of thousands of dollars. We thought that was ridiculous, so we started our own business to compete.
This was in 2012. We had a brilliant vision - commodity hardware and web-based software would make time and attendance dramatically cheaper and easier. We knew this was a better product than fingerprint scanners.
And yet in 2015, we built a fingerprint scanner. 1 customer used it, ever. 2 years later the same customer stopped using it. This is the story of that big waste of time.
“We love your product. But we want a fingerprint scanner that connects to our point of sale.”
This came up right at the end of a sales call with a really exciting prospect. It was a nationwide chain, a brand everyone had heard of. It would be a huge deal to win this account. And so, with dollar signs in our eyes, we said “sure”.
We found a fingerprint scanner with a USB adapter on Amazon and bought a whole bunch of them. We hired a buddy of ours as an intern to write a Windows application that talked to the fingerprint scanner, and to our API. A few months later, we proudly announced “Tanda’s POS integrated fingerprint scanner”.
It’s worth noting that for our existing customers the setup process was really simple; you sign up, we mail you a preconfigured device, you plug it in turn it on, and your employees can immediately clock in and out of work.
But if you wanted our new fingerprint scanner, you weren’t so lucky. We were still figuring it out. The first one we deployed was at a business down the road from my house; I walked into the store, tried to install it, took photos of confusing error messages that meant nothing to me, sent them to my buddy the intern, waited for him to make a new build once he was finished with class, then went back into the store to try and install it again.
Eventually we got the scanner working in this store, so we wrote a user guide for every other store. Here’s a sample:
The user guide was done, so the project was done! I thanked my buddy the intern, paid him, and he went on his way. We started thinking about how good this new logo would look on our website. Dave agreed to own the code going forward in case we needed to make any minor tweaks.
Then the fingerprint scanner started to get used. At its peak, I think we had about 30 stores using it in production - all from the one account. They reported issues constantly. The program would crash and nobody knew why. Worse, the program couldn’t start again because it hadn’t actually crashed, so you needed to restart the computer to fix it. But you couldn’t restart the computer because it was also the point of sale and it took 15 minutes to restart and it’s the middle of a sales rush.
The best part was how these stores were busiest on weekends. Which meant I was interrupting Dave’s weekend beer pong games to ask him to recompile .NET applications with code we thought might work. We were both on Macs.
For the next 3 months we constantly fixed hard to debug issues. Half the time I think Dave was guessing as to what had broken, let alone how to fix it.1 Eventually we got to some semblance of stability.
About 9 months later we started working on a contract with this great logo, to sell to all their stores nationwide. By then, a bunch more stores had signed up, and we had just not offered them a fingerprint scanner. Pretended it didn’t exist, and gave them the same product we gave every other customer. It worked fine, and these stores seemed much happier (or at least, they had a lot less issues). So when drafting the contract, we kept fingerprint scanners out. Just didn’t mention them. And nobody even asked.
A year later, we’d successfully moved every store that had used it off the fingerprint scanner, and removed all the code for it.
The lesson
This wasn’t the only time in our history that someone suggested a nice to have in passing in a sales call, and we treated it as an essential requirement.
It happens all the time. You say “yes” to everything so as to win the deal. Great salespeople can challenge a prospect’s requirements and redirect expectations. But we didn’t challenge the prospect at all, we did the opposite - went all in and immediately built exactly what they asked for.
Then a year later, we learned that this “mandatory” request actually didn’t matter at all. It was just one person’s opinion about how the product should work. And it wasn’t even right - over the next year we found that the product we’d already built was much better.
This meant we spent about 6 months building, supporting, and iterating on the wrong product. For 6 months, our best engineer didn’t work on features that all our customers then and in the future would benefit from. Instead he worked on code that we’d throw away 12 months later, and that would only get used by a single customer.
The cost to produce the code, was more than the revenue the code produced.
You never ever want to do that.
This doesn’t mean you should never try anything new. Every feature will have a first user, so at some point, every feature will just have one user. But every feature is also a bet. Are we willing to pay the time and focus it takes to build it, because we think it will be worth a lot more than that? It is easy in the midst of a sales cycle to think about the “what it will be worth” side and not the “what it will cost” side.
To help spot that, here’s some warning signs to look for:
Only one customer has asked for the feature and not been totally fine with the workarounds/alternatives you have.
Even within that customer it’s not clear if this is a real dealbreaker or just one person’s brainwave.
You think you already have a better or comparable way of solving the same job to be done.
You don’t have technical expertise in house to build the feature well. Building it doesn’t sound fun to anyone.
I was talking to some friends doing their own startup not long ago, and one of them complained that “we have added heaps more devs, but we aren’t moving any faster”. We dug into it a bit, and the biggest cause was not building the right things. I think this is true in most companies, most of the time. It’s easy as technical leaders to focus on how we could go 10% faster if we optimised how the dev team works and the tools they have. But at the same time we’re accidentally building the wrong thing, which is the equivalent to 0% output for months!
You’ll go infinitely faster if you build the right thing.
ps. here’s Dave after we turned the fingerprint scanners off.
More “fun” anecdotes from Dave: the computers were running unpatched Windows XP, which had out of date root certificates, so it couldn’t talk to our API (but could talk to some other HTTPS sites, for reasons we never worked out). So we had to bundle a full certificate set.
Also because we didn’t know anything about building Windows applications, for ages we didn’t have an auto-updater. So we had to call stores and tell them to redownload and reinstall the program.
Then one day we renamed the program, which broke our reinstalling flow. That was hard to fix.