Perspectives on entrepreneurship, startups and venture capital from K9 Ventures.

Revenue Development

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

In 1996, when I started my first company, SneakerLabs, Inc., we began by building chat servers. This was when the state of the art was click-to-refresh HTML form-based chats. SneakerLabs’ first product was a Java-based chat server and client. It worked like a charm since we could create a more interactive experience on the Web.

In fact, at the time (1996-1997) we offered both a downloadable product, that our customers could install on their own servers, and a “hosted-offering”, which came to be known as “On-Demand”, then the “ASP” (Application Service Provider) model, and today we call it “SaaS” (Software as a Service). Same thing, just different, trendy nomenclature. The hosted offering worked by having users place an “HTML-snippet” on their own website, which would retrieve the Java Applet from our servers and connect back to our servers. Today, we call that an “Embed-Code”. Go figure.

One of our first customers was a stock trading company in NY that wanted to host live stock chats. Another customer was my alma mater, Carnegie Mellon University, who was using it to host online class discussions for its distance education program. Since I had good connections with the University, we got a lot of feedback on how the product could be improved to meet their needs. We listened to their feedback and started adding features to the product accordingly. What started out as a generic web-based chat solution morphed into a full-fledged product for a distance education that we called iClass. (We really were doing the i-thing before Apple came out with its first iMac in 1998. Our products were iClass, then iMeet, iServe and iShow.)

The product worked. Heck, it had to work, since we built it in close consultation with the customer. So everything should have been golden right? Not so fast. Within six months of launch, we quickly figured out that though we had a product built, and the product was exactly what our customers wanted, we still had another problem on our hands — our customers didn’t want to pay! It wasn’t that they didn’t want to pay, but for anything above a certain dollar amount, it had to be a committee decision, and Universities are a notoriously bad market to crack (probably second to the government). So the departments either didn’t have the capacity to pay or it would be an endless sales-cycle, where we would spend lots of time on the sales, but it still wouldn’t close. In the end the revenue simply wasn’t enough to make a sustainable business and so we had to switch gears once more (in today’s parlance that would be a “Pivot”).

Let’s take another scenario — this time in my second company. We were a tiny web-conferencing startup in Pittsburgh called iMeet. We had raised only $300K from angels and we were competing against WebEx and PlaceWare — both in the Valley and both having already raised tens of millions of dollars. We were desperate to get a marquee customer. We got a Request for Proposal (RFP) from Hewlett Packard. Despite all the recent rumblings, we can safely say that HP would have been a great marquee customer.

So we decided to go all out. We were going to get this gig. We told HP that we’d do everything they wanted in the RFP — even if we have to build it specifically for them. In fact, we didn’t just send them the response to the RFP, but decided to visit them in person. On the cover-page of our response we printed out in red ink that we want their business, and to show them that we mean business, we will do everything they want for $1 per month for the first 6 months. We asked for the one dollar so that we could call HP a “paying customer”!

That got HP’s attention and we successfully won the RFP to be HP’s web-conferencing provider. Over the course of that relationship that lasted several years, we did over $1M in revenue just from HP. This time we’d gotten it right. We found a customer whom we knew had the resources to pay. We worked with them to make sure the product met their needs — as we were sure that then it would meet the needs of other enterprise customers as well.

But, we still got one thing wrong… it’s a lot harder to get a company the size of HP to issue a check for $1 than to issue a check for $10,000! A $1 check triggers all kinds of red flags — why would a multi-billion dollar corporation be writing a check for one dollar? (We eventually did get paid!) Even though the $1 sent a message, for a company as big as HP, perhaps that message would be the same even if had asked for $1,000. I don’t really know if that’s true, and at the time we needed the business so bad that we would have done anything to get it.

In my first company, we did everything right when it came to building the product. As someone who is trained in Human Computer Interaction, I had followed the concept of User Centered Design. We’d done Contextual Inquiry and gone out to visit potential users to see how they worked in their environment, and then done the Need Finding and all the other good stuff that has been the basis of building the right product. However, what we’d failed to do was validate how much our customers would be willing to pay, and what it would take to get them to pay.

