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 about 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 and 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 makes User A’s computer directly (and securely) accessible from any web browser.
Here’s what file sharing with BoxCloud looked like:
User A no longer needed to upload the file, saving 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 is requested, we can 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 made the caching process invisible in the interface. Once they shared a file, we would cache the file in the background and automatically manage it 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 about a temporary cache versus permanent storage stemmed from our history in serverless content distribution from the P2P world. 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 focusing on and optimizing for the wrong customer. Our customers wanted to be able to serve their customers in the best possible way. While they appreciated a faster workflow for themselves, they would much rather jump through hoops if that meant a better and more predictable experience for their clients. It took me several 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. 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.
Being Amazing
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.