Pricing: Capturing As Much of the Value That You Create As You Can

I’ve wanted to write about pricing for a long time. Finally, I have put together my first piece on a practical framework I’ve seen in action during my career. Pricing is one of the most important and hardest strategies to develop. It goes without saying that a product or company’s revenue is directly a function of their pricing model. Pricing is what drives revenue, margins and profitability.

I am not an economist and do not claim to be an expert in micro-economics, even though I am familiar with most of the basic concepts. In this blog you will not see me recommend that you set your price at the point where marginal revenue = marginal costs. In the world of internet software where marginal cost is usually negligible that concept is somewhat meaningless. Instead…

Pricing is all about capturing the value you create for a customer.

Let me explain the three core concept in more detail: creating value, capturing value and price.

Creating Value:

By definition if you have created a product or service that people are willing to pay for there is some value that you have created which is greater than your customer’s current state without it.  Somehow the offering you have put together is better for your customer than doing nothing or trying to do it themselves.  A few obvious examples are buying a ready-made cake at the bakery instead of baking it yourself.  It may be cheaper to buy all the ingredients yourself and bake it, but it you may not have time or be willing to risk having the cake not turning out as well as the store-bought one. Thus the value created by the bakery is greater than the value of the cake you would make yourself. Net, net it is some combination of costs reduced and/or benefits created that determine the value of an offering to a customer (relative to their current state or substitute option).

We will talk a little more about this later, and without getting into too much micro-economics, the value created by an offering isn’t the same for every customer. This is basically what people refer to as the demand curve. At different prices more or less people will want to buy your product.

Capturing Value

This is one of the most important (and sometimes ‘hidden’) elements of pricing. The essence of which is, given that you create real value for customers (save money, make money, other valued benefits that are delivered) is how can you capture as much of that value that you create for customers?  Is there a way to tie the price your charge to the value created for your customer? This may sound obvious and easy, but it isn’t. This is especially true if there is a big range of value created for different customers for the same product. A great example of this is Microsoft’s Excel. The value to a college student using Excel to do homework assignments etc. at school are very different compared to a management consultant building a sophisticated M&A model – yet the price is essentially the same for the two different types of customers (ignoring the small price difference between MSFT business vs. school edition of Excel).

Furthermore, a concept I like to refer to as ‘metering’ is how a product ties its price to the value it creates for customers. An easy example of this is buying a box of cereal. The metering device is the physical box that the cereal comes in that sits on the shelves at a grocery. There are usually several sizes at different price points based on the volume that you are buying. Another historically great example of metering to capture value has been the phone company. They were able to charge for long distance telephone calls where the phone company metering device was based on both the duration of the phone (i.e. number of minutes) and the distance between the callers. The phone is one of the greatest inventions but without having metering devices built in, the phone companies may not have been able to generate as much revenue. (Of course the world has change thanks to VOIP technology so this example is not as black and white as it used to be thanks to All-You-Can-Eat pricing, Vonage and Skype).  I will touch a little more on this later, but building in pricing-related metering devices to capture value is a critical investment for a technology company.

Price

I am sure this is a gross over-simplification of different pricing strategies, but in my real-life experience in consumer products, enterprise and online software there are basically four ways to look at price.

They are:

  1. Pricing relative to costs
  2. Pricing relative to competition
  3. Pricing relative to value
  4. Psychological pricing

I won’t spend much time on 4. Psychological pricing which entails things like fashion and status related items or specific price points like $9.99 for a book or $0.99 for an iTunes song.  These are special pricing types and I am sure there are other sources of well-research experts who can explain these less tangible and sometimes more tactical price points. Instead I will focus on the first three.

Other elements I won’t touch on here are price optimization, which to me has more to do with price elasticity (to be covered an upcoming blog) and bundling. These two concepts are ‘click down’ components that get deeper into the mechanics of your pricing strategy once you have your basic principles figure out.

1. Pricing relative to costs

This is pretty much what it sounds like – you figure out what your costs are and the determine the margin that you would like to achieve. In many industries there are standard margin expectations. Not sure how these have held up over time, but the rules of thumb I have used historically were professional services at 50%, retail food/CPG 30%,  restaurants 60%. I am sure I am over-generalizing, but this type of pricing easily applies to when your customer can easily do the math on how much it would cost to find an equivalent solution to yours on their own.  Since it usually isn’t worth the effort for them to build vs. buy they will choose to buy yours solution if the margin premium you are charging is reasonable. Pricing relative cost is also frequently used in commodity-like markets where there are many suppliers offering a very similar, mostly undifferentiated solution compared to yours.

