Game With Purpose

With a focus on cross-platform play and a history in game development giants, our team is creating a movement, powered by games that are just plain fun to play.

Bring down the borders. End the console wars. Pick up your controller and let's game with purpose.

Book Review: The Lean Startup by Eric Ries

By Karol on Feb 6, 2017

After I decided to co-run a business, I quickly realized I knew very little about actually running a business, let alone a (hopefully) successful tech startup. So I decided to start reading various business/productivity books to help me figure out how to run a company well.

The first book I read was called The Lean Startup by Eric Ries.

Eric Ries is one of the founders of IMVU and came up with the Lean Startup framework in which a lot of tech companies are built on today. Overall the book is an excellent read and I recommend it to anyone looking to make a tech startup, or even anyone in tech who is interested in how to innovate at their workplace, regardless if they’re part of a large organization. One of the first things you learn in this book, is that startups can exist both in actual startups and within large organizations.

The Lean Startup is basically split into two parts: the part where the author explains how the lean startup methodology works, and the part where he provides case studies from various companies and why they did/did not succeed. For each new idea Eric introduces, there is at least one example of a company that has tried that technique and has either succeeded or failed at implementing it. I started reading this book for the methodology, but finished it to read all the company examples. Without the examples the book reads more like a textbook and the examples provide a nice break between the concepts.

One of the most compelling examples I read was that of Dropbox’s MVP. A MVP or a minimum viable product, is a product with just enough features so that you can start receiving feedback from customers and iterating on it. A company’s MVP is also typically used as a proof of concept for whether or not people actually want/need the product.

MVPs are typically prototypes built within a few weeks to months of coming up with the idea. However, Dropbox had a hard time actually coming up with an MVP since the coding required even for the most basic features would have required months and months of work. Also investors just had a really hard time visualizing the fact that you can sync your files to Dropbox and they would just magically appear on your other devices. At the time there wasn’t really any cloud storage based systems so it just seemed impossible.

But Dropbox found a way - their MVP was a video. The video showed exactly what customers would need to do to get their files to sync and the response to it was dramatic. Before they knew it, they had thousands of people signing up to test it. They just needed some way to convey their idea to their customers.

Another interesting example was not really a company example, but one Eric used to explain the power of small batches. Small batches are used regularly in lean manufacturing and allows for companies to receive faster feedback on their product. The basic idea is this: it is more efficient to complete one item from start to finish, then move on to the next item, than it is to complete one part on all the items first, then move onto the next part, then the next part, until all the items are complete (at the same time).

For example, say you want to mail out flyers to 100 people. This includes folding the paper, putting the paper in the envelope, stamping the envelope and finally, sealing the envelope. Naturally we would think it would be faster to fold all the paper at once, then put all the paper in all the envelopes, then stamp all the envelopes, etc. However, it is actually faster to prepare the envelopes one at a time. This youtube video actually demonstrates this if you don’t believe me:

The thing that we don’t think about when working in large batches, is how much time we’re actually spending on managing the products in between each step of the process. We don’t think about how much time is wasted stacking all the papers after folding them, then stacking the envelopes after putting the paper in them, then stacking the envelopes again after stamping them. Each step doesn’t seem like that much work, but when put together, they make a difference.

While the examples are about specific topics, the book overall really tries to prove that successful startups just don’t happen randomly. Successful startups are a product of hard work, listening to what the people want, and being able to pivot if you need to. If your product is a sinking ship, you shouldn’t be going down with it. You should see why it’s sinking, see if it can be repaired, but if not go find a new ship. Having that flexibility will help you find the right product that will sell, which is much faster than trying to make something work that just won’t.

Overall, I give this book two thumbs up. I think the only times I was reading this book where I didn’t learn something new was when it was explaining agile development and the concept of A/B testing. Otherwise, it taught me a lot about how startups are different, how to actually measure success and if you make it big, how to keep innovating within your organization. I took about 7 pages of notes and I am sure I am going to reference them all the time.

Next up in my line of business/productivity books is the revised version of “Getting Things Done: The Art of Stress-Free Productivity” by David Allen. So be on the lookout for that review some time in the future!

Share this post:
comments powered by Disqus