Sachin Rekhi

Optimizing for Fundamental vs Strategic Value

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.

When superficially looking at these definitions, one could argue that every startup is in the business of generating profits and therefore all startups are focused on building fundamental value. In addition, one could also argue that these are not mutually exclusive and ideally when an organization is building fundamental value they are also increasing their strategic value for potential acquirers. While both of these statements are true, the reality ends up being much more nuanced.

With the nature of startups having limited resources, entrepreneurs find themselves either consciously or unconsciously biased towards optimizing for fundamental or strategic value. With every decision an entrepreneur makes comes a set of trade-offs that could result in the maximization of either of these types of value. And a lot of my advice on the topics above depend on which direction you go. For example, your funding strategy may vary significantly depending on the outcome you are optimizing for. The timing in which you choose to focus on monetization may also differ depending on this strategy.

Let's take a look at some concrete examples.

Last.FM, a social music service founded in 2002, was ultimately acquired by CBS Interactive for $280M in May 2007. I remember chatting with Michael Marquez, who was in charge of the acquisition at CBS, about why they ultimately decided to purchase Last.FM. As a media conglomerate, CBS was very interested in aggregating meaningful target demographics that they could monetize by leveraging their existing sales force and brand relationships. At the time Last.FM had one of the largest online music communities. In addition, Last.FM had experimented with a variety of ad units and had shown some initial traction on ability to monetize it's inventory. However, Last.FM had not built out a large sales team nor was it already making meaingful revenue. It had simply shown that it worked on a small scale, which ultimately proved to CBS that if they married their own large sales team with the Last.FM inventory, it could be a match made in heaven. Last.FM's decision to focus on growth at the time clearly helped to boost it's strategic value. In addition, it's revenue experiments without huge investments in building out a large sales organization also improved strategic value.

imeem, similarly, optimized for strategic value. While imeem was interested in reaching profitability to ensure its on sustainability, it nonetheless regularly made decisions to trade-off short-term profitability for maintaining strategic value. For example, imeem could have chosen to stop servicing international markets that were shown to have little monetization potential, yet continued to do so in order to maintain its large user audience that could be attractive to an acquirer. Similarly, when imeem's VIP subscription service started to show traction, imeem could have decided to push more free features into the premium service in order to boost revenue, but leadership chose not to out of unwillingness to alienate it's large free user base. Unfortunately in the end for imeem this bet did not pay off since the market for such media acquisitions softened, imeem was unable to prove profitable per unit economics to potential acquirers, and it simply ran out of cash to continue fighting the good fight.

LinkedIn, on the other hand, continually shows that it is focused on building fundamental value. LinkedIn has been profitable for years and many say it's an ideal IPO target. While they are in no rush to actually pursue the IPO, the decisions they make on a day-to-day basis are optimizing for fundamental value. One example of this is their API platform. While they have finally released an API platform, it is by no means as open or powerful as similar platforms from other social nets like Facebook and Twitter. And in many ways it has to do with the fact that LinkedIn has existing revenue lines from paid subscriptions for pro users and recruiters, as well as licensing and advertising revenue, which they are unwilling to sacrifice simply to provide a more open API to their users. Some may argue that this is shortsighted of LinkedIn in that a more open API may result in an ultimately more profitable business, yet you can't argue with the fact that LinkedIn is consciously making the trade-off to continue to maximize it's fundamental value over all else.

My point with these examples is to show how decisions are made in startups every day that trade-off fundamental vs strategic value. There is no "right" answer on whether to optimize for one or the other. It depends on a combination of the founder's personality, risk tolerance, desired company culture as well how best to reap the value in the specific opportunity one is pursuing.

In the end though, the answer I hear most frequently from entrepreneurs is that they are pursuing fundamental value but are opportunistic about considering strategic opportunities. On one hand this is a very reasonable answer as entrepreneurs don't want to take options off the table. But at the same time, it's really a non-answer and I urge entrepreneurs to consciously realize what they are currently optimizing for in the decisions they make every day.

Freemium Design Pattern: Scale Pricing with Customer Success

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.

What's nice about this model is that it appropriately segments your potential customers into pricing buckets by ability and often willingness to pay. Businesses that are just getting started, pre-revenue, or early in finding product\market fit can often leverage your product as part of the free tier or low priced tiers. This provides few barriers to adoption and get's them quickly onto your product. And as their business scales, they'll think twice about switching since they've already been successfully using your solution. On the other hand, larger businesses will pay against a higher tier appropriate for their level of success.

Let's take a look at 5 different products targeted at SMBs that leverage this freemium design pattern.



Mixpanel offers a sophisticated set of analytics tools that picks up where Google Analytics leaves off. It often replaces hard-to-maintain home-brew solutions that companies put together themselves. Mixpanel works by allowing you to instrument your application to track custom data points and then does all the data crunching and segmentation to present the data in an easy-to-consume fashion.