2. Pricing relative to competition

The basic premise of pricing relative to competition is looking at direct competitors and substitute products for yours. For example, if something breaks in your TV or game console and you go to a repair shop to get it fixed you will compare how much they will charge you to buying a new one (all else being equal).  When I worked at Kraft I was involved in launching a new dessert product and we compare equal servings of bakery desserts, versus packaged desserts versus from-scratch to get the spectrum of competitive prices to see where we would fit in.

Another example is video games. For simplicity sake let’s say Madden Football or Call of Duty costs $50, most buyers will ask themselves will I spend at least 10 -15 hours playing this game?  Why? Well because they are probably comparing the entertainment value of the game versus going to watch a movie in a theater. Assuming each movie cost about $10 and lasts a couple of hours, it is pretty easy to do the math on whether or not you think the video game is worth about as much as five movies.

The less differentiated your solution is compared to alternate solutions the more you will end up with this type of pricing strategy.

3. Pricing relative to value

As discussed earlier, this is the case where you try to capture as much of the value (cost reduction and/or benefits created) that you deliver to customers. At Emmperative we tried to price our software based on the value we created. As an enterprise software company our primary value proposition was all about increasing time to market with higher quality for our customers along with some cost savings along the way.  One of the challenges was selling the fuzzy revenue benefits to our pricing as customers focused on the cost savings as a way to pay for our software. In hindsight the primary challenge I think we faced is that we tried to price the software as too high a percentage of the value we were creating. Over the past 10 years I have developed a rule of thumb that you should expect to capture 10%-15% of the value you create for your customer. This way they should easily see that buying your solution will provide an order of magnitude improvement over the current state.  Of course early on you could easily charge a higher percentage due to your first-to-market position, but in the longer run the 10% rule-of-thumb is pretty helpful is assessing the potential for a technology business.

One of the best models in the history of pricing relative to value is Google AdWords. When Google AdWords (and AdSense) achieved scale/network effects their auction-based pricing per click of keywords allowed them to capture almost the entire amount of value their ad/search system created for advertisers. Since most sophisticated advertisers work with some type of Cost-Per-Action the advertiser can easily do the math to figure out the value of each click and bid up to that amount and be happy paying it.  As a result, Google has a near perfect system to capture the value they create all along the demand curve by having different keyword pricing for each advertiser based on what they are willing to pay.  Without scale and network effects that Google has other ad network solutions can’t capture anywhere near the same value as Google does.

Picking the attributes to meter

Sometimes you have the ability to have a very dynamic and flexible price metering capability like auction-style model of Google Adwords or eBay.  But many times you will need to pick specific price points.  Many broad-appeal technology based solutions have a feature based two or three tiered pricing Basic/Premium or Good/Better/Best (as I saw at Intuit with their QuickBooks and TurboTax products) (note: QuickBooks is a great example where the value of QuickBooks for many customers is more than 10X what they would pay relative alternate solutions like an accountant’s hourly rate). This type of pricing basically segments the market into different user types or levels/types of functionality and prices accordingly (and may include a free version a la “freemium model”).  However there are other ways to price beyond feature breadth and depth.  Subscription pricing is usually time-based, enterprise solutions can be based on number of users, and others like Dropbox are based on storage capacity.  Understanding the different types of customers, their segmentation based on usage and profile and what they value is the key to picking which attributes to meter.

Building the metering capability into your product

It’s great that the phone company was able to allow anyone to call anyone else; a phenomenal innovation back in the day. However, the ability to measure the duration of a call and the distance between the callers was just as critical to their success as the actual phone call.  I am sure a large amount of resources went into building these metering measurement and billing systems – maybe even as much effort as rolling out the telephony technology? The point being with all new ways to deliver web-based solutions these days, the effort required to build pricing-related capabilities can be a significant investment. The earlier you include this into your development plans the higher the probability of you maximizing your value-capture.

Putting it all together

Figuring out the attributes you are going use to meter the value delivered to customers and charge for early on is critical to the success of your offering/company.  The earlier you build the metering (and measurement) plumbing into your offering relative to the value you create, the better your likelihood of being able to maximize your revenue potential. My experience has been that putting in the metering and measurement tools take almost as much effort to build into your product as the core functionality of the product. So if you solely focus on building the customer solution you may unknowingly be making major compromises to your revenue potential if you need to retrofit your solution or find a less optimal metering tool to charge with down the road.

