Lessons Learned as an Entrepreneur-in-Residence
As many of you know, I spent the better half of 2009 as an Entrepreneur-in-Residence at Trinity Ventures. It was one of the most rewarding experiences I've ever had and would encourage anyone who gets the opportunity to do it. Working alongside Gus Tai, Ajay Chopra, Jim Tybur, Dan Scholnick, and the rest of the Trinity team provided an inside look into the world of venture capital. Given that I've spent most of my entrepreneurial career in scrappy startup environments, I developed a valuable new perspective on evaluating opportunities.
I thought I would take a moment to share some of the most compelling lessons I learned during my Entrepreneurship-in-Residence.
I thought I would take a moment to share some of the most compelling lessons I learned during my Entrepreneurship-in-Residence.
The PayPal Wars and its Lessons for Today's Entrepreneurs

I was perusing Andrew Chen's bookshelf and came across The PayPal Wars by Eric M. Jackson. It turned out to be a riveting tail of the entire journey of PayPal, from its early conception to its monstrous success, retold by one of its earliest hires in marketing. It's a story I thought I knew, but there was so much more to it than the simple success story we all hear about.
I thought I'd take a moment to reflect on the five most important lessons I learned from their journey and my thoughts on their application to today's entrepreneurs.
Goodbye 2009 and Welcome 2010
It has been exactly a year since I started this blog, as it was one of my new year's resolutions for 2009. So how did I do? Well, I'd say it went as well as a typical new year's resolution: highly motivated at the beginning with great progress in the first half of the year, then the consistency started to lapse, with eventual abandonment towards the last quarter of the year. All told I authored 23 posts, which is almost 2 posts/month, though they heavily skewed towards the first half of the year.
Google App Engine Task Queues, Push vs. Pull Paradigm, and Web Hooks
Despite my post last week on the Shortcomings of Google App Engine and my decision to move away from it as a viable platform for upcoming projects, I have been impressed with the overall architecture and design of their experimental Task Queue API.
Google throughout its years has been a leader in interface design and that has been reflected not only in the UI of the products they have built, but the countless API interfaces they have published. Google has made available some of the most easy to use yet powerful API interfaces. A clear focus on leveraging open standards where possible has helped them along the way. Google App Engine is probably the strongest testament to this, allowing developers to quickly build web applications that scale to millions of users on an easy to use Python or Java runtime environment. Their latest experimental design for the Task Queue API in Google App Engine is no exception.
Google throughout its years has been a leader in interface design and that has been reflected not only in the UI of the products they have built, but the countless API interfaces they have published. Google has made available some of the most easy to use yet powerful API interfaces. A clear focus on leveraging open standards where possible has helped them along the way. Google App Engine is probably the strongest testament to this, allowing developers to quickly build web applications that scale to millions of users on an easy to use Python or Java runtime environment. Their latest experimental design for the Task Queue API in Google App Engine is no exception.
Shortcomings of Google App Engine
As many of you know, I have been a huge fan of Google App Engine. I love the vision and truly believe its the first real platform-as-a-service as opposed to the other dominant cloud platform Amazon AWS. While AWS has significantly moved the industry forward with on-demand virtualized instances and cloud storage, it has not developed a fully scalable runtime environment comparable to Google App Engine. Sure Google App Engine only supports a very restricted use case and set of technologies, but constraints can be liberating. If the scenario fits for your web app, the freedom to focus on your app and not on infrastructure and scaling is very compelling.
Thus far I've created a variety of small production apps on app engine, including this blog, TuneChimp, and MonkeySort. I am now in the process of embarking on a large project and have been planning on using Google App Engine for it. However, I have run into a variety of shortcomings in GAE that currently and for the foreseeable future seem insurmountable. It has led me to have to reconsider my platform choice for this project and at this point relying on Amazon AWS (or an alternative cloud platform) seems like the ideal option.
For those also considering building applications on top of Google App Engine, I wanted to discuss these shortcomings so that you can make an informed decision when making your own platform choice.
Thus far I've created a variety of small production apps on app engine, including this blog, TuneChimp, and MonkeySort. I am now in the process of embarking on a large project and have been planning on using Google App Engine for it. However, I have run into a variety of shortcomings in GAE that currently and for the foreseeable future seem insurmountable. It has led me to have to reconsider my platform choice for this project and at this point relying on Amazon AWS (or an alternative cloud platform) seems like the ideal option.
For those also considering building applications on top of Google App Engine, I wanted to discuss these shortcomings so that you can make an informed decision when making your own platform choice.