In my second company, we’d gotten a step closer: we built a product that our customer wanted, and it was a customer that had the capacity to pay and was willing to pay, yet, we’d underpriced our initial offering to them to the point where we were probably leaving some money on the table. Maybe that was the right thing to do to get the business, but the key point is that we didn’t test how much they would have been willing to pay.

I tell these stories to lay the groundwork for what I am going to call Revenue Development. We’re all familiar with Product Development, and thanks to the amazing Steve Blank and Eric RiesCustomer Development has become the mantra for so many startups. But I’m going to contend that we’re still missing one leg of the stool, and that leg is Revenue Development.

I define Revenue Development as the process of iterating on the revenue model for the company. The goal is to try to answer a few key questions:

  • Does your target customer have the capacity and the ability to pay?
  • How much would they be willing to pay?
  • How should you price your product/service? Is it a one-time purchase, a recurring purchase, a subscription, a pay-as-you-go offering, etc.?
  • What should the price be? Can you build a sustainable business at that price point?
  • What will the future pricing look like? Does it change as you open new market segments or territories?

These are questions that a startup needs to think about, as they are key to its ability to build a lasting business. However, these are not questions you can get right in one attempt. Like Product Development and Customer Development, this too requires conscious iteration. In my mind, there are two main facets to Revenue Development: a) Business model iteration, and, b) Pricing iteration.

Very often what a startup’s business model is going to be is unclear. However, at the very least I expect the startups I work with to have at least thought about the options they have. It’s quite likely that the business model at the top of their mind will not be the right business model (Randy Komisar’s book Getting to Plan B is a great read for this). However, to me the sign that a founding team has at least thought about a revenue model is an important indicator.

Google’s first business model wasn’t based on advertising. In fact, that wasn’t Google’s idea at all. That idea came from, which came out of Bill Gross’ IdeaLab, and then became Overture. Google’s first business model was to sell/license search to the major portals (Yahoo! being the dominant one at the time). So it wasn’t that they had the right business model to start. But they were thinking about it, and they iterated on the business model to get to something that worked — and worked well at that.

Pricing is something that whole theses have been written about, but I’ll summarize my view on pricing as it pertains to Revenue Development in one line: It’s easier to start high and then come down than it is to start low and then go up. The right price is “what the market will bear,” but you can only know that by experimenting with it. And in order to experiment with pricing, it’s better to start with a high ask. You can always then discount the price down to match what the customer is willing to pay. But is your starting ask is too low, then you will always end up leaving money on the table. The caveat is that your initial ask shouldn’t be so ridiculously high that the customer just walks away without countering.

Pricing consumer products and services is a little trickier since you don’t get to have a direct dialog with the customer over the price. But with the amount of data we can gather on the Web today using simple analytics tools, doing this time of experimentation is still possible. VC funded companies are very often guilty of giving stuff away for free because they want to grow fast. Founders often forget that their interests and the VCs interests are not all the same. Very often VCs are okay with the company needing more capital because it gives them a chance to buy more of the company.

I’m not a fan of FREE (see my previous post: The Case Against FREE). Free to me is nothing more than lead-gen for paid. If you’re going to be using a freemium business model It’s important to make sure that you segment the offering right so that your paid service has something interesting enough that people will be willing to pay for it. A classic example, in my opinion, was Plaxo. Plaxo built a great product, but the core value Plaxo provided was backing up people’s Outlook Contacts — because Outlook would crash and very often lose them. But Plaxo gave that away for free (probably a result of having too many VC $$s to play with!). They then tried to get people to pay for duplicate removal and support — I don’t know how well that worked for them, but that certainly wasn’t enough of a hook to get me to switch to the paid product.

I would argue that startups need to be doing Revenue Development very early on. Without it, how do you know how your company/product will ever be able to make enough revenue to become a sustainable company?

In a nutshell, Product Development is about building something. Customer Development is about building something people wantRevenue Development is about building something people want, and are willing/able to pay for, while letting you build a sustainable company.

Thanks to all those who helped to proof read this post, especially to Jake Witherell from Schell GamesRon Yeh, and AJ Shankar. You can follow me on Twitter at @manukumar, or, follow @k9ventures for just the K9 Ventures related tweets.

