Listen To Your Customers

Hubris is a death sentence for many startups
I’ve heard many entrepreneurs, including myself, quote Henry Ford’s famous words: “If I had asked my customers what they wanted, they would have said, ‘faster horses.’” Ford implied that entrepreneurs often have better insights than their customers.

Innovation history reveals only a few visionaries who accurately predicted customer needs and innovated accordingly. For the majority, including myself, the crucial step is often overlooked: listening to our customers.

In the past five years, I’ve run CodeStringers, a fast-growing outsourcing business. I’ve closely collaborated with numerous entrepreneurs who seek our assistance in realizing their visions. Sadly, as is typical in the industry, most startups fail. In my experience, their primary downfall lies in founders’ belief that they understand the market so well that talking to customers is unnecessary. They think their vision is far beyond their customers’ comprehension. In essence, they assume their customers would have asked for a faster horse while they’re building a Tesla.

In my over 20-year software career, I’ve made this mistake at least once. Here’s my story…

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.

In 2012, we founded FileString. It’s a cloud-based service for tracking and controlling confidential files. I served as the head of product at that time. My role was to define product features and the user experience.

In its initial “generation” from early 2012 to late 2013, FileString merged file sharing and digital rights management (DRM) to create a user-friendly service for prosumers and teams. DRM, short for digital rights management, is a technology that enables individuals or businesses to set permissions for shared or downloaded files.

If you’re not familiar with DRM, it controls what the recipient or downloader can do with the file. For example, when you buy a movie or song from Apple iTunes, DRM is at play, even if you don’t realize it. DRM encrypts the file, allowing it to be opened only with specific applications. Moreover, some application features may be restricted once opened, like preventing printing or saving a copy of the file.

The early version of FileString was successful because we created applications for Mac and Windows computers, iOS and Android tablets and phones, and a web application. These apps allowed users to share their files and view files from others, incorporating the essential DRM functions needed by senders and recipients.

For senders, the applications incorporated DRM features enabling them to encrypt the file and set specific permissions for each recipient. Recipients, on the other hand, could use DRM functionality to decrypt and access the file while adhering to the owner’s designated permissions. Some of the permissions that file owners could establish included:

• 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. Once you introduce DRM technology to control file types that you don’t “own” (e.g., Microsoft owns Microsoft Office file types, not FileString), achieving “ease of use” becomes challenging. Your choices are: A) Develop your own “viewer” application for recipients, ensuring that received files (like Microsoft Office, PDF, etc.) open in an application you create rather than the applications owned by the companies that control the file types. B) Develop plugins for the applications created by the companies that own the file types.
2. It wasn’t valuable to customers. In an age of widespread Internet access, offering “offline” access to received files has limited value. Put simply, DRM is necessary only to control how recipients can use downloaded file copies. You 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.

At FileString, our primary focus revolved around “security.” We aimed to encrypt files “end-to-end” and ensure they stayed entirely under the file owner’s control. However, we recognized that this value proposition would only be meaningful if the resulting product was user-friendly.

When we first launched FileString in a “beta” version for potential customers, we noticed that many users signed up for two accounts using different email addresses. In one account, they would have one or two sent files, while in the other, they would have the same number of received files. Essentially, our “customers” were testing FileString by trying it out as both senders and recipients, aiming to grasp the user experience from both angles.

The challenge we encountered was that hundreds of users performed this “test” but never engaged with the product again. Despite conducting numerous customer interviews during the two-year product development and iteration process, it’s essential to note that “interviewing” doesn’t necessarily equate to “listening.” Nevertheless, customers shared the following feedback:

1. Reliability Concerns: Customers voiced their frustration with the service’s unreliability. Integrating DRM technology resulted in application crashes, intermittent malfunctions of specific features, and, in some cases, corporate networks configured to block our product’s DRM-based features.
2. Flawed User Experience: The primary complaint centered around our flawed user experience. Recipients expressed a strong desire to open files in their intended applications, rather than in the “viewer” application we had developed. They wanted a straightforward approach like, “If I’m opening a spreadsheet, it should open in Excel…”

That’s NOT “listening”

Listening is an active and essential process in entrepreneurship. True listening involves a deep understanding of both what people appreciate and, more crucially, what they dislike about your product, along with the reasons behind those sentiments. Genuine listening requires being open to the possibility that your product and business may need to pivot. Unfortunately, the very idea of pivoting can terrify many entrepreneurs, especially those afflicted with hubris.

This fear stems from a couple of reasons:

1. Firstly, pivoting means distancing yourself from the fame and financial success that likely motivated you to start the company in the first place.
2. Secondly, it often requires recognizing that your own ideas were not perfect, which can be challenging when ego is involved.

I can certainly attest to my own experience, and both of these reasons directly stem from hubris.