Sachin Rekhi

Every week I meet with different entrepreneurs asking for my advice on topics ranging from funding strategy, exit opportunities, user acquisition, monetization, to technology investment. However, unlike others who often have a set of best practices they like to dispense around these topics, I find myself spending a considerable amount of time understanding the entrepreneur's personal goals before laying out my recommendations.

Entrepreneurs come in all shapes and sizes and there are a variety of successful outcomes that can be achieved. It's therefore important to be wary of anyone that gives you one-size-fits-all advice before understanding your needs.

One dimension along which I wanted to elaborate is a founder's choice to optimize for building fundamental vs strategic value. Let's start with some definitions. An entrepreneur that focuses on building fundamental value is optimizing for creating a standalone business that generates meaningful cash flow and profit as an independent entity. On the other hand, an entrepreneur optimizing for strategic value is one that is building their organization in such a way to maximize potential value to a larger organization that will ultimately benefit from an acquisition of the entrepreneur's startup.

Lately I've been spending time thinking about freemium business models and how best to structure them to maximize conversions. I believe we are still early in our understanding of these models and to date most of the available analysis has been limited to anecdotal evidence, one-off case studies, tips & tricks, and a few early overviews of what's been tried.

Despite this I think we are starting to see some interesting emerging design patterns and best practices coming together. I wanted to discuss one such design pattern, including examples of it's usage and potential limitations.

One of the segmentations that is often talked about among Chris Anderson, Eric Ries, etc. is dividing freemium plans into 3 main tiering types: time-limited, capacity-limited, and feature-limited. Canonical examples of each include 30-day trials for 37 Signals' Basecamp, storage space limitations for Dropbox, and mobile access for Remember the Milk, respectively.

One variant of capacity-limited freemium tiering that is particularly effective for products targeted at the SMB market is to scale pricing with customer success. What I mean by this is providing various premium tiers of your product that will become appropriate for your customer as they are more successful in their own business. Typically this means tying the tiers with capacity-limits that either directly reflect or proxy the customer's growth in their own user base or revenue.

As many of you know, I'm a huge proponent of on-demand computing as I believe it's the best starting point for most early stage web startups. Cloud computing allows a venture to substitute high initial capital expenditures for operating expenses that grow proportional to your traction. Equally important is its ability to flexibility scale and retract with the ebb and flow of your business. While it may make sense at a later stage to move to your own data center as you look to optimize costs, it rarely should be a priority in the tumultuous early days when you are still searching for product/market fit.

At my previous startup Anywhere.FM, we were an early adopter of Amazon Web Services in 2007. I've continued to be an early adopter of next generation cloud platforms as I'm always interested in understanding the bleeding edge innovations. Last year I initially saw a lot of promise in Google App Engine, but ultimately chose to abandon it due to its shortcomings. Just recently I tried the Rackspace Cloud, which is shaping up to be the fiercest competitor against AWS. I thought I'd share my experience with you.

Over the past two decades we have seen an evolution in the way we discover the content we consume online. I wanted to chronicle this evolution as well as offer a better way to take advantage of the next chapter in content consumption.

As many of you know, I'm a big proponent of open platforms and have spent much of my career designing, building, or leveraging open platforms and APIs. While we have seen explosive growth in social platforms over the past several years, I believe they are still very early in their history.

I wanted to put out my 5 social platform predictions for 2010, as I think we are poised to see another exciting year of innovation.

After last week's post I got quite a few folks asking me what exactly is an Entrepreneur-in-Residence. Since I didn't describe it in my previous post and there isn't very good information out there about the role, I thought I would provide an overview, it's benefits, and drawbacks.

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 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.

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.

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.