As explained in my earlier post, in summer 2013, I built the same minimum viable product (MVP) three times on three different continents. It was an experiment with a purpose: To evaluate three platforms and three teams at the same time; and to utilize the “lean way” in using validated learning to build my new company’s first product.
To learn more about how I did my experiment, read my earlier post here.
I learned a lot throughout my first foray into the lean way, but three big lessons stand out: How to pick the right platform; how to work remotely with developers; and how to run lean, without running too lean.
how to pick the right platform
For 90 percent of tech startups building web applications, platforms as a service just makes more sense. I was thrilled with the time I saved not worrying about infrastructure and making choices about which memcached or database server to choose, then set up and run. Instead I focused my energies on the more pressing questions of the experiment.
It’s hard to give up control by using platform as a service. But I found I had more time to write business code and design useful features and wasted less time on the plumbing. Ultimately, it’s about finding the solution that lets you do less work, freeing you up to focus on the things that matter.
When picking which platform makes the most sense for you, I suggest asking four questions:
- Which platform will allow me to build the fastest
- Which platform will be cost-effective
- Which platform will allow me to manage scaling
- Which platform won’t be neglected by the company that owns it
Sometimes, the answer might be a platform your developers aren’t accustomed to using. The learning curve can be steep, but the long term rewards can be fruitful.
How to work remotely with developers
Being based in Sydney, I saw how invaluable the time I spent with the team there was in building our relationship and, ultimately, our trust of one-another. It’s sometimes hard for those of us in the tech industry to acknowledge the importance of “soft” stuff like socializing and trust, but it matters. You’re trusting this developer to build your baby!
We used a wonderful project management tool called Trello (see the public Trello.com board), which allowed us to pass on tasks and notes in an increasingly simplified way. It’s a wonderful feeling to get the point where you can tell someone to do something in as little as three words in a Trello card, instead of writing a full spec.
I was able to connect with Team India and Team Sweden, but the distance between us resulted in a distance in our relationship. If I could do it all over again, I would have tried to spend more time talking with Team India and Sweden, even about things that aren’t business critical. Those conversations help build understanding and trust.
All of that is to say, proximity matters, as do personal relationships and trust. If you’re going to be building a killer product with someone, be prepared to get close.
How to run lean (but not too lean)
In my first meeting with the Heroku team, we reviewed the “lean way” and they recommended building an MVP that was just a website and a phone number. It’s what’s known as a “concierge MVP” and it’s the most basic and manually intensive option available. At the time, the approach felt too lean to me–I didn’t want to build some lame website from 1993, I wanted to create something new. So I opted for a slightly more complex MVP.
On, paper they were right. A concierge MVP was the leanest approach and would have freed up even more room for experimentation on the core question we wanted answered: Which features will drive traffic to the website? But sometimes, the leanest is too lean. Ultimately, I knew I was building an e-commerce website, and I’d need to use some instinct and experience to decide just how much e-commerce to build as the MVP. Even as a passionate proponent of the lean way, I now see how easy it is to get caught up in the “just one more feature” game. Old habits die hard.
But the beauty of the lean way is that it’s less a set of rules and more a mindset, constantly pushing you in the right direction. Regardless of how lean our MVP was, the goal of the experiment remained the same: Uncover what features would help drive traffic to the site.
Depending on how we use it, the lean startup approach can be a tool or a weapon. As a tool, it’s helped us get an MVP up and running in a timespan I didn’t think possible several years ago. That’s probably because testing iterative products with restaurants wasn’t a mindset I would have had several years ago. Change can be a wonderful thing.
