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 Ries, Customer 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 goto.com, 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 want. Revenue 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 Games, Ron 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.