LOIs

Last updated by at .

Update: Manu has updated his post with an excerpt from mine as well as some additional thoughts.  I think we’re on the exact same page.

I just came across a post by Manu Kumar wherein he, riffing on Customer Development, writes about the importance of and need for what he calls: Revenue Development.  He outlines a few past mistakes he made when it came to pricing discovery:

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.

Bingo.

Manu then cuts to the chase:

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. [Emphasis: Mine]

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?

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.

The aim of my blog post is not to beat up on Manu, but to amplify what Manu is advocating for and highlight the importance of testing pricing and revenue in the Customer Development context.  Revisiting my first experiences with Customer Development and testing of pricing, I would remind readers of the power of a Letter of Intent in pricing discussions with your customers.  If you are a B2B play, I strongly suggest you use a Letter of Intent as an intermediate MVP  for exactly what Manu suggests.

As I wrote back in December 2009 on Brant Cooper’s blog about my Customer Development experiences from my last startup.

1) We could have titled this a Memorandum of Understanding (“MOU”) as opposed to an LOI, but we wanted to strongly signal that they are demonstrating intent to buy by signing something called a Letter of “Intent”.

2) Brief description of functionality.  This is is simply to get both parties on the same page and set expectations.

3)  Development process updates.  This was to ensure us face-time with our customer.  Should our customer get busy, we didn’t want to be easily forgotten or ignored by having all our communication relegated to email and phone.

4)  Pricing and price discovery.  Our next LOI recipient got a significantly higher price.

5)  Intention discovery.  Do they actually want to buy our product?  Well, let’s test it very plainly with “It is the intent of CUSTOMER to enter into a formal agreement with START-UP, by REASONABLE_DATE.”  We have de facto started the sales cycle.

6)  Terms.  Can we sign them up for 18 months?  24 months?  3 months?  Month-to-month?  Per usage?

7)  Disclosure.  This is our effort to keep our customers from chatting with one another about the terms of the LOI as we go about price and intention discovery

To be painfully clear, the idea of using LOIs and screenshots as a way of testing pricing and willingness to buy BEFORE building anything came as a direct result of reading Steve’s book.

So Manu is right.  A startup most definitely needs to iterate and test revenue, pricing and a sales roadmap.

And Manu is wrong, there is no need for “Revenue Development” as a missing third leg.  A close reading of The Four Steps to the Epiphany will suffice.