Building a great product in a weekend – is it possible?

So I’ve been thinking a lot about advice I have seen on Twitter about getting your product out there super-fast. In particular, I have pondered about the statements that encourage entrepreneurs to build a product in a weekend, launch it, get feedback, iterate and, if you can, charge money for it; all within a few days.

What I’ve been struggling with is:

Is that reasonable? Could we have done that?

Even more so, what kind of traction is reasonable to expect?

How long would it take to demonstrate enough traction to raise an institutional (VC) round from such a fast time to market?

As an early stage entrepreneur we hear a lot about finding the Product/Market fit. Which basically means figuring out if you have solved a problem with your offering that a significant number of people have.  The way I describe it is ‘do we have a winner?’ i.e. is this a winning, big idea concept if we keep going with it?

However, finding Product/Market fit and have a mass-market appeal product are different. You can probably figure out if you have Product/Market fit with Innovators as well-described in the Diffusion of Innovation Graphic:

Diffusion of Innovation

And this is a tremendous milestone in itself, because it is very hard to get product/market fit with any sized market. But then there is the next major milestone which I call 80% product/market fit.

To me, 80% Product/Market fit means that the significant majority of users in your target market can use your offering successfully. In other words it solve the jobs they do in order to want to continue using your product again (and again). This does not mean having certain advanced features that leading edge / pro users want, but solving the problems the vast majority will need in order to adopt your product on a regular basis.

80% Product/market fit from a time perspective can occur somewhere between the latter portion of ‘Early adopters’ and the early ‘Early Marjority’. Why isn’t it a specific milestone on the graphic? Well because I am separating the product development cycle from the customer acquisition and distribution aspects of technology adoption. The graphic shows when users actually adopt the product. The product may be ready for the vast majority at times different from when users actually start using them due to the  acquisition capability of the organization (sales force, channel management, social media etc.).

There is a wide spectrum of what it takes to get to Product/Market fit at the 80% level. While by no means simple, it is pretty fair to say that the timeline varies by the types of offering you are developing. Some very successful products like Instagram, Twitter, eBay, Turntable.fm surely had a much shorter time-to-market compared to complex applications like most EA titles, enterprise software, ad serving technology and popular analytical tools like Google Analytics.  An interesting observation is that many of the companies that have had shorter development timelines seemed to have large amounts of user generated content and participate in markets with network effects.

There are some companies like SAP which started in 1972 and took years to build to solve enough problems (aka ‘jobs’) to become an option for large corporations in the early 90’s with R/3. Most of Microsoft’s products took several iterations to find 80%Product/Market fit.  The period between MVP launch and 80% Product/Market fit could easily be measured in years (decades?).

Why I am writing this post? Well, we certainly could have been in market several months sooner if we just built what we released as our MVP.  As you might recall, after building several workflows, we removed a large amount of functionality for our public release with the expectation that most will be added back in at a later time.  However if we just built the MVP to start I don’t think we would have gotten our Product/Market fit to the 80% level much faster. In fact, we may have slowed it down.

Let me explain…

Because we were designing and building a product that was striving for the 80%, we made several architecture and infrastructure choices and investments that we would not have anticipated upfront had we just been building our MVP.  So while we may have gotten some early traction with Innovators and very early adopters, it may have taken us longer to get to the 80% level by having to re-architect various aspects of our product at a later date (see my post The Biggest Decision). John’s perpective on this is almost always ‘better to do it now while the patient is open’, and after four plus years of working together he is usually right.  Of course, it was very possible we made some investments in areas that turned out to not being needed or important so that may have worked against us. We also missed some feedback that we should have gotten sooner (Launch & Learn – quickly adapting to insights from our users), luckily that wasn’t too costly. However, on balance we feel confident we will move faster once in market to quickly get to 80%.

Since traction is so important, our speed to 80% product/market fit is what we are solving for; so that we get hundreds of thousands of users not dozens or hundreds of Innovators or Early Adopters. If we got the right initial product/market fit then our speed will be the key to our success.

If someone else has a new product that can be built in a weekend and get 80% product/market fit right away (and ideally benefit from network effects) that is awesome, and I commend them with coming up with such a great idea and opportunity. However, those opportunities are rare. I think the significant majority of meaningful companies require several months to get to 80% product/market fit and in many cases even longer.

Getting the right people in the right seats on the bus

