Contact us at upsourcing@codestringers.com or 831.245.0500

LISTEN TO YOUR CUSTOMERS

Hubris is a death sentence for many startups
I have heard countless entrepreneurs – including myself – quote Henry Ford when he said, “If I had asked my customers what they wanted, they would have said, ‘faster horses’,” the implication being that the entrepreneur knows more than the customer. In the history of innovation, only a small handful of luminaries have had the ability to successfully prophesize the needs of customers and innovate based on that vision. For the rest of us, we need to do something that may seem obvious, but in far too many cases does not happen… we need to listen to our 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’,”

Henry Ford

Last week, a competitor of a product my company builds was acquired by Dropbox for $165 million. As background, my firm CodeStringers has two business units: products and outsourcing. Our outsourcing business is thriving. Our product is called FileString and has yet to thrive. The FileString competitor that Dropbox acquired is Docsend (As a side note, my sincere congratulations to the team at Docsend). As you can imagine, this event provoked reflection and introspection on my part.

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.

In its first “generation”, which we built between early 2012 and late 2013, FileString combined file sharing and digital rights management (DRM) into an easy-to-use service for prosumers and teams. If you’re not familiar with DRM, it’s a category of technology that allows a person or business to set permissions for a file that, when a file is shared or downloaded, governs what the recipient or downloader is able to do with the file. If you’ve ever purchased a movie or song from Apple iTunes, you’ve used DRM even if you didn’t know it. DRM is what prevents you from opening those movies or songs outside of the applications Apple provides for that purpose. DRM encrypts the file ensuring that it can only be opened by specified applications and, one opened, some features of the application may be restricted (i.e. a file owner might prevent a user from printing or saving a copy of the file, for example).

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.
Our intention was to provide a completely secure file control service that was also easy to use.

But there were a few problems:

  1. 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.
  2. 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.

Now, back to my statement about the need to listen to customers.

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:

  1. 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.
  2. 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…”
Our team conducted dozens – likely hundreds – of “interviews” in which we heard the feedback above consistently.

The problem was that we simply did not listen to that feedback in a meaningful way. We interpreted that feedback as:

  1. We need to fix the “bugs” in the software to improve reliability;
  2. 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”

Listening is an active process. True listening means that you want to understand in depth what people like, but more importantly what they do not like, about your product and the reasons for those likes and dislikes. True listening implies that you’re open to concluding that your product and business need to pivot. And that word scares the heck out of many entrepreneurs, particularly those guilty of hubris.

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.

It’s amazing, however, how humbling failure can be. Concluding that the FileString product had failed and needed to pivot knocked the wind out of me, figuratively speaking. Any ego, and the hubris it causes, was deflated. Along the way, I had lost both of my co-founders and, as a first-time CEO, was looking at having to shut the company down within a few months of taking the proverbial “helm”.

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.

CodeStringers