Last week, I re-watched Kathy Sierra’s talk from the 2009 Business of Software conference. As usual, it was filled with gems of wisdom around creating passionate users. But one of her old memes particularly stuck out for me:
Don’t make a better [X], make a better [user of X]
More often than not, we unknowingly optimize for the wrong problems or worse customers.
Here is an example from my first product BoxCloud.
Building a better [X]: Take 1
BoxCloud was built as a Minimum Feasible Product to test out our new peer to web (p2web) framework. In our case, [X] was a file sharing service targeted at small businesses and freelancers. The “promise” was easier sharing of files without emailing, uploading, or FTP.
Here’s how large files were typically shared before BoxCloud:
Files had to be uploaded to a central server somewhere which took the user T1 minutes. Then the recipient was notified who then downloaded the file off the server in T2 minutes.
The Total Time to move a file from user A to user B was T1 + T2.
The advantage of a p2web approach is that it made User A’s computer directly (and securely) accessible from any web browser.
Here’s how file sharing with BoxCloud looked like:
The file no longer needed to be uploaded by User A which saved him T1 minutes. After getting the invitation from A, user B could directly download the files from User A’s computer in T1 minutes.
The Total Time to move a file from user A to user B was now just T1.
Even though, our approach was technically more efficient, it wasn’t better for everyone. While it certainly took less total time to move a file from User A to User B and it saved our customers time because they didn’t have to wait on uploads, the download experience for the recipient was usually worse. This is because a lot of small businesses, and especially freelancers, had asymmetric broadband connections which meant that T1 (a function of upstream speed) was significantly greater than T2 (a function of downstream speed). The real problem though was that the recipients were our customers’ customers and they mattered the most. Once they started complaining about slow downloads to our customers, we decided to do something about it.
Building a better [X]: Take 2
We had already envisioned supporting multi-source downloads all along and decided to address this shortcoming by caching shared files in the cloud. Now when a file was requested, we could swarm download it from both the cloud and the user’s computer improving the download speed to at least T2 and sometimes better. Because, we still wanted to give the sharer the feeling of instant sharing, we consciously chose to make the caching process invisible in the interface. Once they shared a file, we would cache the file in the background and automatically manage the cache so it would appropriately “age out” when it was no longer needed — a lot like a browser’s cache or CPU cache. Our motivation for thinking in terms of a temporary cache versus permanent storage stemmed from our history in server-less content distribution from the P2P world, and in turn was an optimization to lower external storage costs over time.
While this approach was an improvement over the previous one, it still had a problem of requiring the sharer’s computer to stay online until the files had been cached. This wasn’t a problem for some of our customers that installed the app on a dedicated file server, but it was for our freelance customers that typically used a laptop. Their files could potentially vanish off the network while they were driving between client sites if they hadn’t been fully cached!
Building a better [user of X]
All along we had been focussing and optimizing for the wrong customer. Our customers simply wanted to be able to serve their own customers in the best possible way, and while they appreciated a faster workflow for themselves, they would much rather jump through hoops if that meant a better and predictable experience for their clients. It took me a number of conversations with different customers to reach this realization. We were using the word “cache” right on our pricing page and most of our customers did not even know what that was…They thought they had been uploading files all along.
This lesson is reflected in our second product’s mantra:
CloudFire — “The real reason for sharing is making others smile”.
Once I finally understood (and accepted) that, we shifted (or pivoted) from a cache model to a much simpler storage model. That was not exactly a painless transition and I’ll detail that experience in my next post on Pivots. Optimizing to reduce external storage costs was premature if we couldn’t get enough customers to use the service in the first place. We redesigned the interface so our customers could track the sharing process within their application and we clearly differentiated their view from the visitor’s view allowing them to test drive exactly what their customers would see at all times. We have also since then started running extensive usability tests on the recipients view which had been secondary up to this point.
At the end of Kathy’s talk she shows a small clip from Connan O’Brien where his guest jokes about how people aren’t “amazed” anymore.
Customers care about their problems and not your solution.
Once you truly grok their problems and motivations, you can in Kathy’s words grant them the right superpowers to make them amazing, and in turn become amazing yourself.