Maximizing Value from an Enterprise Wide Application Platform

I woke up this morning thinking about microeconomic pricing theory , specifically price elasticity of demand.  That’s not actually true.  I really woke up thinking about the Superbowl and how the Pat’s were going to dominate, but then I started thinking about pricing.  I’m pretty sure this was stimulated by two conversations I had last night.  The first was with one of our Solution Providers who was trying to convince me he couldn’t sell QuickBase across an Enterprise because our per user pricing was too low for the potential value and the CIO was skittish – classic Veblen reaction.  The other conversation was with a CIO who didn’t want to roll out QuickBase to his entire org, because he was afraid that QuickBase would be so pervasive throughout his company that it would essentially become price inelastic and we could charge him anything we wanted – scary dependency.

Both of these conversations turned out fine, but it struck me that when we’re selling QuickBase across an enterprise, our value proposition is disruptive.  Because of our unlimited application model (we charge for users and you can build as many apps as you want), the potential and/or value of QuickBase at scale is really hard to calculate.  In Business Development, we have to take control of the value discussion from the beginning and make sure our customers understand how unbelievable the unlimited app concept can be. 

Why?  Well, look at the difference between calculating value when you first look at QuickBase and when you look to expand your usage. When a prospect first comes to us, they are most often looking to solve a single problem (i.e. This spreadsheet is killing me – I need a real Project Management solution).  They can get their application working in a few days and then make a simple ROI calculation to see if the price we‘re charging is giving them fair value.

But when we’re spreading QuickBase across an enterprise (or even across a team), it’s different.   A single user may be using 5 or 10 or more QuickBase applications each day to be more efficient.  How do you calculate the ROI on that when the per user pricing is fixed?

So my cop-out answer is – value is directly related to use.  With unlimited applications you have unlimited potential and unlimited potential value.  The only thing that matters is that you use the product – and use it heavily.  This is one of those cool economic models when both QuickBase and the customer are getting awesome value.  So build more applications – more and more and more.  Spread them to as many people as you can.  The more apps you build and the more users you spread it too, the more value you get – and even better, your price per user goes down.  When you use QuickBase more, we penetrate more advocates which spreads to more users.  We have many customers extracting insane value from QuickBase and we love it!  Win-Win!

  • gareth

    What do you think about Amazon’s per-use (not per user) pricing model for EC2?

    (http://www.amazon.com/gp/browse.html?node=201590011)

    For folks who are able to use EC2, it seems like it will drastically reduce costs. It won’t be just individuals who use EC2; companies – e.g. http://www.enterprisedb.com – will host very large and complex services on there.

    [Reply]

  • gareth

    What do you think about Amazon’s per-use (not per user) pricing model for EC2?

    (http://www.amazon.com/gp/browse.html?node=201590011)

    For folks who are able to use EC2, it seems like it will drastically reduce costs. It won’t be just individuals who use EC2; companies – e.g. http://www.enterprisedb.com – will host very large and complex services on there.

    [Reply]

  • Alex Chriss

    Hi Gareth. I love the per-use model! It makes perfect sense for out-sourcing your servers or when you have a specific application that is being used by thousands or millions of people and per user pricing would be cost prohibitive. My guess is you’ll see a lot of ISV’s moving towards platforms that offer pay for what you use pricing.

    I’m not sure it works as well for the end-user (a business or consumer), as I think they need something that’s understandable and predictable. I’m willing to pay $XX/mo for my 100 users to use a CRM app, and I know exactly what my incremental cost is to go add one more user. I’m not sure I’m as comfortable paying for my sales team on a “bandwidth” model.

    I wonder if Starbucks would ever move to a pay for what you consume model? hmmm…

    [Reply]

  • Alex Chriss

    Hi Gareth. I love the per-use model! It makes perfect sense for out-sourcing your servers or when you have a specific application that is being used by thousands or millions of people and per user pricing would be cost prohibitive. My guess is you’ll see a lot of ISV’s moving towards platforms that offer pay for what you use pricing.

    I’m not sure it works as well for the end-user (a business or consumer), as I think they need something that’s understandable and predictable. I’m willing to pay $XX/mo for my 100 users to use a CRM app, and I know exactly what my incremental cost is to go add one more user. I’m not sure I’m as comfortable paying for my sales team on a “bandwidth” model.

    I wonder if Starbucks would ever move to a pay for what you consume model? hmmm…

    [Reply]