One of the biggest challenges in an early stage startup is to have enough talent on the team to do all the tasks required to get stuff done right.  If you only have a handful of people in your company (i.e. four or less) it is almost impossible to have all the skills needed to deliver a new offering, especially if it is some type of consumer application like ours.  So how do you find all the people to do all the work that is needed?

For many years now I have talked to people I work with about people I would label ‘Swiss Army Knives’ and others who I would call functional experts.  Swiss Army Knives are basically like the metaphor suggests, they are talented individuals who can perform multiple types of tasks well enough to accomplish the required objectives. This does not mean that they are experts in any specific functional area, but in a startup environment they are able to figure out what is needed and to make it happen. Almost always Swiss Army Knives are choosing this breadth vs. depth capabilities. My experience is that they are very smart and flexible individuals and if they chose to go deep in any specific functional area (and usually they have at least one or two in which they have gone deep) they would be world class in that area.  I started my career at Procter & Gamble and they really encourage attracting and developing Swiss Army Knives, and a lot has to do with their philosophy of promotion from within, general management skills and an upward spiral career path.  Which basically means that at P&G high performing employees are encouraged to take multiple cross-functional roles during their career as they move up the ladder. Being able to perform well in multiple functions and appreciate different functional roles is a critical leadership and career skill.

A few additional thoughts on Swiss Army Knives, while I don’t have statistical data on this I have found that only a small percentage of people fit this categorization, even in great organizations. What’s even more interesting is that I have found that SAKs tend to find each other and hang out together. I really don’t know why, but it just seems that they tend to have similar values, experiences and outlooks. Also, not being a SAK is not a bad thing either, having deep functional expertise is necessary in almost every company especially when combined with the depth of experience that the SAK will almost never have.

So how does this relate back to driving a successful startup?  Well, if you are small and can only have a few folks working full time in your company I would suggest having as many of your early employees being Swiss Army Knives as possible. By having as many people on your team who are able to get things done (in a ‘good enough fashion) within your team means that you do not have to tap outsiders (contractors, consultants, agencies etc.) to help you get them done.  Kind of obvious, but it all start with who do you have riding on your startup bus.

My partner John is a Swiss Army Knife. Not only can he tackle just about every technical aspect of our product (such as architecture, web service integration, functional coding, presentation layer functionality, HTML/CSS, dB management, operations etc.) he also has a unique appreciation of consumers and marketing from his past experiences. Thus when we discuss new features or user feedback we can immediately have a great, productive discussion about what to build and translate the conversation into new requirements.

However as you grow your startup you can’t do everything yourself and you can’t hire full-time people for every role that need to be done. There are lots of ways to address this issue via contractors, interns, consultants etc.  What we have found to work pretty well for us is using oDesk (www.odesk.com).  We use oDesk for both product development and marketing-related experts. oDesk is a great resource if you use it properly but it is certainly not a silver bullet. In fact, our experience is that unless you put a very big effort upfront into hiring and managing the functional experts you find you will be very disappointed in the results. Leading a team on oDesk takes as much effort if not more effort to coordinate (to account for time zone, language and not being in the same room).  In fact until we developed the right process and tools for the team, it was hard for some oDesk people to succeed was a challenge for them. But as we have found if you get your ducks in a row and find the one or two key people that ‘get it’ and can ‘do it’ the bang that you get for your buck compared to hiring locally really pays off.

To-date, getting the right people in the right seats on the bus has been a long, iterative challenge with our efforts finally paying off. We are happy where we are today, but of course it is a never-ending battle as we try to grow and keep up with all the new changes to our product and small company.

Good luck to you on getting the right people on the right seats on the bus – and may as many of them be Swiss Army Knives as possible.

Launch & Learn – quickly adapting to insights from our users

Well the last month has certainly been very interesting. We launched a Private Beta version of Jernel to a few select folks including a couple of friends who are product design and usability folks. I also set up shop in a couple of Starbucks and did some usability testing with random users in San Francisco and Las Vegas.  It’s amazing how quickly we got consistent feedback from everyone who tried Jernel out.

First the good news, everyone loves the Jernel concept of it being a fun, easy way to share and remember your life experiences.  Then, when we tell them that Jernel also allows you to add on specific Jernels for different life events or hobbies I immediately get their request for some specific type of Jernel that suits their world. Then they send me their email to sign up to be a beta tester. This is awesome, we really couldn’t ask for a better qualitative response.

