Chapter 1: An Engineer’s Itch
I’d love to claim that I’ve subconsciously used Customer Development practices all along but that just isn’t true. My first product, 6Degrees, was a p2p address book that was created to basically test out the 6 degrees of separation concept – a sort of “trusted Napster” for contacts. I didn’t talk to any users, I just did it. There wasn’t a general purpose p2p framework we could use, so we just built one.
That same year Friendster launched, social networking was coined, and a slew of social networking sites entered the scene. Forget the fact, that simply linking address books does not build transitive trust. Everyone was (and still is) touting the strength of weak ties as “If you friend me, I will be your friend”. We were swept up in the hype and were basking in the glory of being different. Having built 6Degrees on a decentralized versus centralized model, we harped about the inherent benefits of user privacy and control our approach afforded. We were building a smarter social network where the quality of the relationship trumped the size of one’s network.
In the end, our difference didn’t matter and actually hurt us. Users wore their inflated network size as a badge of honor and for a while social networking was a game. Public profiles and the prescribed benefits of networking made these services just useful enough to keep attracting more users.
Chapter 2: Technology looking for a problem to solve
The tide began to turn from social networking towards social media, from linking the people you know to linking the things people were interested in – flickr with photos, last.fm with music. I convinced myself and the team on the merits of a P2P collaboration application overlaid over a social network. The application would allow collaborators to discover each other through affinity (interest) groups and they would be able to connect with each other through their networks. Once connected, they could create ad-hoc collaboration groups or shared spaces for documents, messages, etc. This time around, I created 15-20 screen mockups and we did talk to several people in the scientific community including the American Heart Association – researchers doing drug discovery that could benefit from such collaboration. We got a lot of positive encouragement and interest in the concept but no budget for an early pilot.
The app promised a lot and rather than trying to reduce the problem scope with customers, I stuck my head in the sand and spent the next 6-9 months building the WiredReach Collaboration Platform. It was a lot more complicated than I had expected. But I did get a lucky break. An entrepreneur in Norway was also looking for a p2p framework for a “legal” music application he wanted to build and ran across my blog. A month later we were building a custom music application for him, while finishing and retaining all the rights to the platform – a classic bootstrap relationship which we have to this day.
Chapter 3: A brief encounter with open source
Over the next year, while building the music application, I briefly dabbled with open sourcing the underlying platform. Surely there had to be other people interested in an open source p2p framework and what better way to build out the platform. It turned out that open source had itself become big business and was no longer something that could be done part-time. Attracting and building a strong community required full time attention, evangelizing, speaking engagements etc. I was at best able to build a very fragmented user community that ended up being more work than help. I quickly nipped it in the bud.
Chapter 4: Embracing simplicity
Up until now, I had been consumed with building complex solutions to complex problems. Simple web applications, like Basecamp, were starting to emerge that didn’t solve complex problems but rather solved a small sliver of a complex problem in a simple way. Some even accused them of being too simple. At the same time, I had started toying with a new model I termed p2web. I had realized that the biggest barrier to adoption in a p2p network was not technology but the software distribution model. It was hard enough getting one person to download and install desktop software. P2P required both sides to be using special software which was a hard value proposition unless you were giving away a lot of something for nothing – Kazza did it with free music, Skype with free phone calls. Even free was not always enough.
The new p2web model would only require the sharer to download software while the recipients would be able to use just a web browser. In any given community, there are about 10 times as many consumers as producers. All I needed now was a minimum viable product to test this out. At the time, I had labeled this approach ASAP3 – As Soon, Simple, Small, As Possible. I had the perfect problem. File sharing is the least common denominator in any p2p application so I decided to start with that – and BoxCloud was dead-simple file sharing. Once you downloaded the application, you could share a file or entire folder on your computer instantly since nothing had to be uploaded. The recipient would get an email with a web link which would point to the actual file or folder on your computer. All they needed was a web browser to access it.
After the product went live, we got some blog coverage, and dumped some serious cash advertising on the DECK network (primarily targeted at designers and developers). We got a ton of traffic which exposed some basic scalability holes which we spent some time fixing. By now we had also heard of the merits in listening to your users and decided to follow a release early/release often model. The only problem was we didn’t know how to listen. In the interest of efficiency and productivity, I generally avoided face to face meetings and phone calls and preferred email. Many people were struggling with the software (desktop apps are hard) but we didn’t know how to engage them. After they’d cancel their account, we would send them an email to learn why but many times it was too late.
We were getting a lot of feedback over email but didn’t know the best way to qualify them. If more than one person asked for a feature and it sounded like a good idea, we built it. The reverse was also true, if the feature didn’t meet our model of “the vision”, we ignored it no matter how many people asked for it. And that’s how we kept busy for a while till I realized we still had a lot of leaky buckets despite all the listening we were doing.
Determined to get to the bottom of this, I got an 800 number which I put on our website and also started calling on users directly. The findings were staggering. Most of our paying users were using a very small percentage of the application. We had built up a lot of bloated features or waste which had only taken time to build but also continued to create ongoing work with regression testing, feature dependencies, etc.
We had started BoxCloud with a freemium model and eventually decided to switch to a premium/trial model. While we lost a lot of free users, it increased the quality of feedback we started getting and allowed us to better focus our listening. Everyone is a critic and when you’re not paying, I’m sorry but you don’t get to send us on wild-goose chases anymore.
Chapter 6: Another Platform is born
I continued to refactor BoxCloud and pulled another platform out from called CloudStack for building p2web applications. This time I didn’t bother with open source but rather created an api for others to plug into. Supporting an api was a lot less work than open source and something we benefited from too. This did help land another paying client that is currently licensing the platform.
Chapter 7: I discover Customer Development
After my daughter was born, I all of sudden needed to share lots of photos and videos with family and friends. There were already lots of sharing services but all them required you to babysit the sharing process which was a hassle. The problem we faced as new parents was not a shortage of options, but a shortage of time. I thought a p2web photo and video sharing application for busy parents might be interesting and spoke to my wife about it. She did most of the photo sharing and liked the idea.
At around that time, I had come across a Venture Hacks article on Steve Blank’s class on Customer Development. Following the trail led me to Eric Ries, Andrew Chen, and Dave McClure. After what I’d been through over the years, Customer Development felt like coming home after a long trip. I had dreamt the big vision, built it, and refined it all in my head. I had learned the value of building a minimum viable product the long way. I had seen how much faster learning could be once customers were really involved in the conversation.
I still didn’t know how to fully engage customers and that is exactly what Customer Development addresses. I was sold. I read every blog post and watched every video I could find. I was determined to learn how to learn from customers and use this for my next product: CloudFire. I have been using customer development and lean startup techniques since June and I’ll be outlining my specific experiences and case studies in subsequent posts.