LISTEN TO YOUR CUSTOMERS
Over the past five years, I’ve been running a fast-growing outsourcing business called CodeStringers. In that time, I’ve worked closely with dozens of entrepreneurs who engage our firm to help them realize their vision. And, in keeping with industry norms, the majority of startups fail. In my experience, the primary reason for that failure is that the founder(s) believed they knew the market so well that they did not need to talk to customers… that their vision was so far ahead of the thinking of their customers that there would be no value in talking with them. Equating this back to Ford’s quote, these founders believed their customers would have asked for a faster horse while they were building a Tesla.
On at least one occasion in my 20 plus year career working in software, I’ve been guilty of this mistake. Here’s my story…
“If I had asked my customers what they wanted, they would have said, ‘faster horses’,”
My co-founders and I established FileString in 2012 as a cloud-based service that helps professionals track recipients’ use of and maintain control over their confidential files. At that point in our history, I was the head of product for the company, so it was my direct responsibility to define the features and user experience of the product.
This early version of FileString worked because we built applications for Mac and Windows computers, applications for iOS and Android tablets and phones, and a web application. All applications allows users to share their own files and view files received from others, meaning that the applications included the DRM functionality required by senders – encrypting the file and setting file permissions for each recipient – and the DRM functionality required by recipients – the ability to decrypt/open the file and ensure that the permissions set by the owner are enforced. The permissions we allowed file owners to set were:
- Allow the recipient to “reshare” the file to other recipients;
- Allow the recipient to print the file;
- Watermark the file when it is viewed or printed;
- Set an expiration date/time after which the recipient cannot open the file.
But there were a few problems:
- It wasn’t user-friendly. As soon as you add DRM technology to control file types that you do not “own” (i.e. Microsoft, not FileString, “owns” the Microsoft Office file types), it becomes impossible to achieve “ease of use”. Your options are to: A) build your own “viewer” application for recipients such that received files (Microsoft Office, PDF, etc.) open in an application you build rather than the applications built by the companies that “own” the file types; B) build plugins to the applications built by the firms that “own” the file types. Either way, the experience for recipients is, at best, clunky.
- It wasn’t valuable to customers. In an era of nearly ubiquitous Internet connectivity, there is limited value in providing “offline” access to received files. Said more simply, DRM is only needed to govern how recipients can use downloaded copies of files. Y9ou can draw one or two conclusions based on this:
- Recipients do not need offline access to files because connectivity is ubiquitous, or;
- Recipients need offline access but it’s sufficient to have the downloaded files be “unprotected”, meaning that no DRM is controlling downloaded copies of files and recipients can do what they want with them.
Regardless of which option, or both, is correct, DRM does not lead to features users value.
Over the two year period from founding the company to realizing our fatal flaw, our team burned through all of our seed funding, lost the confidence of investors, and were unable to establish product-market fit.
Meanwhile, in a shorter time period, Docsend was founded, built their product without the need for a dramatic pivot, established product market fit, and set their company and team on a trajectory that led to a fantastic acquisition.
So, what did they do that we didn’t? Although I’ve never actually met their team, I can say with confidence that perhaps the most important thing they did was listen to their customers.
Our focus at FileString was on “security”. We wanted files to be encrypted “end-to-end” and fully under the control of the file owner. While this value proposition may seem worthy, the value is only delivered if the resulting product is easy to use.
What we saw when we released FileString as a “beta” to potential customers was that people who signed up created two accounts under two different email addresses. One email address would show one or two sent files and the other would show the same number of received files. Our “customers” were “kicking the tires” by experiencing FileString themselves as both a sender and a recipient. They wanted to see the experience from both sides.
Problem was that we had hundreds of users that completed the above “test” and never used the product again. We interviewed customers numerous times over the two years we built and iterated the product (but please do not confuse the term “interview” with “listening”, because they aren’t necessarily the same thing). They told us the following:
- That the service was unreliable. The inclusion of DRM technology caused applications to crash, some features intermittently to not function correctly, and, in some cases, corporate networks were configured such that DRM-based features of our product were blocked.
- That our user experience was flawed. The primary complaint was that recipients want to open files in their intended applications, not in the “viewer” application we built, which was our means of employing DRM to control recipient use of the files. “If I’m opening a spreadsheet, open it in Excel…”
The problem was that we simply did not listen to that feedback in a meaningful way. We interpreted that feedback as:
- We need to fix the “bugs” in the software to improve reliability;
- We need to continue to improve the user “journeys”, particularly the “first time recipient experience” journey.
It took us two and a half years to conclude we had a fatal flaw. That’s NOT “listening”.
That’s NOT “listening”
There are a couple of reasons:
- The first reason is that pivoting means that you’re further away from the notoriety and financial windfall that likely led you to found the company in the first place.
- The second is that you’re simply too driven by your ego to admit that your own ideas weren’t perfect.
Both of these reasons are a direct result of hubris. That was certainly the case for me.
In my case, I had a bit of luck. We had started an offshore development subsidiary in Vietnam soon after the company was founded – a group I had been managing for the past year. I elected to leverage that organization to form the outsourcing business and, with that, the company became CodeStringers. The other option was to shut the company down and, for entrepreneurs who do not have an alternative source of funding (i.e. outsourcing revenue), a shut down would have been their only option.
The morale of the story is, if you want to be an entrepreneur, leave your ego behind and truly listen to your customers. As innovative as you likely are, you probably aren’t the next Steve Jobs or Henry Ford. And, if that statement offended you, re-read the proceeding sentence about leaving your ego behind.
And by the way, we have since leveraged our outsourcing business to make the required pivot to the FileString product. It’s now a web and mobile-based file control and tracking service. No DRM. Just an easy to use service that provides greater control and tracking of your confidential files than existing file sharing services.