On the other hand we got very direct and actionable feedback in two key areas:

To start, as easy as our product is to use (as demonstrated by our task completion rate and user confidence) it was still not easy enough. We realized that we still had a gap between ‘Easy’ and ‘Drop Dead Simple’. Thanks to some excellent, actionable recommendations by my design friends and being able to quickly get feedback to the new wireframes with real users we made the decision to make a major UI change to how Jernel entries are added and displayed.  Thanks to the latest jQuery tools and other fancy Javascript capabilities we’ve been able to simplify the Jernel entry process to just a couple of clicks. Luckily these changes are mostly cosmetic at the presentation layer and do not require many changes to the core functionality and as a result we’ve been able to make the changes in just a few short weeks.

The second major theme we heard was all about branding and graphic appeal.  We started from a place where we were making everything customized – each type of Jernel, badges, buttons etc. And while they were generally consistent, they didn’t really have a broad enough appeal or we created user complexity by offering too much choice. So we took that feedback to heart and have tried to solve for the ‘highest common denominator’ in our branding and graphical design. We have simplified our color palette, use of colors and number of badges. While I am not 100% sure that is where we want to be in the long term, to get to a public launch it really made sense to simplify right now and then expand later based on in-market learning.

Net-net, we have dramatically simplified our product for the initial Beta release. In fact, we have stripped out the majority of functionality we have built to get to market quickly and learn from our users.  While we expect to use all the stuff we removed in subsequent realeases, I am sure they won’t necessarily return in their original form but be adapted based on new insights.

The flip side to simplifying functionality and streamlining our branding/graphics within the app is that we’ve made a choice to provide less capabilities and options to our users.  I am expecting us to hear that we over-simplified things and that users will demand more if they are going to make Jernel a regular part of their life.  I am looking forward to that moment because we are ready for it.

The Biggest Decision

So we have been working  on Jernel with our small team since about November. It is now June. We thought v1 would have been completed by March and in reality it won’t be ready until at least next week – so essentially about 3 months behind what we expected. Like most startups we have been trying to deliver a Minimum Viable Product (MVP) for v1 (a la Lean Startup philosophy). The reality is that we are delivering a lot more than an MVP. This has to do with a decision we made a long time ago about how we would architect our product platform.

Let me take a step back and explain.

Last year we had a working model of the Jernel offering and did some user testing which taught us a lot. Not only did we get a feel for what users valued and what they didn’t, we also got a pretty good qualitative feel for the appeal of Jernel. Now past experience has taught us not to overvalue user feedback in usability testing on how well a product will do, but this time was a little different because the sentiment was nearly unanimous and consistent. It has been the same since I have told or shown anyone about Jernel and how it works. I am sure many marketing purists will tell me I should not overweight this feedback – but at this point in time (before we do our next set of user research) I still believe we have something special in development.

After we did the user research I also went to visit a few friends on Sand Hill road just to share with them what we were doing, get their feedback and start having them track our progress. By far the best piece of feedback we received was from a young VC partners at a major firm who suggested we horizontalize our offering and create add-in vertical solutions. This meant that instead of having unique offerings for each vertical to allow users to have a general version of our app and add ‘action packs’ as he called them for each area of interest to the user. “Otherwise you idea seems to narrow” he said. Several other good points were made that I hope to include in future posts.

The main benefit to creating a single product platform would be the ability to only need to acquire customers once and then retain them for life while they Jernel about all their interests in single location. This made a lot of sense given our learning from our first offering.

However, this feedback meant we would need to fundamentally change how we architected the product. Instead of separate instances of each vertical we needed to have a single platform with users would customize by adding the individual verticals that were right for them. This meant the set-up process was to be more complicated and user experiences needed to be adapted to toggle between verticals. It would also mean changing the paradigm the user would need to understand how the product worked. Net-net this added complexity and time to our development.
Now that we have an almost-ready for primetime product it is clear the decision to have a horizontal platform with vertical solution was the most important and best decision we have made so far for Jernel. Without making that choice it is likely we would have created our “start-up ceiling”, limiting our potential before we even started.

Hello world! I’m finally joining the blogosphere

Welcome to my blog! I decided to start one to keep a record of some of the major events associated with launching a new startup offering and also to share some of my learnings along the way. I will also use this space to put down in writing some musings about my other passions. Stay tuned my first real posting will be about the biggest decision we made so far as related to our upcoming launch of Jernel – The easiest way to share and remember your life.