post

Footer About

Footer Get Involved

Footer Links

Mind the Product

General

Product Unplugged Episode 3 with Pierce Healy

Product Unplugged Episode 2 with Lorilyn McCue

Product Strategy

Building Product Teams

Diversity and Inclusion

Digital Transformation

Artificial Intelligence (AI) & Machine Learning (ML)

Product Leadership

Product Management Career

Product Ethics

Minimum Viable Product

Enterprise Product Management

OKRs

Customer Research

Hypothesis and Testing

Business Strategy

User Research

👩‍🚀🚀   Live now for MTP members: <a href="https://mtp2017stg.wpengine.com/membership/#events" style="color:#FFFFFF;text-decoration:underline;">Driving Innovation AMA with Tendayi Viki</a>

Roadmaps: Break the rules without breaking the principles

Got questions about your product career?

Product roadmaps vs data – Jeremy Levy on The Product Experience

From engineering to product management at Google

Mind the Product joins Pendo

Rif Kiamil

<p><img loading="lazy" decoding="async" class="alignright size-medium wp-image-4403" alt="How to build 3 MVPs at the same time" src="https://mtp2017stg.wpengine.com/wp-content/uploads/2014/02/colour_version-300x168.jpg" width="300" height="168" srcset="/wp-content/uploads/2014/02/colour_version-300x168.jpg 300w, /wp-content/uploads/2014/02/colour_version-1024x576.jpg 1024w, /wp-content/uploads/2014/02/colour_version-285x160.jpg 285w, /wp-content/uploads/2014/02/colour_version-570x320.jpg 570w, /wp-content/uploads/2014/02/colour_version.jpg 1280w" sizes="auto, (max-width: 300px) 100vw, 300px" />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.</p>
<p>Before I get to that, let me backtrack a little. It was the 1st of March 2013 and I&#8217;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.</p>
<p>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.</p>
<p>I had just finished reading <a href="https://mtp2017stg.wpengine.com/product-management-books/" target="_blank">The Lean Startup</a> (if you aren&#8217;t familiar, <a href="http://www.youtube.com/watch?v=FRR_jEDAfoo">watch this YouTube intro</a>), by Eric Ries, and I was determined to employ the “lean” approach: Undertaking business-hypothesis-driven experimentation, releasing iterative products, and employing &#8220;validated learning&#8221;.</p>
<p>My goal wasn&#8217;t to learn how to build an online ordering system &#8211; hundreds of developers have already figured that out &#8211; but rather to uncover the right mix of features and marketing that would most effectively drive traffic to a restaurant website.</p>
<p>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 <a href="https://www.youtube.com/watch?v=UR2yWfKt6Ws&amp;list=SPDFDBB63922B90A70" target="_blank">Google App Engine</a> 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.</p>
<p>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.</p>
<p>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.</p>
<h3>An Experiment on Three Continents</h3>
<p>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 <a href="http://fishburners.org/" target="_blank">FishBurners Startup Office</a> (and made great startup friends out of <a href="http://www.feedbackloop.com.au/" target="_blank">Sam</a>, Bret &amp; <a href="http://www.parkmyvan.com.au/" target="_blank">Jethro</a>), a wonderful tech incubator in the heart of Sydney.</p>
<p>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&#8217;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.</p>
<p>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.</p>
<h3>So, The Results!</h3>
<p><strong>Team Sweden</strong><br />
While Magento could have saved ample programming time by allowing us to build on legacy code, I couldn&#8217;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&#8217;t like how the logic duplicated on each tier. It felt like every poorly-written <abbr title="Enterprise Resource Planning">ERP</abbr> system I&#8217;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.</p>
<p><strong>Team India</strong><br />
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&#8217;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).</p>
<p><strong>Team Australia</strong><br />
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.</p>
<p>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&#8217;t miss out on my follow up post, coming soon!</p>
<div class="g g-21"><div class="g-single a-77"><a class="gofollow" data-track="NzcsMjEsMSw2MA==" href="https://mtp2017stg.wpengine.com/product-management-training/public-workshops/"><img decoding="async" src="https://mtp2017stg.wpengine.com/wp-content/uploads/2021/10/General-Training-Next-Level-FOOTER-scaled.jpg" /></a></div></div>

core/freeform

Data Driven Product Management

Data scaling for startups by Crystal Widjaja

Make Better Product Decisions by Using Quantitative and Qualitative Data, by Brian Tran

Testing Business Ideas, by David Bland

Developing a Data-Driven Culture at Dow Jones, By Helen Hewitt

When A/B Tests Aren’t Enough, By Scott Castle

Using Data to Build a Brand, by Abba Newberry

Socially Preferable by Nathan Kinch

They’re Just Fancy Averages by Ben Fields

Talking About Data Science by Jenessa Lancaster

Unlocking Data Science to Build the Future of Work by Mike Hyde

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

ProductTank Columbus

ProductTank Tauranga

ProductTank Edinburgh

Prioritised Member AMA - Perfecting product roadmaps

ProductTank San Diego

Navigating difficult relationships panel

ProductTank Philadelphia

ProductTank Bucharest

ProductTank NoVa

Remote Training Workshops

ProductTank London

ProductTank Birmingham

ProductTank Oslo

ProductTank Astana

ProductTank NoVA

ProductTank Zürich

ProductTank Perth

ProductTank Tokyo

ProductTank Chicago

ProductTank Auckland

ProductTank Richmond

ProductTank Charlotte

ProductTank Reston

ProductTank Washington

ProductTank Sofia

ProductTank Raleigh

ProductTank Ljubljana

ProductTank Kraków

ProductTank Athens

ProductTank Barcelona

ProductTank Dublin

ProductTank Montréal

ProductTank Seattle

ProductTank Madison

ProductTank Singapore

ProductTank Portland

ProductTank Budapest

ProductTank Valencia

ProductTank Porto

ProductTank Los Angeles

ProductTank Austin

ProductTank Norwich

ProductTank Des Moines

ProductTank San Francisco

ProductTank Helsinki

ProductTank Reading

ProductTank Brighton

ProductTank Buenos Aires

ProductTank Bielefeld

ProductTank Charleston

ProductTank Bogotá

ProductTank Newcastle Upon Tyne

ProductTank Dallas

ProductTank Malmö

ProductTank Canberra

ProductTank Paris

ProductTank Manchester

#mtpcon SF+Americas 2022 Conference

#mtpEngage Hamburg 2022 Leadership Forum

#mtpEngage Hamburg 2022 Workshops

#mtpEngage Hamburg 2022 Conference

#mtpcon London+EMEA 2022 Conference

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

Rif Kiamil

Read more

Comments