LISTEN TO YOUR CUSTOMERS
“If I had asked my customers what they wanted, they would have said, ‘faster horses’,”
- 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.
- 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.
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…”
- 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.
That’s NOT “listening”
- 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.