How I built the same MVP 3 times, across 3 continents in 3 weeks "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 1 March 2014 True Lean Startup, Minimum Viable Product, Mind the Product Mind the Product Ltd 1200 Product Management 4.8

How I built the same MVP 3 times, across 3 continents in 3 weeks

How to build 3 MVPs at the same timeI 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

Hi Rif, interesting articles, putting 3 teams on the mvp phase is a good thought. That’s the team who will carry your project onward with.
I’m a UX, UI, product designer, and building my project: a platform for teens to go out more often! The technical aspect is always a difficulty, any advise you could give me on that?
About your MVP, i usually create prototype to test the product with a small group, like you did with the restaurent. But then once launched, the interactions are all trackes with the data team, and this might change the interface drastically. Take this into consideration when rolling out your project, and be flexible to understand and adapt.

Very interesting post, but I do think it should be renamed to ‘minimum viable team’! The discussion about platforms and scaling misses the point – what you needed was agile-minded (in all senses) developers, and this was a good way to find them.

I think this is food for thought for most managers taking decisions on building any new project and even modifying and updating their internal application. The fact that you chose to build more MVP`s and also test the systems is a good investment knowledge.

One thing i would point out is that Heroku and Google App Engine are PaaS(Platform as a Infrastructure) and Magento(PHP), Spree(Ruby on Rails) are E-Commerce Applications that work on every cloud/servers that support the underling solutions. I don`t think you found the best solution for a your project(it does`t exist 🙂 ), but you found the best team that can build your application fairly fast.

Magento does not scale based on PaaS, but based on normal IaaS. I did not want to deal with trying to scale Magento, If Magento was built on a PaaS would be different story.

This is a really interesting post. Part of me loves the fact that you have very quickly found a team and a platform that will work well for you in the future. However part of me feels like there is a lot of waste here. An MVP should be disposable and is designed to find the features that users are willing to pay for. If it turns out that no one wants your MVP you have wasted resources building all these similar MVPs when you could have built 4 different MVPs and tested more hypotheses. Once you have a validated USP you could look at the platform you need.

Arguably you have learnt a great deal in a short period of time and you will likely save a lot of time in the future because you have a great team you can rely on.

Part of me dislikes how you have narrowed down the platform for a disposable MVP based on your opinion of the company behind it when if you were being strictly data driven there should be some experimental evidence behind this. However a big part of me loves the fact that you have taken this in to account. Even if you product starts taking off, if you are using a platform you Have no confidence in it will show and leave you with nagging doubts.

I am split 50:50. Thanks for challenging my way of thinking. Hope it works out for you

Thanks Dave for the feedback. I agree that we have “lot
of waste here” in terms of money & code. I would have loved to have
done 4 different MVPs, but it’s would been really hard to compare the teams & platforms and I just don’t think I’m that good. I was already running at max and making compromises per MVP. I would have ended up spending thinking about different MVP’s & Making the choices about who should do which MVP.

Maybe the title article should go from ** Minimum Viable Product
to Minimum Viable Team **. The end result was learning about the teams and platforms. The Product fit would take another 6 month to full understand ( need to write about this also )

Regarding “dislikes how you have narrowed down the platform”
is this regarding Heroku & Salesforce? I have had many dealings with salesforce being a CIO in my past job, plus I have been watching Google App Engine since came out in 2008. Love to answer another questions you have. We been now running on Azure and App Engine for 11 months.

Join the community

Sign up for free to share your thoughts