The way their pricing structure works is by pegging the monthly subscription rate to packages of tracked data points. The free package provides up to 10,000 monthly data points. The next package allows 100,000 data points for $25/mo. And so on. While the number of data points collected does depend on how many individual event types you wish to track, the biggest determinant is total number of users using your service and you'll likely only scale to a larger plan when you reach new customer segments. Thus tiering on tracked data points provides a close proxy for their customer's own success in user growth.



Recurly is a service that makes it easy for SaaS businesses to manage their customer's monthly recurring subscriptions. Since billing is not where a service wants to innovate, Recurly provides a great solution to let them take the load off of managing this part of their business.

Recurly's fee is based on number of subscriber's to the customer's business. If your business has less than 50 customers, then Recurly is free. Above that amount, the Recurly monthly subscription ranges from $28-$2,650, depending on various bucket sizes for number of customers. So their pricing structure directly reflects the user growth of their customers.



MailChimp is an e-mail marketing solution that provides e-mail list management, an html editor for designing your e-mails, and detailed email analytics.

MailChimp offers two pricing plans, one based on total mailing list subscribers and the other based on volume of e-mails sent. While one is a direct reflection of customer user growth, the other is a close proxy, thus causing the cost of using MailChimp to increase as your customer's user base continues to grow. Their free plan allows managing and sending monthly newsletters to a list of up to 500 subscribers.



UserVoice is a customer feedback solution that allows you to easily collect, aggregate, and make your user's feedback actionable.

UserVoice allows you to setup a free forum for your customers to supply their feedback. One of the biggest values that UserVoice provides is allowing users to vote on the various feature requests. And it's the number of potential voters that UserVoice divides it's various freemium plans along. Your forum gets 100 voters for free. The premium tiers then allow various numbers of additional voters. The number of voters you will need at any given time is designed to be a function of the customer's own user growth, with UserVoice even detailing that they expect on average 3-7% of your user base to become voters.



FreshBooks provides an invoicing solution for consultants, contractors, freelancers, etc. to make it simple for them to generate, send, receive payment for, and track the entire invoicing process.

FreshBooks tiers it's offering along the obvious scheme of number of clients. You get to invoice up to 3 clients for free and additional premium tiers allow various numbers of additional clients. As your business clients grow, so does the fee you pay to FreshBooks for supporting you.

Limitations
There are a variety of reasons why such a freemium scheme may not be appropriate for your product as well as additional considerations to carefully evaluate before implementing.

Customers may not be very amenable to such a pricing scheme if they did not perceive additional costs for you to offer them support for a larger customer base. But it is often the case that your own costs scale in proximity to this tiering.

At the same time your costs may end up scaling along another axis tangential to growth in customer's own users and revenue numbers and this may make it difficult to leverage this tiering scheme. But keep in mind that you should be looking at costs in aggregate over your entire customer base and not just for individual tiers.

This freemium design pattern does not remove the essential critical question in every freemium tiering scheme, which is where to divide the free and paid plans. While this design does give guidance on along what dimension to segment, you still are free to decide what capacity each plan allows. Is MailChimp giving away too much with allowing 500 free subscribers? Is FreshBooks being too restrictive by only allowing 3 free clients? These are tough questions that remain. And despite our industry's best efforts to optimize through analytics, I've seen very little effective A/B testing done along pricing tiers. The difficulty arises from significant user backlash resulting from taking away features from a free plan.

Also along these lines, if your product ends up being applicable to a wide range of organizations and business sizes, there may not be a way to easily design a free plan that allows every organization to try it out. For many user segments they may just see your service as a SaaS offering with no free level. While this may be advantageous to you overall, it does limit many of the benefits of allowing all users to start for free.

I'd love to hear your feedback on other considerations you think are important when evaluating this freemium design pattern. As well as other patterns that you think have worked well.




I also wanted to mention that I've very excited that Charles Hudson this year is putting on The Freemium Summit. As this business model and marketing strategy reaches heightened interest across consumer and business applications, the time is ripe to bring together the early implementors and thought leaders in the space to discuss these exact design patterns and overall benefits and drawbacks of freemium models.

The Freemium Summit has already put together a great set of panels with speakers including leaders from some of the products mentioned above:

• Ben Chestnut, Mailchimp
  
• Lance Walley, Chargify
  
• Isaac Hall, Recurly
  
• Drew Houston, Dropbox
  
• Peter Harrison, TripIt

If you are interested in attending, you can use the following link with the code SACHIN to recieve a 10% discount on general admission:

http://freemiumsummit-sachin.eventbrite.com


Freemium Resources
I've also provided a list of articles that you may find helpful in thinking through your own freemium model design.

• Charles Hudson: Thoughts on Free Powered Business Models and Why Time Beats Features
  
• Eric Ries: Three Freemium Strategies
  
• Andrew Chen: How to Create a Profitable Freemium Startup
  
• 37 Signals: The Secret to Making Money Online
  
• Chris Anderson: Free: The Future of a Radical Price
  
