I built the same product three times. It wasn’t an act of insanity. It was my way to get my product ready in three weeks.
Before I get to that, let me backtrack a little. It was the 1st of March 2013 and I’d just left my job as CIO at one of the UK’s leading food distributors, JJ Food Service (full disclosure: I still own shares in them). I wanted to launch a startup with a clear vision: To eradicate terrible meals.
We would start to do that by providing restaurants with technology that would allow them to be found by customers more easily, to keep those customers coming back and to improve their own efficiency.
I had just finished reading The Lean Startup (if you aren’t familiar, watch this YouTube intro), by Eric Ries, and I was determined to employ the “lean” approach: Undertaking business-hypothesis-driven experimentation, releasing iterative products, and employing “validated learning”.
My goal wasn’t to learn how to build an online ordering system – hundreds of developers have already figured that out – but rather to uncover the right mix of features and marketing that would most effectively drive traffic to a restaurant website.
I was acutely aware of how recruiting the right people could drag out my timeline and I wanted to move quickly. The first step was to build a minimum viable product (MVP), and do it fast. My gut feeling was that Google App Engine would be best, but I wanted to try out other platforms and teams. So I initially picked four platforms and selected four companies to build to the same requirements. I planned to work with each company over the course of five weeks and through the process, uncover both the best platform for my product and the best team to finish it.
I started by working with the Google App Engine and Heroku teams, which both had experience with the “lean way” and MVPs, to figure out what our MVP should look like.The Heroku team came up with the leanest possible MVP: Literally a website with a phone number. The experiment, they argued, should focus on figuring out which features will drive people to the website. While I agreed with them in theory, my “non-lean” ego left me wanting something bigger and I opted to go with the slightly bigger MVP developed by the Google App Team. That, combined with the fact that Heroku is now owned by Salesforce, a company I don’t trust to properly shepherd Heroku, made me decide to part ways with the Heroku team.
With the MVP agreed upon, we kicked off work with the three teams: Google App Engine (Team Australia); Azure (Team India); and Magento (Team Sweden), which is an e-commerce platform that had the advantage of saving programming time, though at the expense of flexibility.The MVP parameters were: We needed a product that would allow restaurants to have their own website and that website needed to be responsive. It was restricted solely to restaurants that do takeaway service (no delivery), are cash only and don’t have customizable meal options. And we needed it up and running in five weeks or less.
An Experiment on Three Continents
We hit the start button and three teams began building to the same MVP parameters. My Google App Engine team was based in Sydney, which is where I chose to locate myself during the experiment, in part because of my gut feeling about the potential of Google App Engine, but also because after living in London my entire life, I craved some sun. I took up a desk at FishBurners Startup Office (and made great startup friends out of Sam, Bret & Jethro), a wonderful tech incubator in the heart of Sydney.
Although I located myself with Team Australia, I Skyped with Team India and Team Sweden daily. Running three MVPs simultaneously in three different time zones was very stressful. I’d finish my day working in Australia and then do my calls with the Team India and Team Sweden.Team Sydney was adept at the lean way and helped connect me to local restaurants with whom we could talk and test out hypotheses and features. We ultimately needed three restaurants who would serve as our test subjects for each of the three MVPs.
When I won an award from Microsoft for my past role as CIO, I had to fly to New Orleans, which further complicated my timezone-confused brain. On the way back, I was overjoyed that I could squeeze some In-N-Out into my layover at LAX. The Magento team wanted me at their conference, which came at the very end of the experiment, so I made another U.S. trip, this time to Las Vegas, and then back to Sydney to make the decision. Needless to say, I was travel-weary.
So, The Results!
Team Sweden
While Magento could have saved ample programming time by allowing us to build on legacy code, I couldn’t bring myself to inherit so much old legacy code. Ultimately, Magento was a showstopper because it was a two-tier architected system and I didn’t like how the logic duplicated on each tier. It felt like every poorly-written ERP system I’ve ever had to deal with. But I loved working with the team in Sweden, who were not only skilled programmers but displayed essential knowledge of e-commerce, customer behavior and user interfaces. I came to appreciate how important those additional traits were.
Team India
Azure’s platform as a service had more flexibility and options than the other two, but lacked in maturity when compared to Google App Engine. The team in India were solid developers, but had less business experience in what we were trying to build. I found it difficult to give them projects that weren’t tightly defined or that required them to make important design decisions on their own. Their day rate was much cheaper than the other teams, but the overhead on management and slowness in delivering something useful offset those cost savings. I was able to get the Indian team to work on another project for us, because I saw they were good at more structured projects that don’t require domain knowledge and I enjoyed working with them (which is always important).
Team Australia
At the end of the experiment, I selected the Australian team and Google App Engine as our main platform. Team Australia was perhaps the most fluent in the “lean way”, constantly challenging each other on whether each decision was truly the leanest. And yet despite the robust discussion, they were able to complete the entire MVP in only three weeks. My instincts about Google App Engine proved true, and we found that it allowed the developers to be the most productive, building faster, scaling and more cheaply than the alternatives. Also, it’s hard to discount the fact that I trust Google as a steward of the platform.
This experiment taught me several critical lessons about how to do the lean way right, how to run multiple MVPs and how to manage teams across timezones. For those lessons, don’t miss out on my follow up post, coming soon!
Comments 6