Tag Archives: value chain

Why Groupon is worth 100x more than MySpace

groupon_morethan_myspace-200px_highMySpace—founded in 2003—was one of the “original” big social media players. Its purchase by News Corp for US $580 million in 2005 launched a social media “gold rush.” Six years, later it is on the sales block for $50 million to $200 million (even though if has more than 42 million active unique monthly visitors). Meanwhile, Groupon—launched in 2008—is already floating the idea of a US $15 billion IPO with Goldman Sachs.

How did a company like Groupon create 100x the investor value so quickly? It was not simply second-mover advantage (i.e., building a better network). Instead it focuses on social networks as a “means” to creating value, not an “end” in itself.

Moving social networks from an ‘end’ to a ‘means’ of doing business

When talking about social networking, social media, Web 2.0, etc., a lot of people fall into the trap of citing Metcalfe’s Law, that the value of the network is proportional to the square of the number of connected members. Under this assumption, a social network with 42 million active monthly users (e.g., MySpace) would be roughly 7x more valuable than one with 16 million (e.g., Groupon).

Obviously, this assumption does not hold. The reason why is simple: the value of all network connections is not the same. On the top line, a connection that drives commerce purchases generates much more revenue than one that simply increases advertising click-thrus. On the bottom line, a connection that only communicates 140 text characters costs much less to deliver than one that streams video.

Thinking about this from the start

This provides a valuable lesson when using social media to create value:

  1. Don’t just focus on the number of members (or connections between them)
  2. Instead, focus on maximizing the net value of the connection between members: not just your revenue minus cost, but also the value your members perceive of the connection vs. the effort required to maintain it
  3. If you do this, your members (and partners) will organically grow (because they value your network)

Combined, “large numbers of connections” X “large value per connection” = “large network value”.

This is why Groupon created so much value so quickly. It is also a lesson to those who will take through social media the next stage of the technology adoption life cycle: focus on using social media as a means to connect and create value, not just an end in itself.

Nine software pricing models evaluated

Pricing software has always been an interesting exercise. The marginal cost to copy and provide software is virtually zero. However, the cost to develop it—and the value of the intellectual property that goes into its creation—is far greater. These two tensions have created a range of models that vendors use to price software. This post evaluates several of these, highlighting ideal (and non-ideal) markets for each.

1. Open Source (or “Software should be free.”) There are many proponents of this – based both on economic philosophy as well as the concept of social production. However, free software does not work – at least for anything that is important to the enterprise. It creates no economic incentives for someone to support you (through documentation, bug fixing, advice, etc.) I do not see this becoming a winning model (unless we fundamentally change our world economy to something from the UFP or Animal Farm).

2. Price per CPU, server, CPU cycle, etc. This model creates interesting incentives: the less scalable your software is, the more CPUs your customers need, the more they pay. As such, it only works in a few places. For utility applications (e.g., web servers, database servers) it is fine, as it encourages vendors to compete to provide the best performing utility. For enterprise applications it is terrible, as it rewards poor performing software.

3. Pricing per unit time. I know—this is from the Main Frame Age. However, it is coming back in some cloud computing circles. Just like pricing per CPU it only makes sense for utility applications. It does not for enterprise applications.

4. Pricing per end user. This model makes sense in the consumer market, as each person who uses the software pays for it. However, it is less suitable in the enterprise market. Many enterprises employ multiple people to work, from different roles, on the same process. As a result, this model requires them to pay more to perform the function they need (ultimately making the software less valuable to them).

5. Pricing based on type of use, i.e., pricing someone who is a service provider different than an end user. I have seen this model used on occasion in the utility space, where I pay more if I using my database to build services I sell to others vs. services I use myself. Whenever, a vendor presents me with this model, I immediately look elsewhere. If you want me to buy and use your product, let me do so. If you want to treat me as a value-added reseller, incentivise me (instead of penalising me).

6. “New car style” pricing. Yes, I made this term up. It is a term I use for software provides who use very complicate pricing (pricing where the sales representative has to use a web portal or spread sheet to figure out my price). This is as bad of an experience as buying a new car (and very hard to scale from sales force perspective). Keep it simple: it will make it easier for your customers to see your value.

7. Pricing based on value created. This is also an interesting model, where the vendor prices based on how much value it provides. Economically, this provides the potentially for the most economic efficiency. However, value can be very hard to measure – especially between two or more parties. Structurally, this looks more like a value chain partnership than a simple sale. However, a software provider occasionally makes this work; when they do, I applaud it.

8. Utility pricing, i.e., pricing based on consumption. This sounds like SaaS (software-as-a-service) but it is not, it is pricing based on unit of consumption. This is ideal in situations where customers can provide a value on each transaction (i.e., it is great for PayPal but terrible for Microsoft Word). It is similar to pricing on value, but prices on the process input (rather than the output) something that can be much clearer to measure.

9. Pricing as a tax. This model is not used much. It is basically pricing unlimited usage of software as a percentage of the enterprise’s revenue, operating budget or some other metric (e.g., headcount, payroll). The big challenge of this is picking the time interval for measurement and billing. However, it can make the value of your software much clearer for C-level decision-making.

You will notice I did not discuss the concept of on-premise vs. SaaS vs. hosting. I did this on purpose. These are delivery mechanisms, not pricing mechanisms. It is important to separate the two, as it allows customers to evaluate your software based on its value (i.e., price) and most effective means of delivery.

Authors Note: I am sure a missed many models. I encourage you to comment; not only on the above, but on items I may have missed. Thank you.