• Fred Wilson: The Freemium Business Model

Why I Abandoned the Rackspace Cloud

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.

What Attracted Me
Rackspace is not shy about looking to compete aggressively against AWS. They offer on their website a detailed head-to-head comparison with Amazon's EC2. While they suggest a variety of reasons why you might choose Rackspace over EC2, there was one specific advantage that caught my eye and ultimately led me to run a full-scale test on Rackspace. It was the fact that Rackspace offers cheaper low-end server instances that may be all you need for certain tasks. While Amazon's cheapest instance starts at $63.24/mo (1.7GB RAM) for continuous running, Rackspace's cheapest instance starts at $10.95/mo (256MB RAM). For certain tasks that are not CPU or memory-bound but instead network bound, the low-end Rackspace instances may be sufficient and cost effective. Given this fit the characteristics of my workload, I decided to shift some of my resources to Rackspace. I ultimately expanded to a farm of 8 low-end Rackspace instances for a full month.

Why I Abandoned
Given that I've been on Amazon Web Services for years now, my expectations for a cloud platform are high. And unfortunately the Rackspace Cloud ended up falling short for my needs.

One drawback that completely surprised me was the lack of reliability of the servers. This shocked me given Rackspace's long history of being the underpinnings of some of the internet's largest sites even before they launched their cloud offering. But I regularly would receive e-mails like the following:


I received 13 such required reboot notifications during the 33 days that I had instances live on Rackspace! Talk about a maintenance nightmare!

Rackspace also has some pretty restrictive limitations on backups and images created on instances. First, a backup of an instance is always tied to a particular instance. So say for example you setup and installed all the appropriate software like I did on one instance. Then you took a backup of that instance so that you could deploy additional servers based on the backup. Today you cannot delete the instance from which the backup was created because if you were to do so, you'll lose the backup! So as long as you want to create future instances based on that image, that instance has to live on. This is due to the strong coupling of servers and backups.

Related to this issue is the fact that you cannot share images with others. This means that any software you want on the box you have to install yourself instead of potentially taking advantage of someone else's work.

This is in contract to Amazon's strong Amazon Machine Image ecosystem. I personally use the great CentOS images from RightScale. This is just not possible on Rackspace.

While Rackspace does plan on addressing both of these issues, they have a ways to go to catch up with Amazon.

The amount of disk that you can have associated with a given Rackspace server instance is based on the server instance package. So if you require more disk space, you'll have to upgrade to a larger instance size and resize your server. While this does mirror most hosting providers, it falls short of the compelling offering of Elastic Block Storage that Amazon provides. Elastic Block Storage is completely resizable persistent storage that can be attached to any Amazon instance, with easy backup, redundancy, and re-attachment to\from different instances. It's great for storing the data files for a database server, for example, and allowing it to grow as necessary. I definitely missed this when I was on the Rackspace cloud.

Much of my workload involves making requests to third party APIs or scraping web pages. This results in significant network bandwidth both into the box and out of the box.

Currently Amazon is more price competitive on this front. AWS is currently offering completely free data transfer into EC2 instances for the first half of 2010. Compare that to Rackspace's $0.08/GB. In addition, EC2 charges $0.15/GB transferred out, versus Rackspace's higher $0.22/GB transferred out.

For these reasons I have ultimately decided to abandon the Rackspace Cloud. While none of them were deal breakers themselves, there wasn't enough compelling reason to move my infrastructure away from AWS.

What I'll Miss
Despite abandoning the Rackspace Cloud, there are definitely some aspects I will miss.

Rackspace doesn't lie when they say they have fanatical support. Because they really do. I signed up for Rakcspace at midnight on the weekend and I still received a friendly call from a Rackspace agent to confirm my identity and ask me if I had any questions about the service. And this wasn't an offshore calling center either. It was a very knowledgeable American representative.

Similarly, they have always available Live Chat that I have taken advantage of on multiple occasions. Why waste time digging through forums to try to find an answer to your question when you can ask extremely helpful and expert chat support staff immediately? Compare this to AWS, which charges significant additional fees for that level of support.

While the server backup system does have its limitation, it was refreshingly easy to setup. Just tell it in the control panel to backup daily and you are all set! Compare it to the details in this article for getting reliable backups on AWS.

Something so basic that was again very refreshing was the ability to provide easy to remember names for your server instances. AWS can be frustrating at times to look at the Control Panel and simply see instance IDs like i-462e3b1e, leaving you wondering what exactly is running on the instance.

While I have decided to abandon the Rackspace Cloud and stick with AWS, I'm sure I'll be re-evaluating Rackspace as it matures. Nonetheless I'm excited to see strong competition in the marketplace since it forces all cloud providers to continue to innovate. I expect to continue to see significant advancements in the space from all the major vendors as they evolve.

Related Posts

• Shortcomings of Google App Engine
• Google App Engine Task Queues, Push vs. Pull Paradigm, and Web Hooks
• Is Google App Engine Ready for Prime Time?