Update (08/15/2010 11:23 PM): Patrick Vlaskovits posted a great followup to my post above on his blog: Distribution and Pricing Hypotheses with LOIs.

My intention in this post is to draw the attention of startups towards the idea of iterating on the revenue model/pricing. Too many startups today fail to do that. Some of them build great technology and awesome products that do meet user needs, but sometimes forget/overlook figuring out the revenue model till a lot later in the process.

In his post Patrick points out that:

With his assertion about one leg of the stool missing and calling for “Revenue Development”, I think he is making an error (probably well-intentioned) because I surmise Manu probably hasn’t actually read The Four Steps to the Epiphany.  (PDF excerpt here).

As anyone who has knows, Steve has thoroughly embedded sales, revenue and pricing hypothesis testing into Customer Development (Steve calls it very plainly “Distribution and Pricing Hypotheses” – see slide 17), and as such, calling for “Revenue Development” as a missing third leg  is completely unnecessary.

Patrick is completely correct here. What I called Revenue Development is indeed already a part of Customer Development, and I stand corrected. I just wish that I saw companies practiced this more often. So if this post helps to bring that part of Customer Development to the forefront, and helps entrepreneurs realize that it is just as important to iterate on the revenue model and pricing, as it is to build a product that people want, then my job here is done.

Thanks to Patrick for the clarification.

  • Juan Diego Carluccio

    “we will do everything they want for $1 per month for the first 6 months. We asked for the one dollar so that we could call HP a “paying customer”!”

    There are so many beautiful concepts in this action: commitment, loyalty, honesty, belief and faith, long-term view, hard work, and others.

    Thank you. You make my day. It’s nice to see that a pre-seed/seed investor can actually have the same core values as an entrepreneur.

  • noname

    These 2 posts regarding pricing a product may benefit your software entrepreneurs.

  • NG

    Only in the “IT/Software” world do you find such fluff written and funded.

    Anyone who has worked/served large mechanical equipment OEMs would never have to be reminded of such basics.

    When working on the business model, wouldn’t you ask what the risks to Cashflow, Revenue, Profit, Assets (IP, People, Materials, Cash) and Credit are along with technology risks? May be working at GE would be “enlightening”

  • Hi Manu,

    This post really hits home to me as I have recently needed to pivot my revenue model based on multiple conversations with potential clients. The only thing i could add to what you have discussed here is that having 1 revenue model may not be the best solution. If you offer a service that can be translated into a benefit for different markets then each of those different markets can bear different prices. For example, given your original chat platform you could have a freemium model for c2c customers and a monthly fee for corporate clients. In my experience, even to be considered “enterprise” scale you need to price accordindly, this is the basis of price discrimination but in the legal sense.

  • Pricing–and price negotiations–are an integral part of product development and the sales process. Breaking them out into a category separate from product and customer development seems to me to counter-productive. It would lead to exactly the problem you describe in your first situation: developing something that people want who are unable to secure budget.

    You attribute ‘make something people want’ to customer development but it’s actually Paul Graham of YCombinator who espouses “make something people want.” As you point out this is incomplete advice and should be “make something people want to pay for.” Steve Blank has suggested a number of strategies for exploring pricing in “Four Steps to the Epiphany” and includes an explicit criteria of “has or can obtain budget” as a part of his definition of a good early customer–which he calls “earlyvangelist”.

  • Dude, great post. Amazing how many people forget this part.

  • Pingback: Distribution and Pricing Hypotheses with LOIs | Vlaskovits()

  • Great post and so relevant in today’s world! You should write a book – develop a process, outline methodologies. Teach a class at Stanford!

  • Excellent post, Manu. I especially like the point about the HP deal–startups often fail to realize that it’s easier to purchase a product at the right price rather than the lowest price.

    If you want to follow up on this concept, both I and my friend TK would love to help you produce additional content. It seems like we’re very much of the same mind…I can’t tell you how many times I’ve told people, “It’s a lot easier to lower prices than to raise them.”

    That being said, sometimes one does inherit a situation where prices need to be raised, and it is possible to do this. At PBworks, we’ve had to push the average ticket up by a factor of 25X over the past 3 years.