Revenue Early, Reveue Often

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.

Community

Google+

And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:

Google

Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Answers.OnStartups.com

Subscribe to Updates

 

30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn

OnStartups

Current Articles | RSS Feed RSS Feed

Revenue Early, Reveue Often

 

I am an exceptionally strong advocate of startups focusing on early revenue (and repeated revenue).  Once you start getting real, paying customers lots of good things start to happen (not the least of which is the cash that starts coming in the door).

 

Now, one of the things that makes life interesting is that you are often faced with a decision between one of the following alternatives:

 

  1. Do I build the “right” product for the hypothetical customer?
  2. Do I build the “not so right” product for the real (paying) customer that’s willing to write a check now?

 

Obviously, things are never as clearly defined as this, but it helps make the point.

 

The “right” product is the one that you had hoped/planned/dreamed of building.  Its why you started the company.  After much introspection, discussion, debate and turmoil you finally decide on the narrow market focus you’re going to have (you are focusing narrowly, aren’t you?) and figuring out what product should be built.  The right product is one that will be useful to some percentage of hypothetical customers within this narrow market you’ve picked.  The operative word here is “hypothetical”.  Until people start paying you money, you’re really not sure what they want and what they’ll pay for it (if anything).  Unfortunately, no manner of introspection, online surveys or deep conversations with prospective customers provides a reliable answer.

 

On the other hand, you often have the ability to be “opportunistic” and get customers that are not exactly the perfect fit, and that want things that weren’t necessarily on your radar.  Often, what they’re looking for is somewhat related to what you’re out to do (if not, then there’s really no dilemma – walk away).  In fact, there’s a non-zero probability that what they are asking for can ultimately be translated into a “general” product (that is useful to more than just them).  The customer has the added advantage of having a clue as to what real market needs are – at least for themselves individually, since they “live in the domain” every day.

 

We’ve all heard of the “important of focus” mantra – but I’ve found this to be overly simplistic (and not very precise). Sure we should focus, but focus on what?  If you have a customer willing to pay you money, that’s a strong signal that there is a problem they want to solve.  Its your job to figure out if there’s some creative way that accomplishes both your goals:  Delivering a solution for your early customer(s) that they are willing to pay for.  This gives you early revenue and all the benefits that come along with it.  AND , meets your secondary goal of putting you closer on the path towards your ultimate “perfect” product.  You’ll find that the early-revenue path is often more meandering (i.e. not the least distance between A and B), but often compensates for this by being much less risky.  Hopping from one early-adopter customer to the next and meeting their needs along the way while you constantly tweak the product towards the larger aim of a “mainstream” (i.e. general solution) is a great way to build a sustainable software company.

 

Of course, one needs to be mindful of not falling into the “consultant’s trap” (i.e. building a custom development company because most of what you build for Customer A has little or no use for future customers B, C and D).  One of the tricks I’ve learned to avoid this trap is to force yourself to have a single code-branch for your product (for all customers).  Any tweaks/deviations should be implemented as configurable options, APIs and other things (but don’t get carried away).  The message is, when building Version 1.7 of the product, it should be applicable to *all* customers.  If you ever, ever find yourself maintaining a product that is just for one customer (i.e. “AcmeWidgets Version 1.2.3”), you’re in trouble.

 

In a future article, we’ll look at how not all revenue is created equal (especially in the minds of investors).  This has to do with a) how you got the revenue in the first place and b) what it means for future revenue.  More on that later.

 

 

Posted by on Mon, Feb 13, 2006

COMMENTS

There are no comments on this article.
Comments have been closed for this article.