My last article titled “Startup Hiring:  Why You Should Date Before You Get Married” generated a fair amount of interest – and controversy.  It actually broke my personal record in terms of unique web visitors in a single day (in this case, 3,700+).

 

Given that the article also generated the most amount of comments I’ve had to any article, I thought I’d address some of the comments and criticisms and also take a step back to look at why effective startup hiring is so hard.  The idea in the last article (if you didn’t read it)  was that startups should only hire employees after some mandatory “trial period” after which the candidate must have built support within the company in order to be hired.  Admittedly, this is just one tactic (likely sub-optimal) for trying to address the challenge.  Clearly, from the prior article comments, many people don’t agree with it.

 

Lets first start off with some thoughts on why hiring the right people is hard, and hiring for a startup is even harder:

 

 

 

 

 

 

 

 

So,  who in their right mind would join a startup given all of the above?  The answer is, you can’t be completely in your right mind to join a startup.  It takes a little bit of irrational risk tolerance to really get into this game (especially if you’re walking in with your eyes open).  The one big thing that startups provide is the ability to have an “accelerated learning” curve and clear visibility as to one’s contribution.  Its an intellectual challenge.  There’s usually enough work to do (of all kinds) that most smart, energetic and passionate people will find multiple ways to contribute value.  (This is assuming of course, that you have some faith in the founders and existing team – if not, run NOW and save yourself).  Compare this to large, established organizations and it becomes clearer why so many people work for startups.

 

So, lets take a look at some of the criticisms to my “try before you buy” model mentioned in the last article.  I would neatly summarize the comments into the following categories:

 

  1. It’s Not Fair To The Employee:  There were a number of comments which argued why the “date before you marry” model might favor the startup and screw the employee.  However, much of this has little to do with my proposed tactic, and more to do with the general nature of startups (and employment law in the U.S.).  Employees here are “employees at will” (as noted in a few comments), and the startup has the right to fire anyways.  As for the “unfairness” piece, I would counter this set of arguments with my “free markets” card.  That is, if startups are being overly draconian about their hiring practices they will likely not attract the right kind of talent and will ultimately die anyway.  So, if the hiring methods of a given startup don’t appeal to you, the great news is that you likely have many, many other options.  If you don’t have other options, in all fairness, the startup probably didn’t want you anyways.

 

  1. The Startup Can’t Afford It:  I made mention that during the trial period, the startup should pay “fair market value” (though what this is can in itself be hotly debated).  My point is that the trial period should not be used as a ruse to get “free work”.  The motivation for the dating period (as I called it), is simply so that both parties can get to know each other and see if the relationship is working.  If it’s not, then it wasn’t destined to be, and the goal should then be a clean (and efficient) separation.

 

  1. It’s Not Necessary To Have A Trial Period:  The arguments provided here are that U.S. employment laws allow for a probationary period anyways, and it is not that hard to “fire” an employee during this period.  So, the argument goes, why go to so much effort not to hire – since it’s so easy to fire.  My counter-argument is that the “trial period” sends a clear message that we care  about the team composition and chemistry and that we are willing to be transparent about it.  Rather than hire an employee on Day 1 only to learn that it’s just not going to work out 2 months later, I’d rather be upfront about it.  How we deal with this can vary (it could be a contracting/consulting relationship for some period of time), but the motivation is the same:  Figure out early, if its going to work.  Further, if a candidate is in “dating” mode with the startup, everyone knows it and focuses on getting the right “experiences” to make a good decision.  Without this, the candidate is just treated like a regular employee and people tend to forget to figure out whether the relationship is going to work out long term.

 

  1. It’s Only Needed Because Of Startup Cluelessness: Here, the arguments are centered around the notion that if the startup could just get its act together and figure out what it wants and assess appropriately, then this whole “date before you marry” thing shouldn’t be necessary.  This is a reasonably fair argument.  Many startups are clueless when it comes to what kind of people they need, at what times and in what roles.  This is part of the chaos that almost all startups go through.  I think its na?ve to expect startups to be organized, methodical and thoughtful around the whole hiring process.  Though some certainly are, most aren’t. 

 

  1. It Becomes  A Popularity Contest:  Several people took issue with my statement that the new candidate must build passionate support within the existing team in order to be hired.  I can see why this might be controversial, because intuition tells us that this has the danger of creating the “popularity contest” effect whereby the only people that get hired are the ones that can “win over” someone on the existing team (and as a result great candidates might get rejected).  This too, is a reasonable argument.  There is that risk, but that same risk occurs when you have team members interviewing candidates too (which you are strongly advised to do).  

 

Basically, I understand the arguments against the suggested tactic of “date before you marry”, and many of them are clearly cogent and reasonable.  Lets remember that this is just one way to try and address some of the startup hiring challenges.  There are likely much better ways – and I would love to hear them.  So, if you have insights into this dilemma, please share them.  You will build an immense amount of positive startup karma.

 

Apologies to those that commented on the original article and feel like I dodged or hedged their comment (not my intent).  Of all the things I deal with in startup-land, this is one of the toughest, so I really do appreciate that there are no easy answers.  And, remember, this is just one (humble) technology guy’s opinion – I am, by no means, an expert.  That’s the beauty of blogs, you don’t need to be an expert, you just need opinions (and I have an abundance of those).

 

Further, if you are a prospective startup employee, I encourage you to do your homework and know what you are getting into.  Meet the founders and the team.  Inspect and analyze the idea.  Talk to the investors, if there are any.  Tread carefully.  [Note to self:  This might be a good topic for a future article, focusing on startups from an employee’s point of view].

 

 

 

 

 

 

 

Continue Reading

Startup Hiring: Why You Should Date Before Getting Married

By Dharmesh Shah on April 24, 2006

Most entrepreneurs, when asked, will tell you that hiring the “right people” is one of the most important things they do for their companies.  However, what many entrepreneurs won’t tell you is that despite their best efforts, they suck at picking the best people during the recruitment process.  I definitely fall into this camp.

 

This doesn’t just apply to hiring in the management ranks and technical staff, it applies to everyone.  During most of the years I’ve run startups, I’ve always considered myself pretty good at detecting startup talent.  But, the empirical data suggests that I’m almost as likely to screw it up completely as I am to get it right.  Over time, as a startup founder, you learn not to rely on all the conventional proxies for trying to predict the probability of success of any given hire.  Things like interviews (however intense), tests, grades, top universities, etc. are all only somewhat effective in raising your odds of making the right decision.  After all is said and done, you’re likely to screw it up more often than you realize – or are likely willing to admit.  And, the problem is not just limited to you – others on the team are not that much better at it.

 

That is why I think you should make it a practice to have people work for the company before you hire them.  Though hiring an employee you don’t know is not quite as big a commitment as getting married, it can often be almost as risky from a startup’s perspective.  (Apologies for the metaphor, it is almost 2:00 a.m. here in Boston and I can’t think of anything better).

 

In this model, potential employees (especially those in the technical ranks) are considered to be in a “probationary” period (what I would call the “dating” period) for some length of time.  During this period (which was usually 60-90 days in my case), either party has the ability to declare that the relationship is just not working out and move on – with no misgivings on either side.  This is made clear very early in the process.  The potential recruit is paid “fair market value” during the trial period (but generally as a consultant and not a full-time employee).  We’re not trying to take advantage of the employee or get free work – far from it.  Other than the fact that they’re not on payroll, they pretty much are treated as a new hire.  They learn real things, do real work and (hopefully) create real value.

 

At the end of the period (from the company’s perspective), here’s what you should look for:  One or more people on your existing team should be passionate about keeping the recruit on board.  They should be storming into your office making a desperate plea for you to make an employment offer to the recruit.  If in 2-3 months this has not happened, then the recruit is likely not a good fit.  To be clear on this, the “default” decision is to pass on the hire unless someone on the team provides compelling evidence and/or testimony of why the new recruit should be brought on board. 

 

Though this may sound a bit draconian, it has worked out well for me (I did it in the last several years of my first startup after I had screwed up enough times).

 

I expect there to be some resistance to this model.  The common arguments are the following:

 

  1. It is a really tight labor market, can you really expect the best people to join under these conditions?  In short, yes.  In fact, the best people often like having the ability to test out the company (as much as you want to test them out).  This gives them a way to do that without locking themselves in after hearing what amounts to the CEO/founder’s sales pitch on why the company is such a great place to work.  They get a chance to find out for themselves.  As an added advantage, the more astute candidates will also recognize that this process works to their advantage too (if they do end up joining the company).  It keeps a higher percentage of bozos out.  Nobody wants to work with bozos.

 

  1. Is this really legal?  Though I’m not a lawyer, and this is not legal advice -- yes.  In fact, it is much simpler to do this than try to hire a person full-time, be added to the payroll (and insurance, and 401k, etc.) and then fire them later if things don’t work out.  

 

  1. How about people that already have a job?  In this case, I’d advise that the new recruit work with you off-hours (chances are, your startup is working nights and weekends anyway).  This still gives you the opportunity to see if they “fit” without them having to risk their existing job.  Even in this case, you should still compensate the employee for their time.

 

  1. Doesn’t this really limit the number of people you can hire?  Absolutely.  However, just about everyone I’ve ever talked to and every book I’ve ever read suggests that you are much, much better off not hiring a person at all than getting someone on board that’s not a good fit.  It is often very difficult (emotionally and otherwise) to let people go if they are just “slightly below expectations” .  This is particularly true if you are concerned that part of the reason the employee didn’t work out is the company’s fault (it usually always is).  This still doesn’t change the fact that things are not working out.

 

  1. What about recruits that are “referred” by existing employees?  Same rules apply.  Though I would still allow the person that referred the recruit to be the “passionate advocate” after the probationary period.  (Interestingly, there are cases where the same person that refers a potential candidate will learn enough about the candidate during the trial period that they can’t bring themselves to be a passionate advocate at the end of it).

 

Moral of the story:  Whenever possible, when it comes to hiring people for your startup, you should “try before you buy”.

 

If you’ve been running a startup (or even worked for one), ask yourself how many bad hiring decisions could have been avoided if you had the opportunity to “walk away” in the first 2-3 months?  I’m guessing quite a few.  If on the other hand, you’ve got this whole process down cold, please share your secrets.  

 

 

 

 

Continue Reading

The Free Software Debate: Businesses vs. Projects

April 21, 2006

I’ve had a significant response (both positive and negative) to my prior article:  “Giving Software Away For Free” so I think it is time to elaborate on some of that original thinking and dig a little deeper into the issues at hand.

 

To better articulate my position on free (as in beer) software, I’d like to make the following distinction between projects and businesses.  The definitions are my own and only apply in the current context:

 

Project:  An initiative whose primary purpose is not necessarily  to generate revenues and profits.

 

Business:  An initiative whose primary purpose is to generate revenues and profits.

 

I think the cause of much confusion is when individuals think they’re working on a business, when in fact, they’re working on a project.  It is entirely possible that some projects morph into businesses.  I use the term “morph” intentionally instead of “evolve” as I’m not suggesting that businesses are in any way better than projects – they’re just different.  The idea is not to make a value judgment here.

 

Now, with this distinction in mind, some general observations and opinions:

 

  1. Not all software development initiatives need to be businesses.  If you’re happy building something that you, your friends/family or the community at large might find useful, more power to you.  This is a noble and worthy cause.  We need more people like you.  If you’re working on something interesting and can find like-minded individuals to join your pursuit, you may have the makings of a great open source project.  This is a very good thing. 

 

  1. If you are working on a business, then it’s important to address the hard issues early on (like how you’re going to make money).  The reason is that businesses have stakeholders (in many cases, it may be yourself).  I think it’s tempting – but misguided, to actually be thinking you’re running a business, but then treat it as a project.  So, if you’re running a business, then you should act like you’re running a business and force yourself to think through some of the difficult issues.

 

If you are working on a business, then there has to be some way for you to make money.  This doesn’t mean you have to charge for the software directly – but the software has to lead to money somehow, someday.  This can be through selling (license fees, subscriptions, etc.) subsidization (like advertising), services (like consulting, support, etc.) or synergy.  It’s this last one (synergy) that gets a little tricky.  Lets look at each of these:

 

Selling: This is the simplest one to understand.  You charge customers for use of your software.  This can be done through license fees, subscription fees or some other mechanism.  Not particularly hard to understand and for a long time was how most software businesses made money.

 

Subsidization:  This is when you let customers use the software without charging them directly, but make money through another vehicle (like advertising).  In this case, somebody is paying for the software – just not the people actually using it.  So, I would argue that the reason Google is a multi-billion dollar business is not because they’re good at giving software away for free, but because they’re very good at subsidizing software through advertising.  

 

Services:  This is when you let customers use the software itself without charging them directly, but charge them for services related to the software.  The classic example is a company like RedHat which provides the underlying software without charge (in most cases), but charges for support and other services.

 

Synergy:  This is the weirdest one of the lot and highly popular in the current crop of Web 2.0 companies.  In the synergy model, you don’t make any significant money through the standard mechanisms (as described above), but through what I would call “delayed gratification”.  Basically, the synergy model says:  I won’t make a lot of money directly myself, but will help some other company make a lot of money.  This other company will then acquire my company to reap the benefits of the value I’ve created.  So, instead of making money every year, the hope is that you “defer” the gratification and make lots of money when you sell the company.  The astute among you will likely recognize that this is somewhat of a risky bet as it assumes that there will be an acquirer someday.

 

One of the reasons that the synergy model is so popular for Internet startups is that it’s easy.  You don’t have to worry about troublesome things like sales, customers, profits, etc.  You can focus on what you enjoy (which is writing software) and let the rest “just happen”.  Interestingly, I’ve never known of a startup that will actually admit that they’re playing the “synergy” (or “lottery”) game.  When pushed, they often hide behind the cloak of subsidization (i.e. advertising) as their model.  The reason for this is that advertising too is easy.  In about 10 minutes, any Internet-based business can claim legitimately, to be using advertising as a source of revenue.  The trick is one of magnitude.  Few of these companies actually understand how much traffic is required for this advertising revenue to actually lead to a “real” (i.e. sustainable) business.

 

I’d like to close with some thoughts on projects (instead of businesses).  I think projects (I consider this blog a project), are a wonderful thing.  Here are some of the benefits of projects, and why not all things need to be businesses:

 

  1. Making a difference:  Projects are a great way to actually make a difference, even if it is a small one.  By focusing on your strengths and passions, projects provide a vehicle for you to leverage your unique talents and give back.  Some would call this “making meaning”.

 

  1. Meeting great people:  Projects are a great way to communicate to the world what you care about and what you love.  This provides a channel for others of like-mind to find you that would likely have not done so otherwise.

 

  1. Making you better:  Projects often lead to you improving your talents.  By doing what you love and taking on challenges, you end up learning a lot.  Not just how to write better software, but how to interact with beneficiaries (also known as “users” – which is a term I don’t like) and assimilate knowledge.  I’ve never known someone to pursue a project (either successful or not) and not learn and grow from it.

 

To be fair to yourself (and others that might join you), ensure you know whether you’re working on a project or a business.  Successful, sustainable businesses are hard.  Though it is possible that your project could turn into a business someday, I would argue that the odds of this are really, really low.  One of the reality distortions is that we hear much more often about the successes, and hardly ever about the failures. [Note to self:  Possible topic for a future “reality distortion” article].

 

Whether you’re working on a software business – or a software project, you have my best wishes.  Cheers!

 

 

 

Continue Reading

Disagreeing with 37signals #1: Less Is Sometimes Less

By Dharmesh Shah on April 19, 2006


This is the first in a series of articles I plan to write about some of my thoughts on 37signals and their e-book “Getting Real”.  [For the record, I highly recommend the book].  Most of the advice is really good.
 
There has been a lot of talk on the net about simplicity and the whole principle of “less is more”.  
 
I must say that I agreed with a large majority of what they had to say in the book, and most of it I think is good advice for software entrepreneurs.  However, the things I disagreed with, I strongly disagreed with and felt it necessary to respond to.
 
Disclaimer:  Overall, I like 37signals and what they have done.  They’ve shown us what is possible in the “real” Web 2.0 world where companies can create value, charge customers and run a real business.  Further, Jason Fried (founder/director/evangelist of 37signals) was kind enough to let me interview him for some graduate work I’m doing at MIT, so I am grateful for that (thanks Jason!).  I am also a paying customer of the company and have used their products.
 
Having said that, I’m just getting a little weary of this “less is more” message.  I think we are beginning to confuse the simplicity message with the “less” message.  Very, very powerful things (like the Google search engine) can be very, very simple too – from a user’s perspective.
 
So, to be clear, there are various “dimensions” on which less can be measured:
 
  1. Less complexity (from a customer’s view point)
  2. Less “baggage” (more flexibility)
  3. Less features.

 
It’s the last item that I have contention with.  Less (features) is not always more.  So, lets dig a little deeper here.  In every technology industry that I know, customers demand more features/capabilities over time.  Whether it be software, a car or a mobile phone – as time goes, you expect more out of the technology in your life for it to continue to be useful to you.  Paradoxically, you want things simpler too – but simpler does not mean you’re willing to give up on features.  You want both.
 
Lets take a classic example from the software world:  the word processor.  The 37signals team might have us believe that the answer here is the simplest possible set of features are all that people really care about or want.  Basically, you write/edit text and save/print it.  That’s it.  Basically, something like Notepad.  At the other extreme, we have Microsoft Word with its 10,000+ features.  Many can (and have) argued that nobody uses more than 20% of the features in Word.  That’s likely true.  The issue is that it is a different set of features for each user, and within that set, one or more features are very important.  Not nice to have, not customers whining because they want everything, but important.  For our word processing example, we could divide the kinds of features that people might want into some simple buckets:
 
  1. Formatting and Printing (fonts, images, layout, rulers, etc.)
  2. Better writing features (spell check grammar check, word count, etc.)
  3. Large document features (table of contents generator, footnotes, etc.)

 
Now, ask anyone that falls squarely into one of the above groups as to whether “less is more” – and they’ll clearly disagree.  A journalist needs spell check and word count.  When writing my master’s thesis, I need the table of contents feature.  Sure, we crave simplicity (so we like features to “go away” when we don’t want them), but we’re not willing to give up the features we want.  Most of the most successful products in the software industry are those that were able to deliver “more” to the customer without disproportionately increasing the complexity (examples are Lotus/Excel, Word, Photoshop, Quicken, etc.)  


To be sure we're clear here, I'm not suggeesting that companies build products that try to do everything for everyone.  I'm a big believer in focus.  But, once you've picked what kinds of cusotmers you're going to focus on, the goal should then be to deliver what these customers expect.  In the 37signals case, it seems that they are picking a broad range of customers and then choosing the minimalist set of features (i.e. "lowest common denominator") that all of these customers need.  The result is a very small set of features that doesn't meet the full needs of most customers. 

Overall, I’m all for finding a  Clayton Christensen style “disruption” (See “The Innovator’s Dilemma) and playing a different game.  The issue is that in the world of software, even simple things sometimes require some planning, thought and design so that you don’t paint yourself into a corner.  Here’s the one example from the book that just about gave me an ulcer:
 
From “Getting Real” by 37signals:
 
Build software for general concepts and encourage people to create their own solutions.
 
When we built Ta-da List we intentionally omitted a bunch of stuff.  There’s no way to assign a to-do to someone, there’s no way to mark a date due, there’s no way to categorize ,items  etc. We kept the tool clean and uncluttered by letting people get creative.  People figured out how to solve issues on their own.  If they wanted to add a date to a to-do item they could just add (due: April 7, 2000) to the front of the item.  If they wanted to add a category, they could just add [Books] to the front of the item.  Ideal?  No.  Infinitely flexible? Yes. 
 
Now, let me breathe deeply and explain why I think the above example is so troublesome.  I’ve been a professional programmer for all of my career.  I’ve read the books, got a CS degree, written big apps and small apps, worked with some exceptional people (folks that Joel Spolsky and Paul Graham would like), and so on.  Not a single person that I respect and know from the software development community would likely consider the above a “good approach”.  Repurposing things as simple as a due-date and having users make up their own ways to solve the need is just asking for trouble – very soon.  This goes against so much of what we have learned (simple things) about creating great, enduring, well designed software.  We’re not saying it should be more complex, but there needs to be some minimal design that accounts for the most basic needs.  Other than the fact that the above application is web-based and Ajax-powered (which is cool), it’s just another simple data management application, with minimal structural support.  I think we’re getting overly distracted by the coolness of new technologies and taking a major step backwards.  In the above example, what happens when users want to be notified of items that are due?  How about when users want to see tasks that are assigned to them (if that feature ever gets added).  There’s no need to add these features now (though one could argue that for a task management system, these are bare essentials), but given the choice, customers are likely to want these things – once they get done with the basics.
 
As a final point, I’ll include another excerpt from the book:  Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else.
 
In my experience, the simple problems (that people are willing to pay to have solved) are both hard to find and hard to build enduring software companies around.  Even things that start simple end up becoming complex as customer demands increase.  The 37signals approach to addressing this increased complexity seems to be to build “opinionated software” (basically, push back on the customers and keep things simple).  I think this is a sub-optimal strategy.  History is replete with companies that didn’t work hard enough to meet the growing demands of their customers and ultimately got left behind.  
 
If you’re an aspiring software entrepreneur and have found nice, easy problems to solve that customers are willing to pay for, congratulations!  That’s great!  You too can be a huge success like 37signals.  But if not, you’re in good company.  Thankfully there are still lots of difficult, challenging and interesting problems that customers need solved in the software world.  Looks like Its poor, wretched souls like you and me that will likely have to take on these problems.  Such is life…
 
What do you think?  Am I off-base here?  
Continue Reading

Mashups vs. Gnashups and The Dangers Of Google As Platform

April 18, 2006

From Wikipedia:  A mashup is a website or web application that seamlessly combines content from more than one source into an integrated experience.

 

From Dharmesh Shah:  A gnashup is a mashup that eventually causes gnashing of teeth because the developer thought she was building a viable business, when in fact, she was really conducting a controlled experiment for the benefit of Google and others.

 

Mashups are all the rage.  Many new startups are creating applications that leverage available web applications that provide APIs (like Google Maps).  These mashup applications put together pieces of web functionality like search, mapping, photos, news, shopping, etc. into a single, composite application.  These applications weren’t easy to construct “back in the day” as the web services required to power them simply didn’t exist.  Now, more and more companies are making interesting web services available for the aspiring mashup developer.

 

So, what do I have against mashups?  Nothing.  I think mashups, as a concept, are a fine thing.  As a user, I find them fun and interesting (and sometimes even useful).  My issue is that from an entrepreneurial perspective, too many mashup startup founders seem to be working under the misguided notion that they’re building a viable business – when in most cases, they’re not…

 

Here are my issues with mashups, and what might cause them to become gnashups. 

 

  1. Dependencies Abound:  At the heart of the mashup is the use of one or more “key” services that make the mashup possible.  In essence, the mashup depends on the existence of a set of web services in order to work.  If one or more of these services becomes “unavailable”, everything breaks down.

 

  1. Lack Of SLAs (Service Level Agreements):  The above dependencies wouldn’t be so bad if you could somehow have assurances or guarantees of certain “uptimes” and availability.  But, in most cases, there is no such guarantee.  In fact, many of the available services mashup developers use today can’t even be “purchased” (i.e. paid for), and hence there is little motivation for the providers to offer guarantees or assurances.

 

  1. No Good Way Of Dividing Up The Value:  Assuming that there was some possible business model here (I’ll put on my simple business guy hat and suggest that you might actually charge for your application someday), its still unclear how the value gets divided up and who gets paid what.  Even if you’re building a revenue model on advertising, how do the other service providers make any money?

 

Absence Of Malicious Intent Is Not Enough:  One of the common arguments I hear from mashup developers is: “Hey, Google has no motivation to cut me off.  They’re running a multi-billion dollar business.”.  I could even support this argument further by noting that part of Google’s core philosophy is “do no evil”.  However, as it turns out, this doesn’t really mean much.  

 

For example, lets assume you were writing an application for Microsoft Windows.   This application would be “consuming” software services (core operating system features) through an API and doing (hopefully) interesting things.  Sound familiar?  Remind you of mashups?  That’s because it’s a similar concept.  Software developers have been using third-party platforms and services for a long, long time.  Now, here’s what makes this interesting:

 

  1. Microsoft doesn’t know who you are:  When you write Windows applications, there’s no registration process.  You can simply buy the tools and build your app.
  2. Microsoft doesn’t charge you (directly):  There’s no “tax” to you as the software developer.  Microsoft makes its money from the customers that buy Windows.
  3. Microsoft doesn’t charge the customer (extra):  People that are buying your application don’t pay more for Windows.  More importantly, Microsoft can’t charge customers extra for using your application.  This is subtle, but critical.  Stick with me.  

 

Now, lets explore this a bit.  What if Microsoft made you “register” with them before you could develop Windows applications and use their API?  What if Microsoft could (from a technical perspective), turn off your access to their platform at will?  What if Microsoft could charge you a different fee for access to the Windows API than your competitors?  What if Microsoft could charge its Windows customers more if they are using your product vs. someone else’s?  Would you write Windows applications?  I certainly wouldn’t.  It’d be hard to build a business in these circumstances that was going to succeed beyond a certain point.  The other party (Microsoft) would have too much power.  [Note:  I’m going to be writing about strategic partnerships and dealing with 900 pound gorillas in a future article].

 

That’s the situation we have now with mashups that are based primarily on Google and similar platforms.  Back in the day, even if Microsoft hated your guts, it was very, very difficult for them to do anything about it, because if you were selling applications running on Windows, they had no real control over you as a developer.  Their software was already running on millions of desktops, and they couldn’t easily change it just to spite you.  Even then, companies like WordPerfect and Lotus felt vulnerable because Microsoft could have an unfair advantage over them. 

 

In a Google mashup world, lets see where we as developers stand:  They make APIs available.  But, to use their API, you have to register with Google and get an account.  Not a big deal.  Easy enough to do.  But, here’s the catch:  Every time your application does anything with the API, it’s getting implicit approval from Google to do so.  Though they don’t (currently) have any motivation or incentive to cut you off,  they could if they wanted to.  They could also charge you a fee, if they wanted to.  They could charge their customers a fee for using your product, if they wanted to.  They have the ability to perfectly price discriminate (a neat economics concept I learned at MIT) if they wanted to.  As such, your destiny is in their hands.  Sure, they’re likely a benevolent dictator, but as a business guy, that doesn’t give me the warm comfies (my own term, I didn’t learn this at MIT).

 

What surprises me most is that the same community of developers that is pushing for open standards and open source (Linux, PHP, Ruby, etc.) is also the same community of developers that at some level is willing to build on a closed platform where the platform provider has complete control.  What am I missing here?

 

Moral Of The Story:  Putting too much power in the hands of a few doesn’t seem particularly prudent for software developers and startup founders.  We shouldn’t let the current wave of innovation cloud the need for sound business strategy.

 

 

Continue Reading

Startup Reality Distortion #3: The Fallacy Of the Non-Disclosure Agreement (NDA)

April 18, 2006

In my role as angel investor and informal startup advisor, the issue of NDAs (non-disclosure agreements) comes up about once or twice a month.

 

It is likely that a lot has been written regarding NDAs from an investor’s/VC’s perspective.  There are very good reasons on why they won’t usually sign them.  But, I’m not going to talk about that here. 

 

I will look at NDAs from an entrepreneur’s perspective and make the argument that pursuing an NDA may not be a particularly effective strategy anyways.  Note:  This is not legal advice (I’m not a lawyer), but just one guy’s opinion on how NDAs (or the pursuit of them) may distort your reality.

 

The Fallacy Of The NDA

 

The common rationale for trying to get people to sign an NDA in the first place is that you don’t want them to reveal your “secrets” to others.  So, the thinking goes, “if I get them to sign the NDA, then I can reveal some of my secrets because the NDA will protect me”.  

 

Lets say we divide the type of information you might conceivably disclose to an outside party into two categories:

 

  1. Information about what you are trying to do (i.e. the idea, market opportunity, etc.)
  2. Information about how you are going to do it

 

My first argument will be that items that fall into category 1 (what you are trying to do) should not be kept secret anyways.  You have more to gain by disclosing this information than trying to protect it (in most cases).  One of the biggest problems startups face is that they invest time/energy/money into an idea under the false premise that they will be the first/only company in that market within a given window of time.  In most cases, this is simply not true.  By talking to people (that you trust at some level) and discussing your idea, you’ll get a better sense of who is out there doing similar things.  Some of these could be competitors – but some could also be partners, customers, acquirers, etc.  As a startup entrepreneur, I prefer to really get a sense of what’s going on in the market I’m looking to enter before getting too deep into it.  If I try to keep the idea a secret, I’m likely not to discover this information until it’s too late.  I would further argue that a founder’s basic fear – that revealing the idea will cause a bunch of people to hear about it, recognize its brilliance and then pursue the idea themselves, is very rare.  [Note to self:  This is a topic worth exploring on its own].

 

So, I would argue that its to your benefit to share information about what you are thinking about doing as soon as possible.  This surfaces potential issues, existing competitors and gives you a clearer lens on reality.  By talking judiciously about your business with advisors, investors, potential employees and others, you can avoid this reality distortion effect.

 

Second, with information that falls into category #2 (that is, how you’re going to do it), I would argue that the truly special/secret stuff you don’t want to reveal anyways (with or without an NDA) unless you’re so far along in a conversation with a potential investor/advisor that it becomes necessary and makes sense.  The fallacy of the NDA in this situation is that it actually has any value.  In most cases, it doesn’t.  As a startup, your ability to actually enforce the NDA is minimal.  What’s left is the vague notion that by signing an NDA, the person/firm you reveal your information to is less likely to cavalierly share it with others.  This is an interesting notion, and I can’t refute it.  

 

Finally, lets take a look at the cost of actually asking people to sign an NDA.  Given that most sophisticated people (investors, partners, etc.) that you will talk to have a policy not to sign NDAs in early stages of a discussion anyways, the simple act of actually asking for an NDA often signals to the other party that you’re new to the game.  If you had a fair amount of experience, they reason, you would know not to ask, as it’s just not going to happen.  

 

So, to summarize my points:

 

  1. Its often in your interests to share the “what” (but not details of the how) as early in the process as possible.  In this case, an NDA is not relevant.
  2. Don’t rely on an NDA to protect the truly “secret” stuff.  It’s likely not going to give you the protection you think it is.
  3. Your odds of actually getting someone to sign the NDA are low anyway, so it’s likely not worth the effort.

 

This is a reality distortion that is relatively easy to avoid.  Just don’t it.  Existing behaviors are well established and you’re not likely to change them.

Continue Reading

Agile Software Startups: The Myth Of The Perfect Business Plan

April 14, 2006

Lets say I had this idea for a great software product.  If I told you I was going to spend the next 3-4 months writing (and rewriting) the product specification and design documentation and do everything I could to address what I thought would be the key issues, and then expected to actually use that document to build a near-perfect product that was going to succeed in the market, you’d likely dismiss me as being na?ve or inexperienced or both.

 

Why?  Because, clearly, if we’ve learned anything about software development it’s that the process is difficult to completely plan for and much of what actually happens has to be emergent and “iterative”.  Though you may not be a fanatic follower of any of the specific agile methods (like XP), chances are, you basically agree with some of the fundamentals of the movement.  Chances are, you wouldn’t develop a relatively sophisticated software product today without using some agile methods.  Chances are, you wouldn’t be blindly using the waterfall approach in its original form.  The most important agile principle (at least for me) is the need for iteration.  In an agile development world, we do not try and predict every possible situation our product will need to handle, but we iterate and improve and refine – with the help of users/customers.

 

So, why is that when it comes to starting businesses, so many of us otherwise experienced and savvy software developers fall into the “waterfall trap” and spend inordinate amounts of time writing and refining the business plan?  I would guess it’s because we think that a business plan is a necessary component for raising funding (from VCs, angels, etc.) and that funding is a necessary component for actually building the business.  As it turns out, this is not really true.  You can start a software business without raising funding, and you can raise funding without writing a business plan. 

 

Why not take some of the same ideas we’ve learned from agile software development and apply them to software startups?  Though I recognize that developing businesses and developing software are different in many ways (I’ve done both for longer than I care to admit), there is enough in common that its worth thinking about.  In this light, I humbly offer to you the agile startup manifesto with credit to the original.

 

The Agile Startup Manifesto

 

We, the entrepreneurial software developers of the world believe that we have uncovered better ways to launch and grow successful software businesses.

 

Through our experience, we have come to value:

 

  1. Useful software over a comprehensive business plan.  We would much rather focus on creating value – in the form of (somewhat) working software, than planning to create value in the form of a business plan.  

 

  1. Customer revenues over external funding.  Customer revenues are the clearest evidence that we are solving the right problem.  The sooner we figure this out, the better.  If we want to learn about what users might want in a software product, we ask the users.  If we want to learn what the market might or might not want in an offering, we ask the customers.  Customers communicate with their cash. 

 

  1. Responding to change over following a plan.  We realize that most software businesses (especially the ones that survive), rarely stick to their original idea.  Flexibility is key.  We realize that most of the information we need to succeed with our strategy will not become clear until after we launch the company and product.  Recognizing this, we focus on responding to change rather than stubbornly following our original plan.  The key is to iterate.

 

  1. Building It well over building to sell.  We have learned that the best software developers design and develop products that they are passionately committed to “getting right”.  Programming is an expression of the ideas of the developer which blends in real-world feedback from customers.  There is pride of authorship.  These are the software products that succeed.  Just like we wouldn’t develop a software product with the notion that we’ll simply be “passing it off” to someone else to maintain later, we don’t build businesses with the express intent of “flipping” them some day.  This leads to mediocre businesses that are at the whim of the market.  Instead, we design our companies much like we would design our software.  With an eye towards balancing the difficult tradeoffs, and building something that is designed to endure.  Like our software products, we would rather build it well.

 

I think that individuals and companies that use agile methods have a distinct advantage over those that don’t (and likely have a lower failure rate – though I can’t prove this).  I would similarly argue that applying agile principles to software startups would likely have a similar effect – a lower failure rate and better businesses that actually create real value and are sustainable.

 

If there are other ideas and concepts from software development that you think have parallels with software startups, please share them.  

Continue Reading

PowerPoint Presenters Anonymous: Breaking The Habit

April 7, 2006

Hi, my name is _______ and I’m dependent on PowerPoint.  It started out slowly.  At first, I did it because it was what everyone was doing.  And, it was relatively easy to fall into the habit.  The software  was easy.  It made me actually think about my message.  And, nobody ever got fired or thrown out of a meeting for using PowerPoint.  Eventually, it came to the point that I couldn’t even imagine doing a sales or other type of pitch without a deck of PowerPoint slides.  I would just feel naked.

 

Does this describe you?  Be honest.  In what percentage of your presentations and meetings do you use PowerPoint (is it close to 100%)?  Do you simply feel “unprepared” getting in front of a group unless you have some slides?  If so, then read on.  You too can break the habit.

 

Now, I’m not saying that PowerPoint is a bad application.  In fact, for what it does, it does pretty well and it is powerful when it needs to be and has all sorts of neat functionality.  My issue is not with the application, but with the premise.

 

First off, a little background (and a little bit of a disclaimer).  When I started my first company, I actually banned the use of PowerPoint for just about all of our meetings – both internal and external.  This “rule” stayed in place for about 7 years.  My issue was not that I didn’t like PowerPoint, but I just found that it got in the way.  It locked me in and forced me to devise a “message” or a “story” without knowing enough about the customer.  As it turned out, life was just fine without PowerPoint   We made sales, closed deals, evangelized and educated – all without PowerPoint.  

 

If you’re getting skeptical, try and stick with me for a bit.  Lets assume for a minute that my situation was not that different from yours and that there was nothing particularly special about my startup that made it uniquely positioned to live without PowerPoint.

 

My thesis:  In most cases, you should not be delivering a presentation, but having a conversation.

 

Lets assume that you are making some sort of pitch.  The most common is a sales pitch, so that’s what we’ll use.  However, my points below apply equally well to other kinds of pitches (like an investor pitch).

 

Why PowerPoint Presentations Often Don’t Work

 

  1. Too One-Sided:  I’m a big believer in somewhat “balanced” conversations with an audience.  In my experience, it is much easier to convince a customer to buy when you can engage them.  Its really hard to engage them if you’re doing all the talking.  PowerPoint presentations don’t necessarily cause you to say too much, but it sets the wrong stage and it just winds up that way.  As soon as your first slide is up on screen, people assume you’ll be doing most of the talking.

 

  1. Too Presumptuous:  When crafting a PowerPoint deck, you are almost automatically presuming a bunch of stuff that simply might not be true.  The biggest assumption is that customers care about what you have to say.  In many cases, they don’t.  While you drone on about this feature and that benefit and how your software is “scalable, flexible and powerful” the odds of your closing a deal are actually going down – not up.

 

  1. Too Much Message Lock-In:  Think back on the number of times you’ve done a presentation with PowerPoint and when you’ve wished that what was up on the screen wasn’t there.  But, you feel like you have to say something anyway, because there’s that slide that everybody is now looking at and reading.  A major issue with using PowerPoint is that it takes away some of your flexibility.  I’m not suggesting that you should be “spinning” a story here and changing your message to pander to the audience.  What I am  saying is that there are a million possible things you could say during a presentation.  Which points you highlight and what you actually decide to communicate should be a function of what you have learned about the customer and what furthers the cause and not what just happens to be on the slide on the screen.  You should be driving the message – not your slides.

 

  1. Too Detailed:  Many people create PowerPoint decks that are “stand-alone”.  The rationale here is that people should be able to look at the slides and have a general idea of what the presentation is about.  This is totally and completely wrong.  In fact, if your presentation can do a pretty good job communicating your message on its own (i.e. without you), then it’s the wrong presentation.  If you’re going to do a presentation, it should be simple.  For a great article on this, go read Guy Kawasaki’s Article.  This also why you should never, ever send your presentation before-hand or print them out and pass them around at or before the meeting.  They’re simply not designed for that (or shouldn’t be).

 

So, lets envision a world (or at least a sales meeting) where you don’t have PowerPoint.  What happens?  I’ll tell you.  People are a little surprised at first (but not negatively so).  You may fear  that without a PowerPoint deck, customers may believe that you’re not prepared for the meeting.  That you haven’t done your homework.  As it turns out, this is usually not true.   Customers decide whether or not they want to listen based on what you have to say and the value you bring to the meeting – not if you just happen to have a set of slides.  They have no idea who created the slides anyway. 

 

Without PowerPoint, you can actually position yourself as something other than “just another sales person”.  In fact, at the beginning of most of my sales pitches, I would introduce myself as a technical guy, and not a sales guy.  (This had the added value of being true).  Just on this point alone, customers tend to let their guard down a bit and open up.

 

Without PowerPoint, you’re setting the stage to have a conversation.  You can ask questions.  You can make forward progress.  You can focus on areas that are of actual interest (instead of just blindly working through all the slides in your 20-slide deck).  Magical things happen when you have a conversation with a customer.  Customers tell you things.  Useful things.  If they believe that you’re listening and actually capable of actually helping them, lots of things happen.  In the best meetings, you’ll feel like you’re jointly collaborating to solve a problem.  The sale becomes incidental.  Though I’ve never been to formal sales training (I’m a programmer), I have sold millions of dollars of software this way.  It works.

 

And, lest you think that presentations without PowerPoint can only be done in small groups or for short meetings, you should know that I’ve presented to somewhat larger groups (in excess of a hundred people) on a big stage, with a pretty complicated topic, for up to two hours.  I’ve done this several times, and the audience feedback has been positive each time.

 

So, here’s my idea for you:  Just once, take a chance and walk into a meeting with lots of ideas – but no PowerPoint presentation.  Set the stage for a conversation.  Let the customer talk.  Listen intently.  See how it feels.  See where it leads.  Who knows, you might just be able to break the habit.  Even if you go back, at least you’ll do it with a better recognition of why you’re using PowerPoint.  And, remember that I’m not advocating eliminating PowerPoint from your toolbox completely (it certainly has its place), but figure out when you think it helps, and when it doesn’t.  Just be a little thoughtful about it.

 

Continue Reading

Startup Lessons From The MIT and Harvard Strategy War Game

April 5, 2006

Recently, I led a team from MIT in the second annual “strategy war game” with Harvard Business School organized by Fuld and Company.  The event was held on Thursday, March 30th in Cambridge, MA.  I was a participant in last year’s battle (MIT won).  This year, the battle was even more competitive.  The judges were more critical in their assessment and opposing teams more “aggressive” in their questioning.  However, much fun was had by all.  MIT won again this year (makes two years in a row for both MIT and me).

 

This year’s topic was “The Battle For Digital Entertainment Supremacy”.  Basically each team had to devise strategies for a randomly assigned company (the companies possible were NewsCorp, Microsoft, Apple and Verizon).  These strategies were then presented, while opposing teams asked questions, objected and otherwise critiqued the strategy.  Judges chimed in as well with thoughtful (but pointed) questions to the presenting team.  The judges were all “neutral” (no school affiliation) and from industry (IDC, Gartner, Yankee Group, etc.).  After initial presentations, the organizers provided a “random but plausible” external event.  This year, the event was:  “Dell and Wal-Mart have announced a partnership whereby they will jointly develop and offer a fully integrated entertainment system with Internet connectivity”.  The task in Round 2 was then to respond to this event.

 

Enough by way of background.  What does any of this have to do with startups (which is the topic of this blog)?  Why is this article nothing more than an ego trip for me because MIT just happened to win both years?  I’m glad you asked…

 

Strategy Battles And The Startup Game

 

  1. Even In Academia, Winning Strategies Don’t Always Win:  Looking at the war game objectively, most people could have argued that Harvard’s presentations and strategies were just as cogent and defensible as MIT’s.  Many would argue that they were even better in some cases than those of MIT (though I personally wouldn’t argue this).  However, I would posit that strategies don’t win competitions (neither in war games or in real life), teams win.  

 

  1. Think Co-opetition:  In the digital entertainment industry (and in many other industries), winning is not always about taking market share away from your competitors.  Strategy in today’s world is much more nuanced.  From a startup’s perspective, success can often be built on picking the right partners and platforms.  This is a case of competition and cooperation (hence the best selling book “Co-opetition” – which is well worth the read, if you haven’t picked it up yet).  Partnerships for startups are very, very hard (I’ll be writing about this in an article next week), but often a great way to overcome early obstacles.  For startups, its critical to really look at each of the players in the industry (big and small) and figure out on what points you really compete – and on what points you can collaborate.  I would further argue that almost nobody is just a “pure” competitor.  There are always opportunities for collaboration (though, admittedly, they may not be the most strategy in all cases).

 

  1. Don’t Deliver A Presentation, Have A Conversation:  Too many people feel like they need to get up in front of a room and “deliver” a presentation.  Selling a strategy (to judges) is not unlike selling a product (to a customer).  There are a few things to remember:  Customers are people too.  Success is often a function of how much the audience/customer is “engaged”.  And, its hard to engage if you’re doing most of the talking, and your PowerPoint slides are doing the rest.  Pitches (sales, investment, strategy, whatever) are all about “telling a story”.  MIT took a big risk in Round 2, and actually used no PowerPoint slides.  Practically unheard of in this kind of setting (particularly since the task assigned was to “build a strategy presentation and deliver/defend it”).  We ignored the task and focused on the goal.  We had a conversation.  (For the record, MIT scored the highest points of all teams on that particular round).  Conversations win.  [Editor’s Note:  I have a forthcoming article titled “PowerPoint Presenters Anonymous – Breaking the Dependency”]

 

  1. It’s Hard To Fake Preparedness:  Quite simply, the MIT team was by far much better prepared than the Harvard team.  Everyone on the team knew everyone else.  We had talked about the topic before “game day”, and discussed/debated the salient points.  In our minds, we had already won before we even walked in the room.  Winning was not about winning the battle (though that was certainly important to us), winning was about learning about the topic, using our new-found “MBA skills” and most importantly, learning about each other.  So, in this case, as is the case with startup management teams, preparing is as much about knowing your team as it is about knowing your industry, products and competitors.  And, much like startups, its important that you focus on the ultimate objective.  Its not about “equal stage time” for all the participants.  Its not about “fostering and growing” each of the employees.  That’s a luxury that’s earned and must come later.  In the early stages, you’re leveraging your team strengths to survive.  Having this team chemistry is about trust.  Individual team members must trust each other to do “the right thing”.  

 

  1. Nothing Motivates Like Winning:  This is going to seem obvious, because it is.  Nothing motivates a team like winning (except perhaps losing, with a chance to come back).  Once you have a win, it can bring the team together in unparalleled ways.  It validates things you thought you knew.  It encourages risk-taking (because most wins involve some risk-taking).  And, it just feels good.  Incidentally, the MIT team actually talked about what it meant (for us) to win.  We didn’t just want to “beat Harvard”.  We wanted to represent MIT admirably and “create value for the participants”.  We wanted to be creative.  We wanted to say something meaningful for everyone in the room (including representatives from Microsoft and Verizon).  As Seth Godin would say, “We wanted to do something remarkable”.

 

With that, we’ll bring this to a wrap.  My compliments to the smart people from Harvard – you played an exceptionally good game.  I was worried the whole time.  Just like being a CEO, credit for winning goes to the team, responsibility for failure goes to the leader.  J  I’m just glad I’m graduating and hence won’t be participating in next year’s game.  I’m sure Harvard will be coming back with a vengeance.  I know I would.  Thanks also to Fuld and Company for organizing the event.  It was another great event.

 

 

Continue Reading

Startup Websites That Work

April 2, 2006


I am continually amazed by the lack of attention many startup founders and management teams give to their startup websites.  Too often, it's treated as a necessary evil (they’ll spend some time on it initially and then forget about it).
 
Disclaimer:  For my latest startup venture I’m working on a web software platform to make it easier for very small businesses (less than 25 employees) to do meaningful things on the web.  So, I have a bit of a bias here – but I’m not trying to sell you anything (yet), other than my opinions.
 
If you are delivering web-based software then you should already know that your website is critical (it's your business!).  But, even if you’re selling non-web software your website is very important and worthy of you spending some time thinking it through.
 
The following are my tips for creating a website that will actually work for you.  Think of your website as a relatively important employee (like a sales person). You need to spend some money, get them trained and keep them engaged.  Your website is no different – and will likely be cheaper and more productive.
 
Tips For Startup Websites That Work
 
  1. What will you do for me?  What does the product do?  Why should I care?  Answering this is much more important than sharing with me your philosophy of the world and how you’re all about “connecting individuals on the Internet through an intelligent and collaborative engine that is scalable, AJAX-powered and cool”.  Honestly, I don’t care.  Tell me how my life is going to be at least marginally better if I use your product.

 
Example:  Our MailMinder product will make sure that you don’t forget to respond to important messages that you receive in Outlook.  Just press a single key (1-9) and MailMinder will automatically remind you if you haven’t responded to that message within the specified number of days.  So, if you press “2” on a message and haven’t replied to it in a couple of days, you’ll get a friendly reminder.  (Note:  This is a completely made up product idea and any resemblance to an actual product, living or dead, is purely coincidental).
 
  1. Who is it for?  This one is subtle.  A great way to really grab my attention is to tell me who you’ve built the product for.  The reason so many companies don’t disclose this is because they think they’re going to “lose opportunities” by being too narrow in describing their ideal customers.  Its simply not true.  Do your potential customers and yourselves a favor and be focused in your message and offering – ultimately, the right kinds of people will wind up at your site and your sales will go up not down.  

 
Example:  Our software is specially built for technical book authors that would like to start a blog as an online extension to their book and build a community for their readers.
 
  1. How does it work?  Here, a picture (or a short video) is worth a thousand words.  In a minute or less, give me a general sense of how the product works.  Examples could include screenshots, video captures, or sample results produced.

 
  1. Why your product and not something else?  Chances are, I didn’t happen upon your site randomly.  I was probably looking for something or was led to your site from somewhere else.  And, despite how unique you think you might be, chances are that I’ve already considered other alternatives (and may even have tried a few).  Tell me what makes your product different.  You can be even more clever if you know what other products I’m likely to have tried that are similar to yours.

 
Example:  Tired of the limitations of XYZPro?  So were we.  So we did it better.  Hundreds of XYZPro customers have already switched. Here’s why…
 
  1. What does it cost?  Throw out complicated pricing formulas and don’t believe the marketing professionals that tell you that you should sell a customer on your “value proposition” before telling them what it costs.  In today’s world, with so many options, if I can’t figure out what your price is in the first 5 minutes, I’m probably gone.  Don’t make me email sales@somecompany.com to get a “price quote that is tailored for my needs”.  Worse, don’t make me contact my regional sales rep.  (In fact, if you have regional sales reps, you’re probably reading the wrong blog – its meant for startups).

 
  1. How can I try it?  Its software.  There’s no reason (at least that I’d understand) that there shouldn’t be a way for me to “try before I buy”.  Offering a trial version reduces the customer’s risk and puts the burden on you to deliver something of value. 

 
  1. Who’s behind it?  I don’t need to read your life story or see a “board of advisors” list that reads like the who’s who of the business world.  But, based on how much I expect to spend (in time and/or money), I’m likely going to want to know that there are actual humans working for the company.  You don’t need to misdirect and create the illusion of size (being small or even a one-person company is perfectly fine), so be honest. 

 
  1. Where are you?  Call me old-fashioned and traditional (which I’m not), but I tend to want to know where the company is that I’m about to do business with.  A physical location disclosed on the website signals to me that the company is not “hiding” out in the virtual world.  If all I can learn about you is that you have an email address that is info@somecompany.com and that support is going to be provided by support@somecompany.com, then I get a little concerned. 

 
  1. Keep me posted:  Sometimes, customers may be interested in your product, but just not now.  Either it's too early (they’ll only use products that have 10,000 users), doesn’t support some critical feature or operating system, doesn’t have the right license (example: no source code), or isn’t at the right price point.  Provide an easy way to let customers know when you hit major milestones.  This can be done via RSS, email subscriptions or other means.

 
Extra Credit:  If you can provide an easy way for customers to tell you why they’re not interested now (example:  Let me know when you support add support for X), you win even more points.  The prospective customer becomes aware that you’ve considered this limitation and you have a way of gauging which limitations are keeping customers away.  So, if 4 out of 10 customers say they want to be notified when you support Outlook integration, it may not be a bad idea to consider that feature.
 
  1. Look Alive!  I like to see that a company is “alive”.  This can be done by the management team maintaining a blog, having product support forums (that are monitored), issuing press releases, posting release notes, etc.   Somehow, signal to me that the company isn’t already dead and that there are signs of life somewhere.  This is the Internet equivalent of walking by a store and not seeing anybody there through the window.  The immediate question most people wonder:  “Is anyone home?”

 
Though all of the above take some thought and effort, it is likely that this investment will pay off very well.  Today’s customers have short attention spans and a generally cynical nature.  There are simply too many things competing for their time and money for them to cut you any slack.  If you doubt this, monitor your own behavior when it comes to browsing the web and evaluating products.  If you’re honest with yourself, you’ll learn lots of interesting things about how/why customers buy.  Just put yourself in the shoes of the customer.  The power of empathy is amazing and will teach you a lot.  If you were a random visitor to your own website, what would you think?  And, if a website did all or most of the things above – would you be more likely to try or buy?  
 
 
 
Continue Reading

The True Value Of A Customer: Introducing CustomerRank(TM)

March 29, 2006

If you’ve ever run a business of any sort (whether software or not), you’ve probably given some thought to the “value” of each of your customers.  Different industries look at this differently.  For example, successful car dealerships often look beyond just the current sale and more at the “lifetime potential value of the customer”.  This is because not only is the person that walked in the door today making a decision on what car they will buy today, they are also creating a future opportunity for you to sell cars to them tomorrow

 

A relatively simple way of measuring the value of a customer could be expressed as a function of:

 

  1. Revenue Generated:  How much money the customer is paying you.
  2. Cost to Acquire:  What it cost you to get the customer to start paying you.
  3. Cost to Serve:  What it costs you to ensure that the customer continues to pay you.

 

There’s nothing magical here.  Basically., the above are the key drivers of profitability for a given customer. If any of these are “out of whack”, its likely you have a not-so-good customer.  There are volumes written about ways to look at customer value through these different lenses (including articles about firing your worst customers to improve your business).  I’ll save the topic of firing customers for another day.

 

However, I think that in the age of the Internet, life gets more interesting for software startups.  So, let me introduce what I think is a relatively new (and hopefully useful) concept:

 

CustomerRank?:  An algorithm that allows the ranking of customers (or clients, or sales leads) based on their true value which is measured as a function of the following variables: 

 

  1. revenue generated
  2. costs to acquire
  3. costs to serve
  4. magnitude of useful learning
  5. and  the CustomerRank of any additional opportunities that they can generate for you

 

These last two new items are what makes this interesting.  

 

Magnitude of learning goes to the point that we often get our best ideas from our customers.  They do this by requesting enhancements (that help other customers), complaining about poor service (so we can fix it), threatening to switch to a competitor (often ones we didn’t know existed), etc.  Some customers teach us a lot of useful things.  Others don’t.  This is a key variable in calculating CustomerRank.  The more useful knowledge we can get from a customer, the higher their rank to us.  Oddly, many software startups end up giving their software away for free (see my prior article for why this may be ill-advised) under the assumption that simply having lots of customers has value.  Though this is certainly true, not all customers are the same.  Some may be creating minimal (or no) value and others are creating lots of value.  

 

Those of you that are familiar with Google’s PageRank will likely pick up on the last item (#5 above) immediately.  Google’s PageRank basically calculates the “rank” of a web page by a combination of the contents of your page and the number/quality of inbound links (based on the PageRank of those pages).  Its this “connected” nature of the algorithm that is intriguing.  Google will “weigh” a link that points to your page higher based on the ranking of that page.  So, if The New York Times links to your home page, it means a lot more than if I link to you from this site.  

 

We have a similar concept with CustomerRank.  Customers that are well connected to other “high value” customers get a higher rank.  For example, if a non-profit organization is a customer of yours and is paying you nothing, they may still have a relatively high rank if they have a bunch of people they are “connected” to that would make good paying customers.

 

So, customers can get a higher “CustomerRank” and thus receive preferential treatment (however you define that) by doing any of the following: [Note to Self:  Write future article about creative ways to show preferential treatment to the highest ranking customers]

 

How Customers Can Rank Higher

 

  1. Spend more money.  This is the easy one.  

 

  1. Be Easy To Sell To:  By making themselves easier to reach, they get a higher rank.  If it costs you two plane trips to get the customer, it reduces their CustomerRank.  Conversely, the customers that make it simpler/cheaper to earn their business get credit.

 

  1. Be Simpler to Service:  Customers that cost the least to support get a higher rank.  Basically, this credits those customers that really “get” your business, what you’re bringing to the table, etc.  They’re not looking for a ton of custom features that have nothing to do with where you’re headed, free consulting/training, etc.  

 

  1. Teach Us Something Useful:  Customers that can help us improve our product deserve to be credited for doing so.  This is the premise for so many “free” services that are out there.  But, not enough software companies actually quantify what is learned from each customer and make the mistake of treating all customers equally.

 

  1. Be Connected To Others:  Customers can raise their rank simply by being better connected to the community (and other customers).  Basically, this credits those organizations that have invested the time to be thought-leaders (even if they can’t spend that much money on your product/service).

 

Now, some of you are thinking of posing the following questions:   “don’t all customers deserve the best service and price?” and “aren’t we supposed to be earning their business and not expecting them to earn a higher rank?”  The answers are no and yes.  I’m not suggesting that we try and influence customer behavior (we should indeed be happy and grateful that they are our customers), but I’m trying to suggest that we change our behavior to truly reflect “real customer value”.  

 

Some quick (and possibly debatable) ideas of how this may be applied in your software startup, should you try and implement CustomerRank:

 

  1. Credit customers that report bugs or request enhancements – based on what you actually end up doing.  Example:  A customer is the first to request an enhancement that many other customers want and that you actually implement.
  2. Credit customers that find you directly over the web (and hence have a reasonably low acquisition cost).
  3. Credit customers that give you a testimonial on their website.  Better yet, track how many web-link referrals you’re getting from their site (that is, how many of your visitors came from your customers site).
  4. Track how much labor it takes to get the customer live. Note:  Hours you spend fixing your own product which then has value to future customers doesn’t really count.

 

Obviously, implementing a semi-accurate CustomerRank algorithm is non-trivial.  The idea here is to just provide some useful visibility to some key variables that have not gotten enough attention:  customer learning and customer connectedness.  

 

On the other hand, if you’re a software entrepreneur and want to build a CRM product for small software companies centered around this concept, email me.  I’ve got some additional ideas on the topic (and have the CustomerRank.com and ClientRank.com domain names pre-registered for our use).  I’ll be attempting to bake this idea of CustomerRank into my own software offerings for HubSpot.

 

Continue Reading

When Raising Venture Capital Might Make Sense

March 28, 2006


Those of you that read my previous article “Fatal Distraction:  The True Cost of Venture Capital”, may have thought that I’m against venture capital and venture capitalists – neither of which is true.  VCs are generally smart, savvy people and serve an important function.  In fact, some of the vibrancy of the U.S. entrepreneurial market is attributable to our strong VC community.  My issue is not with VCs, but with the appropriateness of VC investments for most software startups and the lack of a true appreciation for the dynamics of the VC process within most first-time entrepreneurs.
 
Though I still stand behind my points in the earlier article, and continue to believe that venture capital generally doesn’t make sense for most software startups, there are indeed cases where raising VC might make sense.  So, here are some reasons that you may want to consider raising venture capital for your startup:
 
  1. Your Business Model Is (Somewhat) Proven:  You have already demonstrated that your business model works (i.e. there is clear evidence of customer interest in your product and that you have a reasonable chance at reaching profitability).  In this case, capital can often be deployed efficiently – which is just a fancy way of saying that you can actual use the money to expand and scale your business.  This is often by expanding the team, increasing the sales force, broadening the product reach, etc.

 
  1. You Need An A+ Management Team:  The business you are pursuing requires a proven, exemplary management team -- now.  Many proven professionals can be convinced to accept compensation that is less than fair market value (i.e. what they could make elsewhere), but there are limits to the risks they are willing to take – no matter how much they like you or your idea.  In this case, capital is often critical to attract the right people into the company.

 
  1. You’ve Started A Business Before:  If you’ve run a business before (especially one that had outside investors), you generally have a better understanding of what it actually takes – and  as such,  you are much less likely to make the “rookie” mistakes that plague many first-time entrepreneurs.  Your odds of actually successfully raising capital also go up (so the distraction risk is lower).

 
  1. You’re A Major Player At An Established Company:  This one is a little more subtle,  If you’re a high-powered executive at a major established company, chances are that you have industry contacts, domain expertise, etc.  This makes it more likely you will actually raise outside capital.  Also, this means that your “opportunity cost” is probably higher than someone less experienced.  As such, it may make sense for you to reduce your risk when launching a startup by bringing in some outside capital.  Instead of working for zero (or minimal) salary indefinitely, you’ll then be able to pay yourself something.  However, remember that this is not the “full” entrepreneurial leap that many associate with a startup.  You are in some respects replacing working for a large company to working (to some degree) for your investors.  This is not necessarily a bad thing, but its best to understand that you’re not fully your own boss as much as you might think or had planned.

 
  1. You’re Swinging For The Fences:  One of the biggest downsides to raising capital is that there is commonly a misalignment of goals.  You’re looking for a high probability of a modest exit and the investors are looking for a low probability of a fantastic exit.  However, if this is not the case – if you’re actually fine with having a small chance at a big win – and you believe your idea provides a credible story that VCs might believe, then it might make sense to raise capital.  Venture Capitalists are always on the lookout for big market opportunities (large, growing markets) as one of their fundamental criteria for investing.  If this sounds like you, then venture capital might be the right path.

 
  1. You’re Already Got (Real) VC Interest:  Much of the downside (in my mind) associated with the VC process is that the chances of actually closing a round are so low – and the time spent courting VCs can be much better spent elsewhere.  But, if for some reason, you already have real VC interest in your startup (they like the idea, you, one of your co-founders, etc.) then the decision is simplified as you can then focus on whether the investors are someone you want to partner with and the terms are something you can accept.  

 
Overall, its important to understand that VCs are looking for specific kinds of deals.  If you happen to fit into this narrow category and truly believe that your odds are well above average of closing a deal, by all means give it a shot.  It makes sense to consider all of your options.  On the other hand, if you’re not reasonably sure that you have the right mix of ingredients that will attract a VC, the points from my previous article still hold – chances are, you’re better off looking at other avenues.
 
If you’re an entrepreneur (or for that matter a VC), and have other reasons why raising venture capital might make sense for software startups, I would love to hear them.  Leave a comment here or email me privately:  dshah (at) onstartups.com
 
 
Continue Reading

Fatal Distraction: The True Cost Of Venture Capital

By Dharmesh Shah on March 22, 2006

I’ve had several requests in the past week to post an article with my views on venture capital for software startups. This was driven partly because I often make casual and vague references to being “generally against venture capital for software startups, in most cases”. I’ve not written on the topic yet, because there’s a lot of good writing on the topic already on the web. But, there seems to be interest, so here we go.
There has been a lot of negative sentiment regarding venture capital, most of it which centers around two basic notions:
  1. Venture capital is often the most expensive form of capital one can raise (when looking at the cost of capital)
  2. Venture capitalists themselves are often seen to be predominantly arrogant, self-absorbed, heavy-handed, jerks (though, as always, with exceptions)

Though both of the above points are broad generalities, I think they’re more or less accurate. VCs (on average) are very, very smart and have very, very aggressive (“type A”) personalities. This, combined with the fact that they hold the purse strings and generally have much more “power” in the negotiation than you, the entrepreneur, do – often leads to the stereotype of “jerkiness”. Further, VCs can rationalize their behavior claiming that they are responsible for investing other people’s money – and they’re just doing their job. Though they could rationalize this way, they generally don’t (the personality type doesn’t lend itself well to having to explain anything). In any case, it is what it is. There are some nice VCs out there, but I really do think they’re the exception. But, this article is not about VCs being jerks. That wouldn’t be particularly interesting.
So, if you’re looking for additional content to reaffirm your views on VCs being jerks, feel free to do a search on “vulture capitalist” or other similar terms and you’ll come across plenty of amusing and educational reading on the topic. You can then feel comforted in the knowledge that your views have been validated and go about your life with some well-deserved satisfaction. Peace be with you.

If, on the other hand, you’re somewhat interested in digging a little deeper and figuring out what the true costs of venture capital are, read on.

For purposes of our discussion, I’ll assume that you have not raised significant capital from VCs before and that we’re talking about “early stage” capital.

So, here, in no particular order are what I believe to be what contributes to the *true* cost of venture capital:

Understanding The True Costs of Venture Capital
  1. Sub-Optimal Use Of Founder Time: When you decide to try and raise venture capital, you are basically committing to expend a fair amount of your time in the process. This time is spent on documenting your plan (either an executive summary, PowerPoint, business plan – or all three), “pitching” your opportunity (i.e. VC meetings) and follow-ups to those meetings as VCs ask for more detail, other meetings, etc. Assuming for a minute that you get a yes/no answer relatively quickly from VCs that you pitch to (which you generally won’t), you are still spending a lot of time trying to create a “story” that is fundable. More often than not, this wasn’t the story you started with. Now, if your prospects for success were actually improved as a result of doing all of this work and having all of these conversations, this wouldn’t be such a bad thing. You could then think of this as free consulting from really smart people (and trust me on this one, VCs are really smart people). However, unfortunately, this time spent is rarely worth it (for you). Most of the time you spend putting your story together has minimal positive impact on your actual business. I can’t prove this, but I still think I’m right. Now, given that the most common answer you get from a VC pitch is “maybe”, you will generally spend a lot of time trying to “fill in the blanks” and respond to the questions/concerns/issues that the VCs have. Though some of this work may actually be useful, I’ll still categorize it as “sub-optimal” because it is not the best time you could spend to improve your odds of success.

  1. Non-Fundable Ideas Are Not Always Bad: Lets assume that your odds of actually convincing a VC to fund your business/idea are really, really low (which they are). If they were simply rejecting ideas that had no chance of succeeding anyways, then they’d be doing you a favor. Rejection simply means they saved you a bunch of future grief. Unfortunately, this is not the case. Simply because an idea is not VC-fundable provides little information regarding whether or not it could have been a successful business. The VC benchmark is often so high that even rational, reasonable business ideas get rejected. So, the cost to you here is that you automatically assume that your failure to raise capital is conclusive proof that you had a failure of a business. Though indeed, your idea/business may suck (I’ve had many, many ideas that ranged from mediocre to bad), rejection from VCs is not a way to reliably determine that.

  1. Misaligned Goals: What you would call a “success” is very different from what the VCs consider a success. What you’re looking to do is somehow figure out a path that leads to a decent chance of putting about $3-5 million in your pocket in 3-5 years (numbers vary, but this is as good as any). With this kind of money, you could invest it all in long-term investment vehicles and live a reasonable life doing whatever you want. You’re not going to be buying small islands, but (I’ve been told) this is highly overrated anyways. VCs, on the other hand want a small chance at making a lot of money (i.e. 10 times whatever they invested). Why the asymmetry? Very simple. VCs have a “portfolio” of companies (so their risk is diversified). They want 1 or 2 out of ten companies to succeed tremendously – so on average, they are making a great return for their investors. They don’t care, if any specific company (like yours) dies – as long as the portfolio of companies does really well on average. You, on the other hand, have all of your eggs in one basket. When your life savings is wrapped up in the company (which it will be), then it is in your interests to optimize for the modest exist – anything else would be bordering on stupid. Basically, you and the VCs are looking for different things – and thereby running different companies.

  1. Cost Of Capital Is Very High: Putting aside all the “softer” stuff above, its important to remember that the cost of selling your equity to a VC is actually very expensive. For discussion purposes, assume that you were offered a loan (I understand the difference between debt/equity – I’m just trying to make a point). Lets say the interest rate is 30%. Most people would think that was very “expensive” and would think twice about taking the loan unless they really, really had a strong belief that they needed the money and could do something with it to overcome this “cost of capital” and were desperate because there were no other alternatives. Unfortunately, raising VC money has a similar dynamic, its just not that clear at the time you do it what your cost is. If it helps you understand it better, remember that VCs are expected to return 30%+ to their investors. By definition, these returns (and the VC salaries and bonuses), can only really come from one place – the startup companies. Sure, you may not necessarily incur this cost – but on average, somebody is paying for it. I’m not a brilliant financial mind, but even I understand this bit.

  1. Limited VC Control: Yes, you read that right. I’m saying that VCs actually have very limited control in what they can do in regards to your company – and that’s a bad thing. Things VCs control include limiting founder compensation, limiting how much cash can be taken out of the company, how much debt can be incurred, etc. All of these are designed to protect their interests and are reasonably easy to understand. However, when things go badly, there’s very little they can do to “fix it”. Of these, the most drastic is pushing the “CEO eject button”. Basically, VCs can fire the founder/CEO should they choose to. This may be a last desperate attempt to turn things around and try to salvage their investment when things have gone wrong. Now, here’s the problem: In just about all companies, things will always go wrong. Its just a matter of time. The odds of you actually walking the straight and narrow path to success are near zero. So, the cost to you is that in any given year, you may be fired. Perhaps, you may need to be fired, but maybe you don’t.

  1. Fatal Distraction: This is the most subtle of all the costs outlined so far – but, still supremely important. Once you decide to raise venture capital, your reality is distorted. You no longer think in terms of talking to customers, narrowing your focus, building a product, etc. Instead, you become singularly driven by “building and pitching the story”. This tends to distort your reality significantly. Instead of working on figuring out the names of your first 10 potential customers, you try to find an analyst prediction that shows that you are pursuing an opportunity that could be $700 million. Or, when looked at just right, even $1 billion!! Instead of feeling satisfaction from hitting an intermediate goal of getting our product out there (even if its crap), you instead feel satisfaction because a VC called you back for a follow-up meeting. Instead of measuring ultimate success by shipping a product and generating revenue, you start thinking of ultimate success as being closing your round of capital. As it turns out, even if you do actually successfully raise VC money – you have created zero value. All you have is the opportunity to create value (and, you had that all along). This distraction is very often fatal and has killed countless startups.


Hopefully, the above represents something that is semi-useful and at least moderately objective and balanced. I have nothing against venture capital (or venture capitalists). I just think its important for entrepreneurs to understand the true costs (and risks) of raising VC money. Though being a VC-backed startup founder may seem like a life of glamour and intrigue – its really not. Raising venture capital, and running a VC-backed company is just plain hard.

Note: Much of my thinking on this topic is not first-hand experience. I have raised institutional capital for startups before, but not early-stage money, and not from traditional VCs. However, I have seen my share of VC pitches, talked to many VCs, sat on VC panels, read the books, took the courses at MIT and even befriended a few (of the nice ones).




Continue Reading

Startup Reality Distortion #2: The Lake Wobegon Effect

March 21, 2006

For those of you not familiar with the “Lake Wobegon Effect”, I provide a brief definition located on the web:

 

Lake Wobegon effect (layk WOH.bee.gawn uh.fekt) n. The tendency to treat all members of a group as above average, particularly with respect to numerical values such as test scores or executive salaries; in a survey, the tendency for most people to describe themselves or their abilities as above average.

 

It is named for the fictional town of Lake Wobegon from the radio series “A Prarie Home Companion”, where according to Garrison Keillor, “all the children are above average".

 

So, what does the Lake Wobegon Effect have to do with startups?  Most startup founders I’ve met (including me) manifest this effect to some degree.  It’s a subtle form of reality distortion that causes most software entrepreneurs to believe that they and their companies are better than most others.

 

Here is an example manifestation of this:

 

“Yes, I realize that Venture Capitalists only fund a small percentage of companies they look at, but I am well above average, so my odds are much better than other companies.”  (Note:  Most startup founders think this way, and VCs know, for a fact, that they all can’t be right).

 

So, lets assume (for a second) that you are a victim of TLWE.  As noted, this is not uncommon – in fact, some might argue that if you don’t have an element of this effect (whereby you think you are better), you’re likely not to succeed as an entrepreneur.  Though this may be true, I think there are ways to make this effect (and people’s awareness of it) work in your favor.  The idea is this:  somehow credibly demonstrate how you are actually above average.  The key word here is “credibly”. 

 

So, lets say you are recruiting an exceptional individual to join the management team of your startup.  Lets assume that this individual has already decided they want to work for a startup and are considering several other offers.  (Note:  We could have easily replaced this example with you raising capital from an investor, but I’m getting tired of that example).  Now, chances are, the individual being recruited has heard the following from each of the founder/CEOs of the opportunities being considered:

 

1.      We have a curve-jumping, high barrier-to-entry, disruptive technology that is going to change the world.

2.      We are just two weeks away from: (pick one or more):

a.    Raising a round of venture capital

b.    Signing a big client contract

c.     Finalizing a deal with a big, strategic partnership with a Fortune 500 company

3.      The fact that nobody else of your caliber has joined the team yet is simply because we are in “stealth” mode and have not yet encountered someone as brilliant as you that really ‘gets it”

 

Now, the mistake here is not so much that the above statements aren’t true (they just might be), but that you are assuming that you are the only person making these kinds of statements (or variations thereof).  In reality (when reality is not distorted), you are going to be above average in some dimensions and not others.  Your goal is not just to demonstrate how great you are – but why your company amongst the others she is considering is “well above average” in specific areas of interest.  How do you do this?

 

1.      Get some facts:  Figure out what the real averages in your market are (compensation, size of funding, etc.)

2.      Compare yourself to the real averages and show that you are better

 

The above likely sounds overly simple and trite, so let me elaborate with some example statements:

 

Example 1:  “I read in a recent study that he VP of Marketing for startups in hi-tech companies get about 70% of their fair market value in terms of base compensation, with the remainder in equity and options.  Given how important this particular function is to us, and the fact that we have strong financial backers, we’d be willing to offer 80-85% of fair market value so you are not taking on disproportionate risk.”

 

Example 2:  “We recognize that most VC-backed companies would offer you above $X on average in terms of base compensation.  However, we are not VC-backed and are looking to run the company efficiently so that members of the management team can capture a significant portion of the value we create.  In order to attract exceptional talent like you, we would offer Y% of the company as equity which is significantly above the industry average of Z%.  Of course, none of this equity means anything if the company doesn’t succeed.  Let me show you why we think this is a good bet…”

 

Moral of the story:  Figure out a way to find what “average” really means in your context and devise credible ways to show how you are “above average” in ways that the other party actually cares about.

 

 

 

 

 

 

 

Continue Reading

Game Theory and Software Startups: Part II

March 18, 2006

Thanks to those that read and played the startup valuation game in one of my previous articles.  If you have not yet read the article, I encourage you to do so.  The information below won’t make much sense unless you do.

 

Also, I received some great responses, but wanted to acknowledge two individuals that both emailed in the correct answer (and an accompanying detailed analysis).

 

  1. Dean Fragnito
  2. Alex Hofsteede

 

There were several other people that had the answer right (but left comments in other Internet forums where the article was discussed, so I have no good way to acknowledge them).  Congrats to you too!

 

Basically, the simple answer is that given that it is an even distribution of valuations and the bottom end of the range is zero, Google should offer nothing.  It cannot win this game.  Basically, what we have here is an “adverse selection” problem.  For any offer higher than zero, Google’s issue is that the only companies that would accept the offer are those that have a lower or equal valuation (and they know it, Google doesn’t).  What we have here is also a case of asymmetric information.  If Google makes an offer, on average, they lose money.  The best companies (with valuations higher than the offer), won’t take it.  The worst companies (with valuations lower than the offer), will take it.  Overall, Google loses if it plays this game.

 

What does this pathetically simple and contrived example have to do with software entrepreneurship?  I’m glad you asked.  The larger message here, for software entrepreneurs is this:  You know more about your company than other people do (asymmetric information).  In many cases, you may by the fact that others are facing the adverse selection issue.

 

Lets take a look at an example:  Lets say you are raising venture capital (or some other type of external capital).  Your job is to then provide credible signals to the investor that you are not one of those 9/10 companies that they know is going to fail.  Here are some tips and ideas that flow from this basic concept:

 

  1. Do not send your 100 page business plan to all the VCs you know.  Reason:  The VCs think:  “Only startups that don’t have any contacts in the industry (and hence will have a hard time getting employees, partners and customers) would do this.  Well connected startups would know someone that knows us.   This is a losing deal”.

 

  1. Do not hire an “investment broker” to help you raise money.  Reason:  Same as above – if you need to hire a broker, there’s a problem.  VCs think:  “The best startups with really cool ideas wouldn’t need to hire a broker.”

 

  1. Find a great co-founder that believes in the company:  Reason:  VCs think:  “Here’s someone that gave up their cushy job in a big company to join this startup as co-founder.  They know the business better than we do.  They wouldn’t take on this risk if the startup were really crappy.  Maybe this is a company worth investing in”.

 

The intent here is not to get into a detailed analysis of how to get VCs to invest in you (I’m not a big believer in venture capital for early-stage software startups anyways).  The point here is a little broader:

 

Moral Of The Story:  There are many situations where people you are dealing with are faced with the “adverse selection” problem.  Though you may think you have the coolest idea since sliced bread, they don’t know that.  Further, their experience indicates that every startup thinks they have a cool idea – and their experience also indicates that 90% of them will die.  Your job is to figure out a way around this problem.  Somehow demonstrate that you are in that 10% of companies that actually will succeed.  This applies to investors, partners, employees and customers.

 

In a future article, we’ll look at the issue of “The Lake Wobegon Effect for Software Startups”.  Why all startups think that they are “above average” (which obviously, cannot be true).

 

 

Continue Reading

Startup Reality Distortion Effect #1: Giving Your Software Away For Free

March 15, 2006

Many software startup founders have a bank of early potential customers for their product.  If it’s a general purpose product (that everyone can use), this is often friends and family.  If it’s a more specific product, its generally colleagues (prior employers, prior co-workers, friends of friends, etc.).  A common question in these situations is if/when you should charge these “early adopters” for using your product.

 

I’m not a big fan of giving away things away for free.  Its not that I’m not a nice guy (I am) nor that I don’t think having a free edition can often have good marketing value (it can).  Its just that I think too many entrepreneurs jump immediately into have a free version of their product available without thinking through things completely.  It’s the easy way “to get out there”.  Common rationalizations are “I’m building a user base”, “I’m not worried about revenue right now”, “I just want to focus on building the best product”, “I’m not in it for the money”.  And so on, and so on, and so on.  If you actually believe all of this, feel free to stop reading now.  You’re basically working on a project and not a business.  That’s totally fine.  The world needs people like you.  Go forth and prosper and you have my good wishes.

 

For the rest of you that don’t have the luxury of not making money at your business, read on.

 

Lets say that you have a product that you don’t intend to give away for free.  You intend to charge money for it (someday).  The question is, should you charge the early adopters, the people you know?   These are your friends and family, co-workers and colleagues, your buddy at the gym, classmates from school, etc.   The answer, I think, is yes.  Here are my reasons:

 

  1. It’s a business.  If you are running a business, you need to get comfortable with charging fair value for your product/service.  Though there is certainly some emotional value to being able to give things away for free to people you like, this has to be part of a larger strategy.  It will feel more like a business to you and others if you’re actually getting money for what you’ve built.  Its very gratifying

 

  1. You want candid feedback.  If you don’t charge anything, your early customers will likely not give you the most candid feedback.  Its hard to complain about something when its free (especially if it’s a friend).  Its hard enough to get an honest answer out of friends/family overall (there’s an emotional cost to telling you your product sucks, is overpriced, etc.)  If its free, its even harder.  If you do charge some price, you’re likely to get much better feedback.  Part of that feedback has to do with the price.  Is it fair?  If it were someone else selling it, would they have bought it?   Are they unhappy with it the product because it doesn’t give them enough for what it costs – or are there other issues (i.e. they wouldn’t use it at any price)?

 

  1. You need the cash.  As a software company, most of your costs are front-loaded (i.e. you’ll spend much more in the early days trying to get a product launched).  Though money from friends/family and other early adopters might not be a large amount, it sets a precedent.  

 

  1. You need to learn how to charge money.  Charging money makes you develop the infrastructure to collect payments!  This is probably the biggest reason.  Though its much easier today to collect payments for your product over the web (PayPal, merchant accounts, etc.) – this is still something that needs to be done.  You’ll need to pick a provider, get an SSL certificate.  Link it all into your website.  Deal with refunds.  I can’t tell you how many software entrepreneurs don’t account for this crucial piece of software development.  They launch a beta (or production) version of their shiny new software.  It rocks!  (But, they have no way to actually charge any money – even if they wanted to).  In fact, this is one of the most important aspects of your business (the “purchasing experience”) and too few entrepreneurs test this part of the system.  

 

  1. The early data is very important.  You get early visibility on important financial metrics once you start charging money.  How long does it take for people to make a decision to buy?  What percentage of people that try your software buy your software?  How do you handle unhappy customers? 

 

So, the point here is not that you’re a draconian opportunist that who is looking to squeeze cash out of people you know (I don’t like these kinds of people either).  But, you’re honestly and transparently trying to figure out whether you have created anything of value.  By giving away things for free in the early days, you are basically distorting your reality.  Reality distortion is fine if you’re Steve Jobs (who purportedly walks around with a reality distortion field around him), but its not fine if you’re just a simple software entrepreneur looking to start and grow a business.  

 

Now, the question you’re probably asking yourself is:  what possible advantage do early adopter customers have if they have to pay like everyone else?  Aren’t they doing me a favor by trying out my new product and giving me feedback?  Isn’t that payment enough?  All exceptionally good questions and just the kind of questions you should be asking.  My answer is this:  You need to provide them “enhanced service” instead of free software.  For example, lets say you were starting a high-end restaurant.  Many (successful) restaurant owners don’t give away meals for free (not even in the first week, and not even to friends and acquaintances).  Instead, they give special treatment.  The chef/owner greets them at the door.  They get escorted to the best table available.  They get something “compliments of the house”.  There are many ways (in the software world) to show your appreciation to early customers.  The best (and often most valued) is just listening and responding to feedback.  Help them use the software.  Invest time (and energy) understanding their problems.  Share your expertise (even if it doesn’t necessarily have to do directly with your product).  

 

If it makes you feel any better, remember that even when you are charging money to your early adopters, you are losing money on every sale. Period.  Forget all the fancy micro-economics stuff of marginal cost being low and yada, yada, yada.  All that applies once you’re successful and have recovered your early  expense (and paid your credit card bills and talked your spouse back off the cliff).  In the meantime, even when you’re charging money, you’re still losing money.

 

One closing note:  There are a substantial number of people (including me) that are dubious of early startups with free products.  If I’m going to invest any amount of time learning them and using them

(remember, nothing is ever completely free), then I need to believe they have some chance of surviving.  Otherwise, what’s the point?  So, when I see a company that has a clear way to charge money, it gives me the warm comfies.  Their probability of surviving (and hence letting me reap my investment of time) just went up.

 

The point of the story:  Strive very, very hard for early revenue.  Early revenue is impossible if you’re not charging early customers.  Giving things away has a dual expense:  you’re not getting cash, and you’re not learning what its like to make money and deliver something that people will pay for.  Leave the reality distortion for the celebrities.  You’ve got a business to run.

 

Finally, if you get lots of resistance from some of your early customers, point them to this article.  If they still don’t get it – its possible they’re not a great customer anyways.

 

 

 

 

 

 

Continue Reading

Lessons from MIT: Game Theory and The Startup Valuation Game

March 15, 2006

As noted elsewhere, I’m working on a graduate degree (M.S. in Management of Technology) at MIT.

 

This term, I’m taking a Game Theory class and we had an example come up that I found interesting.

 

Here’s the game: 

 

Lets say you are Google.  You have the option to buy any number of startup companies (lets say there’s a hundred of them, for discussion purposes).  Each company has a valuation (i.e. what the company is worth) of somewhere between $0 - $1,000,000.  These valuations are evenly distributed across the range -- so a startup is just as likely to have a $0 valuation as it is to have a $1,000,000 valuation (or any value in between).   [Note:  Lets not get into arguments of what actual startups are worth, not relevant to this exercise].

 

You, the head of Google are going to offer to purchase the entire company for some price.

 

Here’s the catch:  The founder of the company knows exactly how much the company/idea is worth (somewhere between $0 - $1,000,000).  You have no clue what its worth.

 

However, given the Google brand, what you do know is that whatever price the founder’s think the company/idea was worth, simply by you buying the company, the value goes up by 50% of what the founders thought it was worth (not what you paid).

 

You have to decide how much you are going to offer each of the 100 possible companies (same offer price for each one, because you have no “information” about any of them).

 

Example:  Lets say your offer is $400,000 to all of the companies.  One of the companies (StellarSoftware) has a founder who knows his company is worth $300,000.  Obviously, he will accept your offer.  Immediately you have made a profit of $50,000 on that transaction (because after you bought it, its now worth $450,000).  Another company, “TerrificTechToys” has a founder who knows his company is worth $600,000.  Since your offer is $400,000, he turns it down – so you make no profit or loss.

 

So, there are 100 such possible companies and you have to make the same offer to all of them.  What would you offer?  (Remember:  A single offering price that each founder will accept or reject).

 

Please send me your responses via email (dshah AT onstartups DOT-COM).  Don’t post them as a comment as that will give away the solution.  I’ll post the names of the winning answers in the next post.

 

Tomorrow, I’ll post the answer (and more importantly, what can be learned from the phenomenon and how it applies to software startups).

 

Stay tuned…

 

 

 

 

 

Continue Reading

The Risks Of The Mega-Market: Thinking Small To Succeed

March 12, 2006

One topic I’ve avoided talking about for some time is how software entrepreneurs should go about picking which market to target for their product/idea. 

 

The reason I’ve been avoiding this particular topic is:

 

a)     Its really a difficult question to answer

b)     I’ve had a hard time following my own advice

 

Having said that, I’ll go ahead and give you my advice anyways.  Remember, just because I’m unable to always follow the advice myself doesn’t make it any less valid.  Its kind of like doctors that tell you not to smoke – but are smokers themselves.  Fact is, smoking is still bad for you.

 

To frame our discussion, lets assume that there is a continuum (or spectrum if you will) of market that you could conceivably target.  At one end (the left end) of the continuum is a very ‘vertical” (or focused) market.  At this end, the number of potential customers is relatively small.  At the other end of the continuum, which we will call “the horizontal market” the number of potential customers is relatively very large.  

 

One of the most frequent mistake that software entrepreneurs make is to automatically think that a large potential market (i.e. the horizontal strategy) is better.  The (flawed) reasoning goes something like this:  “If I pick a broad market with millions of possible customers, my likelihood of finding X customers is much higher than if I had a very small potential market”.  The problem with this reasoning is not always obvious (if it were, fewer entrepreneurs would make this classic mistake).  

 

Here are  list of problems with the horizontal (i.e. millions of potential customers) strategy:

 

  1. It is difficult to figure out exactly what you need to build into your product because your potential customers are likely very different, and there are so many of them.

 

  1. Large markets are interesting to a larger number of competitors (because it’s a potentially lucrative market).  These opportunities are particularly interesting to the really big players (like Microsoft, Google and Yahoo!).

 

  1. In a horizontal market, its relatively difficult to actually differentiate your product from your competitors (i.e. the products that are able to successfully serve the larger market often are very similar).  If you try to make your product different in meaningful ways (that are hard to replicate), you end up reducing the size of your market.

 

Any one of the above points on its own would likely make horizontal markets a dangerous approach.  All of them combined results in a situation whereby picking the horizontal strategy will almost always result in failure for your startup.  However, the horizontal market is just so tempting-- (its glamorous, big and VC-fundable.  [Note to self:  write article on why VCs always seem to be pushing for horizontal strategies even though its in the company’s best interest not to pursue them].

 

Lets look at an example:  Lets say you were going to build an RSS reader of some type (yes, I realize this has already been done a hundred times, but it’s a good illustration and I can’t think of a better example at this particular moment in time).  You have two choices:  You could build a generic RSS reader that would be useful to just about any of the billion or so people on the Internet today.  Sure, you have some nifty ideas of how using mouse gestures and machine learning to make the product better than the existing RSS readers, but effectively, you’re building something that could be useful to millions of people.  For discussion purposes, lets say you had an actual target market of 1,000,000.

 

Or, you could build an RSS reader that is very specialized, because it integrates with a large-scale financial services application, takes that data feed (via RSS) and aggregates with another proprietary system in the healthcare industry and provides an end result in RSS that can then be used as a part of yet another enterprise application for data visualization and price/capacity optimization (note:  I’m making this up).  In fact, there are only 250 possible customers for this product on the entire planet (primarily because only 500 people even understand what the thing does, and only half of them can afford this specialized product).  

 

Now, lets put aside price for a little while.  We can assume you can charge much more (on a per customer basis) for the specialized product than you could for the non-specialized product.  But,  interestingly, I don’t even need to use price to make my case.  Lets say your goal is to get about fifty paying customers at whatever the price is.  This is not your ultimate goal, just your initial goal.  As it turns out, you are much more likely to get 50 customers out of the 250 in the “specialized/vertical” market than you are to get fifty out of the million people in the horizontal market.  

 

So, why is it easier to get 50 out of 250 customers instead of 50 out of a 1,000,000 customers?  Because the specialized market has the following benefits:

 

  1. In the specialized market, you can name all of your possible customers.  In fact, you could pick 5 of them and have a fair idea of what they would actually need.  As such, your product is much easier to define.
  2. You can reach just about all of your target customers.  Heck, if you absolutely had to, you could fly out and visit all of them in person.
  3. The likelihood of 10 other startups also going after precisely those same 250 customers with the same exact product as you is very low.  The likelihood that Microsoft, Google or another large competitor will go after those same 250 customers with a near-identical product is near zero.

 

So, even though you are trying to capture 20% market share in one case (where you have 250 potential customers) and only 0.005% in the broader market, you’re much more likely to succeed at the former.  Now, the really important part is that even though you target just those 250 customers today there is no law that says you are limited to these customers for eternity.  If you just so happen to actually get 50 of those customers, you can later explore other markets, broaden the product offering and see what other “pools” of potential customers might be out there.  In fact, the next pool might be even easier than the first pool because now you have credibility, resources, knowledge and customers.

 

Dharmesh’s Rule Of Thumb #1:  In almost all cases, software entrepreneurs should pursue the smallest possible market they can define.  The probability of early success is inversely proportional to the size of  the initial market.

 

Corollary:  If you don’t have early success, the size of your potential market is irrelevant anyways, because you’re out of the game.

 

Credits:  I thank Michael Cusumano for his excellent book “The Business of Software” .  Though I had been exposed to this concept before (what he calls the “lure of the horizontal market”, the book and the associated class, which I took with professor Cusumano in Fall of 2005 really hit it home for me.  Lets see if I can follow my own advice in the future.  I would also recommend “Crossing The Chasm” by Moore.  He takes a look at this phenomenon in some depth.  Both books are on my Suggested Readings list.

 

 

Continue Reading

Seeking Stellar Software Entrepreneurs

March 8, 2006

I’ve met my fair share (and then some) of software entrepreneurs – and would-be entrepreneurs.  In thinking back on those I’ve met that I would consider “successful” (i.e. have built successful companies), I’ve found there’s a pretty recurring set of “patterns” amongst the successful and not so successful.  

 

The items below are more about correlation than causality (i.e. manifesting one or more attributes doesn’t necessarily cause you to become a great software entrepreneur, but in my experience, those that manifest these attributes, in my experience, have a strong correlation to long-term success).  Inversely (and very coincidentally), I’ve found that many people that you would have thought would make great software entrepreneurs ended up not doing so.  In each of these cases, I’ve found that they were missing over half of the attributes below in some significant way.  One of the big impacts of the dot-com bust was that it gave many mediocre entrepreneurs an excuse for not having succeeded.  This is the classic “I’m great, my company was great and my idea was great – if only the market hadn’t collapsed”.  And yes, I’ll concede that many great entrepreneurs also got taken down with the market, but I’m going to argue that many of the software entrepreneurs that failed in the wake of the bust would likely have failed anyways (in a “normal” market).  

 

In any case, here are my signals of software entrepreneurs with a high probability of success.    Note:  I have a bias towards “technical founders” (i.e. software company founders with a technical background).  However, I’ve met some great entrepreneurs that weren’t technical – but were able to join up with someone who was – and who would have also met most of the criteria below.  

 

Top Signals of Success for Software Entrepreneurs:

 

  1. You like to experiment:  You like to play with new software.  You’re one of the first people to try new software (like Google Desktop Search, Yahoo! 360 and Microsoft Live)) within a week of its introduction.  You end up using < 1% of these applications over the long-term, but still love to “play with new stuff”.

 

  1. You like to read and learn:  You tend to read a lot.  A combination of blogs, books, magazines, etc.  You like to read on a variety of topics (marketing, technology, sales, strategy, etc.).  

 

  1. You like to tinker and build:  You tend to want to solve problems in a better way than is out there.  You customize, you build extensions, you write scripts, you improve.  You like to build things.  You can start with nothing more than a computer and a compiler and create something that generally works.

 

  1. You are opportunistic:  You’re always looking for leverage and an opportunity to create (and capture) value.  You measure ideas by their ability to create something meaningful.  Though you may not be obsessed with money, you’ve got a healthy recognition of the fact that money makes the world go round (and helps you have the resources to do what you love).

 

  1. You are an artist:  You love having an audience (users).  You’re fanatically obsessed with delighting your audience (users) with software that surprises them in positive ways.  You like to continually improve.  You take pride in your work by investing in great design that will withstand the test of time.  

 

  1. You Live On Email:  You tend to prefer email as your preferred communication vehicle.  Though you see the merit and value of in-person meetings (and in some cases phone calls), you would much rather have 90% of your communications over email as you believe it makes you more productive.  Your average response time on “emails that matter” is measured in hours, not days.

 

  1. You are considerate, respectful and niceYou tend to respect other people’s time, and show up on time for meetings.  When you meet with someone, you pay attention.  You don’t abuse the fact that you may have the upper hand in a given situation.  You are considerate and empathetic and generally have a high emotional quotient.  You tend to genuinely want to help people (even those from whom you are unlikely to receive anything in return).  You are kind to animals and children.

 

  1. You have a proclivity for action:  You are more likely to act than analyze, plan and obsess.  You tend to “jump in” and do it and deal with consequences after the fact instead of figuring out precisely the right path, right product, right market, etc.  You’d much rather ship a product that’s not perfect than try and spend another two weeks perfecting.

 

  1. You attract others like yourself:  You tend to have a great nose for talent and your passion is infectious enough to attract them to your cause.  You like to hang around other people that are as smart (or smarter) than you are.  The thought of feeling threatened never even crosses your mind.  

 

  1. You are a realist:  You tend to look at most things objectively.  You see them for what they are.  You have ambitions, but not unrealistic ones.  When in contentious situations, you’re usually the voice of reason.  You keep things in context and tend not to over-react.

 

  1. You are exceptionally intelligent:  Lets face it, software is a mind sport.  Software as a business even more so.  I’ve never met a successful software entrepreneur that I wouldn’t classify as being “well above average” in terms of intelligence. I’m talking about raw intellectual capability here (which may or may not have translated into great grades, exemplary test scores, or other “standard” measures – those these certainly don’t hurt).

 

  1. You are fundamentally likable.:  People want to help you.  Customers want to buy from you.  Employees want to join you.  Generally, people tend to return your phone calls and emails and they tend not to avoid you at parties.

 

  1. You exhibit “balanced frugality”:  You tend to have a reasonable and rational approach to expenses in your business.  But, its not frugality applied evenly across everything.  You’re not always looking for the lowest price or best deal in all cases.  In areas that matter (like the product!), you tend to spend what is necessary (and what you can).  You also tend to let other people make money too (something about the karmic startup cycle).  You avoid the temptation to “do everything yourself” using cost-savings as an excuse.  You place value on your own time (even though you may not be paying yourself out of the company yet).

 

  1.  You work hard:  You’re an over-achiever.  You’ve never been satisfied delivering the “minimum”.  Though you understand the importance of work-life balance (you read about it in a book somewhere), you’re not frequently able to pull it off.  When in a group setting where work is divided you somehow always do a disproportional amount of the work.

 

  1.  You just love the game:  You’re grateful to have the opportunity to do your own thing, create neat software products and serve customers.  You love the adventure and the thrill and are not hung-up on the rewards (though some of those would be nice too).

 

That’s it.  Once again, remember, these are just “patterns” I’ve observed in many of the really successful software entrepreneurs I’ve met.  Obviously, simply responding to email within minutes or reading the top 10 business bestsellers each year will not cause you to be a successful software entrepreneur.  But, if you manifest most of the above attributes, you are generally more likely to succeed than not.  You’re the kind of person I like to invest in (and I’m sure other investors feel similarly).  

 

Notice the stark absence of the idea, or the hockey-stick financial plan.  In my experience, simply having a great idea is not correlated with success.  That is, I’ve met many people with great ideas that haven’t built great businesses and many people with not-so-great ideas that have done really well.

 

So, I think the software industry is desperately seeking great entrepreneurs.  Are you one of these people?

 

 

 

Continue Reading

Further Thoughts on Finding A Co-Founder/Partner

March 7, 2006

In response to my last article, "Finding A Co-Founder, Partner and Co-Conspirator", Daniel Howard had some really good questions (I think Daniel could make a good career out of asking really great questions).

 

So, in order to dig deeper into the issue of if/when/how to bring in a co-founder, partner or co-conspirator, I thought I’d take a shot at answering some of his questions.  As always, remember that these are just one person’s opinion, but I think they have a non-zero probability of applying in your situation too.

 

  1. Is it better to find a like-minded friend or should there by more social distance between you two?

 

There are some advantages to finding someone that is a like-minded friend to join you in your startup.  There is an implicit level of trust that often pre-exists and that saves both parties some amount of time and energy in the short-run.  When forging a relationship with a stranger, some percentage of your time will be spent just learning about each other and establishing trust.  By picking a “like-minded friend” (i.e. someone with a lower social distance), you avoid this “cost” in the early days.  However, I’m going to argue that a greater degree of social distance is actually better in most cases.  Running a small software company is a very “personal” thing.  There will be many emotionally charged moments.  The closer the social distance, the greater the likelihood for a lack of objectivity when it comes down to making really hard decisions.  Case in point:  I started my first software company with my younger brother as co-founder. I was 25 at the time and he was 18.  Though we had a really good run (we jointly ran the company as co-founders for 11 years before we successfully exited in August, 2005) there were some really, really rough patches.  The issue was not lack of trust, but there are simply so many decisions and situations where it is impossible to have an objective “right answer” (things like equity, control, responsibility, rewards, etc.) and that more often than not, one or both parties feel they were treated unfairly.  When the social distance is very low, this kind of conflict is inevitable.  Even when people with high integrity and high emotional IQ are involved.  These are tough situations regardless, but having people that are close to you on the other side makes things much more difficult.

 

Summary:  Make the investment of time to build trust with folks that have at least some minimal social distance.  Ironically, you will end up reducing the social distance with anyone that you successfully work with for an extended period of time.  And, you’re likely going to want to work with them again.  That’s OK (not sure why yet, we can look at this one later).

 

  1. What are the tradeoffs of trying to clone yourself using a team of 3 or 4 people rather than finding one guy who’s like you?

 

The obvious trade-off is one of cost.  You often can’t afford to have 3 people doing the work.  Not in the early stages anyway.  So, I’ve found it helpful to actually look for “concentration”.  That is, don’t hire a finance person, a marketing person and a technology person.  Find someone that’s reasonably good at two or three of them (and better than you in at least one of them).  Specialists are for companies with large budgets.  If you can afford them, by all means go for it, but if your company size is <=3, its unlikely that you’ll be able to justify hiring someone “just for marketing” or “just for technical support”.  Another upside to this “personnel concentration” is that there is less vision/information/strategy that is “lost in translation”.  The odds of your communicating 80% of what’s in your head and what you’re trying to do to one person are modest at best.  Trying to do this with two or more people is much, much harder.  

 

  1. What if finding a clone takes a really long time, say years?  How do I find a clone?  What if I find somebody who seems to have a lot of good skills, but isn’t a clone?

 

Actually, finding a clone isn’t that hard.  What’s really hard is convincing them to join you instead of doing their own thing.  By definition, if you’ve truly found a clone, then they have the same entrepreneurial drive you do and likely have several ideas of their own that they want to pursue (or are already pursuing).  The best source of clones are:  existing software startup founders that are doing things similar to what you are (so, you can basically “join forces”), mentor/advisor types that enjoy the thrill of the startup process (but are looking for something new, taking into account that they probably don’t have the same energy you do) and fanatical users/customers (assuming you have these).  In fact, I’m going to back-off of the term “clone” as the ideal label here.  A better (and more defendable) way to position this would be to find a “high impact/value in short time-frame” person.  If you can’t find someone that can create immediate value, you may need to look for ways to find “funding” so that you can hire people during the ramp-up phase.  This is much riskier.

 

Also remember that “selling” a co-founder is actually much, much harder than selling a customer.  Your potential co-founder/partner is taking a much bigger risk than a customer is.  And even early customers are hard to convince.

 

And, to ensure I didn’t hedge the question completely, I will say this:  If you find someone with great skills, ask yourself what the likelihood is that they will generate enough “real value” (think dollars, sales, etc.) to overcome the cost of bringing them on board.  As a small company, even a world-class marketing person who is worth $200,000 a year – and that you can get for $100,000 because of how charismatic you are, isn’t going to help you (or them), if your market/idea/product/business can’t really sustain them.  Big, heavy-hitter players often need big markets and big companies to “spread their wings”.  Often, a capital-efficient software company can’t provide that in the early days.

 

  1. What if someone wants to be an employee – and not a partner?

 

If someone wants to be an employee, and you can afford to pay them, then this is often the best (and simplest) solution.  This is how I ran my first company.  In essence, instead of assuming (and forcing) some degree of risk on the early team, I bore the risk myself.  I hired programmers that wanted to program, project managers that wanted to manage projects, etc.  Not everyone wants to play the high risk game of stock/options ownership in software startups.  In fact, very few people even really understand the dynamics or appreciate the risks.  I think its na?ve and impractical to assume that everyone is driven by the same risk tolerance you are.  What I do now is this:  If the individual wants to be an employee, get paid close to “fair market value” and have very little equity – fine.  As long as they’re the right fit and are going to bring value.  If the individual wants to work for near-zero salary but have a bunch of equity – great.  As long as they’re the right fit, can bring value and the shared risk is not going to distort their decision-making.  A common counter-argument is that employees will not “treat the company as their own” unless they have skin in the game.  Though this has some truth to it, I would posit that the truly right people are incapable of consciously making bad decisions that are only in their self-interest – and not the interests of the company.  I’ve met (and hired) a bunch of these kinds of people.  Sure, they’ll make bad decisions sometimes, but the decisions are not distorted by self-interest.

 

  1. What if you (the founder) are impossible to get along with?  How can you know if you’re impossible?  Should you care if you’re impossible?  What can be done (for both you and the other person) to make it more likely to work out?

 

I’m going to argue that if you’re impossible to work with, you will end up having a high probability of failure for one simple reason:  You’ll end up paying a “premium” to get people to work with you or you’ll find only mediocre people that are desperate enough to work with you because they have no better options.  In this case, your best bet (as a founder) is to likely go work for a much larger company OR raise venture capital for your brilliant idea to so you can afford to pay the premium.  So, yes, you should definitely care if you’re impossible (though oddly, many people that are impossible to work with, don’t realize that they are).  As for what can be done?  If you’re on the receiving end (i.e. the one trying to live with a person impossible to work with), I’d suggest that you quickly find a way to move on.  Life is short. 

 

 

Finding a great partner is one of the hardest things to do, and something many people struggle with.

 

 

 

Continue Reading

Understanding Real Network Effects

March 3, 2006

I hear the term “network effects” a fair number of times when I talk to software company founders.  The thinking goes something like this:  “We’re going to give away our AJAX-driven, patent-pending, orphan sock matching software away for free so we can build a large base of customers and take advantage of network effects."

 

In my experience, In about 1 out of 4 times the term “network effect” is used, it is used incorrectly.  People often mistake having a large customer-base with an automatic network effect.

 

I’m by no means an expert on network effects and couldn’t give you a rock-solid, academically oriented definition, but I can provide a simple explanation:  A network effect exists when each user/customer/member that is added to the network increases the “value” of the network to other users.  So, if you have 10,000 customers, you don’t necessarily have a business model with a “network effect” unless customer X benefits from the fact that customer Y is also on the network.  Though a (weak) argument can be made that customer X indirectly benefits customer Y, because they’re paying money, thereby increasing your revenues, thereby giving you more resources to improve the product – this is really not what network effects are about.

 

Social sites like Linked In, delicious, and others have a network effect.  The more users there are, the more everybody benefits.  If I’m a user, there is some benefit (sometimes miniscule) to me if you also join the network.  The power of this model is that when users understand this, they are more likely to refer other users (because they would benefit from the growth in the network).  Other examples are the phone system (the more people that have phones, the more people that you can potentially talk to), instant messaging, Skype and others.

 

A good example of the absence of network effects is the Google search engine.  I’m going to argue that just because I’m using the Google search engine does not directly increase the value of the engine to you.  I could stop using Google tomorrow, and it would still work for you just as well.  In fact, in a theoretical sense, you could be the only user to use the Google search engine, and as long as the algorithm still worked and the index was still there, you’d get about the same value.  It helps you find stuff.  In fact, you have little incentive to convince me to use Google as well (other than good will) because it does not increase your Google experience at all.

 

So, next time someone tells you their business takes advantage of “network effects”, ask them how you would benefit from the system by getting other people to join.  If there’s not a good answer, or the benefit is indirect, chances are, there’s no network effect.

 

 

 

 

Continue Reading

Guy Kawasaki: The Art Of The Start

March 2, 2006

Though I am a very avid reader (of both business and technology books) I had not planned on posting book reviews on this site.  In this particular case, I feel compelled to make an exception and post my first book review.

 

I just finished “Art Of The Start” by Guy Kawasaki.  I am not generally prone to gushing praise (for anything), but in this case, I need to make an exception.  

 

If you are a startup founder and have time to read just one book this year, read “Art Of The Start”.  If you have time to read just two books – read it twice.

 

How’s that for an endorsement?

 

If you have not yet read this book, run – don’t walk (unless you’re holding scissors) and go grab a copy somewhere.  It is by far one of the most useful and practical books on how to improve your chances of succeeding at a startup I have ever read.  In fact, I will make you this offer.  Buy the book, read it.  If you don’t think you got your money’s worth out of the thoughts and ideas in the book, email me and I’ll pay you the price of the book (via PayPal or some such means).  This is as good of a guarantee as they come.  Yes, I liked the book  that much.  Not because it is particularly erudite or deeply researched, but because it is useful.  Guy somehow manages not to dodge the issues and state his opinions (most of which I happen to agree with).

 

I’ll admit it’s a little humbling to read something like this as it greatly diminishes the value I can bring to startup founders through a blog like this.  Guy covers so much territory and does it so well, its really hard to compete.  The good news is I don’t have to.  I’ll continue to share my insights and ideas focused specifically on software startups and if I end up repeating things that Guy has already said, I can comfort myself with the notion that by seeing the same concepts and insights twice, you’re likely to believe them a little bit more.

 

In future articles, I’ll take some of the key insights from the book that most resonated with me and expand on them here.  Stay tuned…

 

Closing Note:  I’ve never met Guy and as far as I know, we have no “connections” (no common investments, don’t sit on any common boards, etc.).  So, I have absolutely nothing to gain by the above endorsement other than the warm glow one gets from sharing a good thing.

 

Continue Reading

Finding a Founder, Partner and Co-Conspirator

March 2, 2006

If you are the founder of a software startup, when is it time to bring on your first co-founder/partner/employee/co-conspirator?

 

There comes a day when an opportunity presents itself to help spread some of the work and bring in a co-founder/partner/employee/co-conspirator.  The first time you go through this, things can be both very exciting and very frustrating.  On the one hand, there is the excitement and gratification of sharing.  There is a very basic human need to share our success (which has the effect of amplifying one’s joys of achievement).  We like to show others how smart and capable we are, and this is near-impossible without having someone intimately aware of what makes us tick and seeing things from the inside.  Though friends, family and significant others can play a supportive role, this is often short of completely gratifying because they don’t truly appreciate exactly how brilliant you truly are.  J  On the other hand, there is also frustration because the co-founder/partner doesn’t quite “get it” completely.  He or she doesn’t write code as well as you do, doesn’t understand the problem as well as you do, etc.  And, as fate would have it, in retrospect, there are often mixed results when bringing in that early co-founder/partner/employee.

 

Note that my comments below are focused primarily on bootstrapped software startups, and likely more applicable to first-time entrepreneurs.  If you have done this before, or are raising some meaningful outside capital, things change.

 

So, here are some considerations when trying to make this difficult decision:

 

  • Immediate Value:  The best partners that you will bring on are contributing value from day one.  Despite learning curves, lack of knowledge of the company, lack of knowledge of existing products, etc.  the best partners will likely be able to bring you some value from the moment they start.  If, within the first week, they are not creating measurable value (improving the product, deepening relationships with customers, increasing the hours that you get to sleep soundly etc.) then there is something that is likely wrong.

 

  • Find Exceptional Generalists (like you):  We tend to like people like ourselves – for a reason.  Though there is great power in supplementary skills (i.e. bringing on someone that is good at marketing, if you aren’t), it is often difficult to allow these kinds of people to help you if you don’t have some baseline of trust.  For many software startup founders, this trust is created when you can see some core set of technical skills and an ability to improve the product.  You’re looking for gifted generalists that can help you with any number of things.  These kinds of people often have an innate intellectual curiosity too (so part of the value they get from joining you is to learn new things).  Please refrain from posing the argument that not all people can be good at both creating the software and marketing/selling/finance/operations etc.  You’re right, not all people can be good at these things.  But, in early, bootstrapped software companies, generalists that are “well above average” in many things likely fair better than specialists.  In essence, startup founders are looking, to some degree, for clones of themselves.  In reality, if they could find a way to increase the hours in their day, they’d do it all themselves.  But, they can’t, so they decide to bring in outside help.

 

Summary:  What you’re really trying to do is team up with the next Joel Spolsky or Eric Sink.

 

  • Try before you buy:  This is in the interests of both parties.  Before you hand someone (regardless of how wonderful they may seem), a big chunk of equity in the company expecting them to do miracles, its best to let them jump in and do their thing.  Often, whether someone works out or not is an issue of chemistry, skill, stage of life and myriad other factors.  The only way to know whether someone will actually be able to help you and share your passion is to let them demonstrate it.  Thankfully, this is a two-way-street.  Its also in that person’s interest to see if they like working with you, can contribute value and generally like where you are headed before they get too deeply involved.  If someone pushes you too hard, too early to be a “partner” in the company and receive equity, take pause.  The right person wants to have skin in the game, but only after they have figured out it’s a game they want to be involved with in the first place. 

 

The good news here is that you can often use role-reversal and empathy as an effective tool.  Put yourself in their shoes.  If it were you, what kind of concerns would you have?  What would you want to know?  What type of “respectful escape plan” would you be looking for before jumping in?  If the person you’re looking for isn’t manifesting a similar set of questions/concerns/passions, etc. that you would have if you were in their place, its likely its not a good fit.

 

There comes a time in when you can use the help and you’ll be missing out on opportunity by stubbornly holding onto the reigns too tightly for too long.  Learn to find, attract and retain great people.  It can be a lot of fun and very gratifying.  And, its really, really hard to build an exceptionally successful software company by yourself.  Given my reclusive and idiosyncratic nature, if there were a way to build software companies by locking myself up in a room and not having to deal with people, I’d be doing it.  But, there isn’t, so I don’t.   J

 

 

 

Continue Reading

Early Customers: The Coerced, The Convinced and the Committed

February 27, 2006

Talk to any experienced entrepreneur or investor and they’ll tell you that there is no better evidence of the viability of your business than a paying customer – or better yet, multiple paying customers.

 

Given this fact, many savvy startup founders focus aggressively on getting early revenues, however they can -- which is a really, really good thing.  But, its often helpful to understand that not all customers are created equal.

 

Here is how I like to categorize early customers:

 

  1. The Coerced:  These are usually friends or family.  In many cases they are so close to you that a simple request (assuming there’s some relevance and the product doesn’t cost an arm and a leg) is all it takes for them to pay you some money.  Basically, it’s a combination of arm-twisting and guilt that brings these customers on board.  Not that this is necessarily a bad thing, but recognize that revenues from these kinds of customers don’t have as much “value” as the other two categories.  Basically, the validation provided for your business is just not as strong.  Chances are, they didn’t buy the product, they bought you.  The cash doesn’t hurt, but in my experience, its usually pretty modest.

 

  1. The Convinced:  These are people that are either complete strangers or people you know but don’t know well enough to arm-twist into buying from you.  They have to be convinced.  You probably gave them some discount, made some changes to the product to get them on board, or just your passionate conviction was sufficient to get them on board.  This is real revenue.  Congratulations.

 

  1. The Committed:  These are people that are not only sold (and paying you money), but are committed to your product and are ready to back you up.  They either want or need to see you succeed.  They’ll give you testimonials.  They’ll give you ideas for features.  They’ll be a reference.  You’ve created something of such value to them that they’re rather pay you, and increase your odds of success, then not pay you.  They answer your calls and respond to your email.  They’re great.  Happy, Happy – Joy, Joy.

 

To put a finer point on this.  Lets say we measure two aspects of a new customer:

 

  1. The “distance” of that customer from you (i.e. how well did you know them and how much influence did you have over them)?  

 

Use a scale of 1-10:

       1=You’re joined by blood, undying friendship or are (or were) sleeping in the same bed.

      10=They’re never met you or heard of you before.  You have no power or influence.

  1. The “repeatability” of the sale.  This measures how this customer reduces the work/effort required for future customers. 

 

Once again, use a scale of 1-10:

      1=You had to customize the product significantly and fly out 2000 miles to manually install/configure it and train them.  Future customers don’t benefit from the features added.   

      10=They found you on the Internet, paid by credit card and are ecstatic with the base set of features you already have and are impressed with your brilliance.

 

So, quite simply, take the above two numbers and multiply them together and you get a “customer value index” from 1-100.  Obviously, the closer to 100 you can get, the better.  For my own purposes, I usually calculate the average across all my early customers.  I multiple my total revenues by this average (as a percentage) to figure out what my “real” revenue is.

 

For example:  If my average customer value index is 40 and my revenues are $500,000, I would estimate my “real” revenues at about $200,000.  Not very scientific, but then very few things in startup-land are.

 

What’s the point in all this?  Simple – it helps me recognize that not all customers are the same and that getting one committed customer with a high index is much better validation that “things are working and I’m on to something” than many low-index customers who I arm-twisted in a weak moment into paying me money.

 

Finally, though I would agree that “cash is cash”, in my experience, the higher index customers end up being more profitable too.  Selling to friends and family (at least for me) rarely ends up being a profitable venture.

 

 

 

 

Continue Reading

MIT Thesis Research On Small Software Companies

February 26, 2006

I am currently working towards completing a master’s degree (M.S. in the Management of Technology) from MIT.  With any luck, I will graduate in June 2006.

 

As part of this process, I’m writing a graduate thesis that is focused on today’s small software companies (with less than 100 employees).

 

If you are the founder/CEO/manager of a small software company, please complete the following survey.  The survey should take only about 10 minutes to complete.  At the end of the survey, you can request to receive a summary of the survey results and/or the final thesis document when it is published.  Individual responses will not be shared and will be kept confidential.

 

Click Here For Survey
 

Thank you in advance for taking the time to complete the survey. 

 

Regards,

Dharmesh Shah

 

P.S.  If you know of others that are running small software companies, please pass the link along.  

 

Continue Reading

The Myth of Building A Software Business on Google AdSense Revenue

February 22, 2006

As the saying goes, “Somebody will win millions of dollars in the lottery this month.  Just not you.

 

Similarly, there are many websites and individuals that will make lots of money in Google AdSense ads – just not you.

 

In looking at many of the “Web 2.0” companies that are out there, most of them don’t have a discernible business model (by “business model”, I’m talking about some definable way to charge money and create semi-predictable cash flows).  When pushed, and asked how they’re going to make money, many Web 2.0 company founders will simply revert to the knee-jerk, “we’re really focused on building a user base right now.  We’re not focused on revenues”.  Or worse, the response is sometimes “we’ll make money on advertising”.  Unless the company happens to be really focused on some segment of the market, which specific types of advertisers will be interested in and pay a premium for, this model just doesn’t work.  Systems like Google AdSense which “aggregate” a large volume of advertisers and connect them to a large volume of websites, though highly efficient, won’t work for your software company.

 

Here’s why:

 

  1. Systems like Google AdSense are generally determining which ads to send to your site by using their highly sophisticated algorithms to find just the right ads based on the content of your site.  Problem is, if you’re a software company, most of your content is probably not “public” (i.e. requires users to signon) and as such can’t really be processed by Google.  So, you end up with a bunch of non-relevant ads (which irritate your users and/or don’t generate clicks/revenues anyways).

 

  1. You have no way of knowing/predicting what kind of revenue you’re going to generate.  Google gives you lots of reports and details on click through rates, eCPM (estimated cost for a thousand clicks), and other useful information.  What they won’t tell you is how much the advertisers paid for the ads, and what portion is coming to you.  If Google decides someday to take a larger portion of the pie, you won’t probably know (and won’t be able to contest it anyways).

 

  1. Given that Google is using an auctioning process (which is a good thing), there is essentially a “market” for Google Adwords (what the advertisers use to promote their product/service).  The upside to this is that advertisers have to “compete”.  The downside to this is that like any market, prices can vary.  Advertisers may decide (independently or in collusion) not to “drive prices up” by competing with each other.  Or, the market may just change.  This has a dramatic impact on your revenues.  And you won’t know until it happens.

 

  1. Click fraud (or more importantly, suspected click fraud) is a major, major issue.  If Google suspects that people (or automated bots) are clicking on your ads to inflate your revenues, they can turn you off.  Period.  No warning, no arbitrage, no recourse.  Period.  There’s been a lot of talk about this (I’ve had it happen to me on one of my personal sites).  Google is judge, jury and lead prosecutor.  They don’t have to explain anything to you (and they won’t) and what little chance at “evidence” there was is gone because they will turn off your account immediately so you can’t even see your reports.  You were warned.  [Note To Self:  This entire phenomenon deserves an article into itself].

 

  1. The magnitude of revenues made by even highly successful (highly trafficked) sites seems to be pretty low.  If you’re an independent blogger, writing content for left-handed plumbers that enjoy Broadway musicals, and making $10,000/month on Google Ads – that’s a success.  And trust me, you’re in the 99th percentile.  That’s just not that much money when you have those irritating things called expenses.  If you’re a software company trying to make a living (and pay employees, rent and other things) and generating even $20,000/month in AdSense revenue, you’re still struggling.  The fact that your monthly revenue can drop from $20,000/month to $2,000/month overnight will cause you much loss of sleep.  Somehow, explaining to your team that the price for AdWords like “CRM, industrial, engineers” has dropped by 50% is not going to provide them much consolation when they can’t get a paycheck.

 

Obviously, I’m being a little extreme here (but not that much).  I simply don’t think that 90% of the companies out there that think they are going to build a business on AdSense revenue really know what they’re talking about.  If you really want to learn how all this works (and what kind of money you can expect), I’d suggest you try it.  Setup a website, subscribe to Google AdSense, make a little money and just see what happens.  Heck, you can even extrapolate and say “well, I’ve got 100 users today and am making $100/month…if I had 10,000 users, I could make $10,000 a month!”.  But, just do the math – and be realistic. 

 

Note:  All of this is really looking at advertising revenue through systems like Google AdSense.  If you’re planning on advertising directly with partners and others that place a premium on the reach you have with customers, it’s a different ball game.  You lose the efficiency of Google, but will generally have other benefits (like a fair degree of predictability and control).

 

If you think I’m wrong, and your experience leads you to believe you can build a software business on Google AdSense (or its competitors), let me know.  Would love to hear your success stories – or even your hopes for a success story.  

 

 

 

 

Continue Reading

The Risks Of Outsourcing for Software Startups

February 21, 2006

A lot has been written about outsourcing and the flattening world and labor arbitrage and a global pool of talent, etc. etc. etc.  I’m not going to repeat that here.  This article focuses on the implications of outsourcing from the perspective of a software startup founder/CEO.  Though most of my background is with U.S. startups (that’s where I live), the points in this article should apply equally elsewhere.

 

Lets go ahead and stipulate that there is a normal distribution of software talent across countries (i.e. India, China, Russia and others are just as likely to have smart, competent software developers as the U.S.).  Lets also stipulate that there is the opportunity for cost reduction by outsourcing to countries that have a large pool of talent available at lower prices.  This is reasonably well documented and understood –and my personal experience bears this out.

 

Despite the above, I am going to argue that most startups should not try and outsource their core product development.  The rationale is very simple:  software businesses are usually not a “cost play”.  Basically, you are not predicating your success on the fact that you can build a product that solves a particular problem cheaper than anyone else.  If you are, we really need to talk, as this is a risky strategy.  Generally, most software company founders start product companies for one simple reason:  fantastic profits because of low variable costs (and of course, the thrill of having many, many users).  Basically, this means that once you’ve written the software, reproducing it has near-zero cost and assuming you can acquire customers cheaply, your margins are great.  This is not hard to understand.  This is why so many software people avoid service/consulting companies (there’s less risk, but also less reward).

 

In order to understand why outsourcing can be a bad idea, lets take a look at similar industries that have high profits (but also high risk):  entertainment (the movie industry) and books (the publishing industry).  In both of these cases, the model is to try and create the “killer” box-office hit.  In the publishing industry, its about creating the runaway bestseller.  Both of these industries rely on having a really, really successful “product” that many people will want and pay for.  In both of these industries, the number of these “blowout successes” is also very small (much like the software industry).  The challenge here is that success driven more by art than science.  Nobody really understands what makes a bestselling book or a blockbuster movie (though some ingredients certainly increase the chances of success).  Its not formulaic.  Its not predictable.  In your case, you are probably trying to build “the killer app”.

 

Software has similar attributes.  Nobody really knows what the right mix of “ingredients” is that creates a product that thousands or millions of people will buy.  But, that’s what many of us hope to build.  Lets assume that you have a 1% chance of creating a reasonably successful product (in terms of revenues/sales).  Lets say it would cost you 10,000 hours to build said product (at a cost of $100/hour, that would be $1 million).  Lets say by outsourcing, you could reduce this cost by a fair amount (maybe bring it down to $250,000, if you were really good).  However, I will argue that doing so would dramatically decrease the probability of you building the successful product.  Its no longer 1%.  Its considerably lower.

 

Why?  Simple.  Its hard enough to build a successful product when its coming from the “mind of the few” that spend long days/weeks together, sit across the hall, discuss customer feedback, debate usability vs. performance, timeline vs. quality and other “tradeoff” issues that are typical of any startup.  Even when the distance between members of the team is measured in feet, its still hard to really communicate without something being lost in translation.  In an ideal world, the founder (you) would have an infinite amount of time to create the killer app.  If you could do this, your probability would go up (the product would be elegant, well designed, maintainable and something to be proud of).  Many of the most successful products I know were effectively built by one or two brilliant minds (with supporting staff of course).  But, you don’t have infinite time and non-trivial problems will likely take additional resources.  So, you can outsource (and save some money) or you can try and find the best talent possible to minimize the risk premium you’re going to pay (in terms of impacting your probability of success).  I advocate the latter.  So, its fine if you want to outsource.  Its fine that your development team members are not a few feet away (I’m using physical distance as a proxy for measuring “closeness”).  But, you need to do it for the right reason.  If the best possible person that you can find to work on your project is 3,000 miles away – fine.  If they happen to be cheaper because they have a lower cost of living where they are.  Fine.  But, that shouldn’t be the motivation.

 

In summary:  Trying to save money as the primary motivator for outsourcing in a software startup is being a penny wise and a pound foolish.  There are other places to save money (which I encourage you to do).  Just don’t skimp on the one single factor that will likely have the highest impact on your probability of success.  You’ll be sorry you did (and won’t even know it).  There are a thousand reasons why your startup might fail – try to avoid this one.  If it were as easy as identifying a possible market, writing a 200 page specification document and finding the lowest bidder with the highest IQ, that’s what software startup founders would be doing everywhere.  I assure you, they’re not.  Not the savvy ones, anyways.

 

It doesn’t make it any easier that investors are often pushing for some type of “outsourcing strategy” as part of your business plan.  My strategy is simple:  Find the best talent you can find for your product and try to find investors that are sophisticated enough to understand and respect your approach. 

 

But, that’s just my opinion.  I could be wrong…J

 

 

Continue Reading

To Launch or Not To Launch - The Benefits Of the Infinite Beta

February 19, 2006

As many of you may have noticed, Google Mail (aka “GMail”) is still labeled/branded as being “in beta”.

 

This is an interesting thing because I originally got my beta account setup on GMail sometime in the summer of 2004.  This means we’re closing in on two years of the “beta period”.  So, we can ask ourselves why Google insists on leaving the product in beta – and if there are good reasons for this, whether other web software companies should do the same.

 

At some level, I think Google has distorted the meaning of the word “beta”.  Generally a beta period is intended to have a limited set of early users test the product and provide feedback.  The developer then uses this feedback to refine the product prior to public release (or general “launch”).  The intent is to get many of the issues resolved before the software is unleashed on the masses thereby hopefully reducing the volume of “post production” bugs that are reported.  This makes sense for just about everyone involved (especially the software developer).

 

Implicit in most beta programs is the following:

 

  1. Beta users should expect to find some issues and report them  (i.e. the product is likely not quite ready for “prime time” yet).
  2. There should be a reporting mechanism so that these users can report the issues.
  3. Some portion of the reported issues will be resolved by the software developer (usually, what is important enough to fix is up to the developer)
  4. Eventually a “public release” is made once the software is deemed “good enough” by the developer.  

 

In Google’s case, it seems obvious that they are not really managing a beta program in the traditional sense.

 

My suspicion is that Google is keeping this (and other products) in beta for one very simple reason:  because they can.  Though the term beta likely has no real legal implications (other than what is defined in the terms of service), there is a perception about beta products that allows for a minimalist set of terms to be offered.  For example, if Google had a “production” (non-beta) web service available, it would be unreasonable of them to state their terms of service to be something like:  “use at your own risk, we reserve the right to turn this off, change our mind, kill the project or whatever for any reason whatsoever which we may or may not decide to ever communicate to you…”  However, for a beta product, just about anything goes.  So, the question is, what possible incentive does Google have to ever take GMail out of beta.  If users have come to accept the beta label (and will gladly use the product anyways), it seems there’s very little incentive.  Given that GMail is free (though I prefer the term “subsidized”), they really don’t have any obligation to ever come out of beta.  

 

So, having said that, if you are offering software as a web service and not charging direct fees (like a subscription), could you get away with the same thing?  Should you even try?  The answer is:  maybe.  Most users these days expect developers to have a beta period for their software.  Nothing surprising here.  The only risk is that some percentage of customers will likely wait before a product is “launched” as they don’t want to be “beta testers”.  If this set of users is very small (or small enough), there’s no reason not to put a beta product out there – and leave it there, for the same reasons Google seems to be doing it.  Though one could argue that not every software company can get away with what Google does, one can make the counter-argument that Google has “conditioned” the market that using beta software is “ok”.  

 

My general advice would then be:  If putting a beta label on your software makes it easier for you to get out to market (and start getting some feedback from real customers), then by all means do it.  Too many companies hold on to their software too long in the hopes of making it “perfect”.  Once you’re out there in beta, you can ask yourself when (and if) you ever actually come out of beta.  If your customers (and I use the term loosely) don’t’ have an issue with you being in beta, then there seems to be little incentive to actually “launch” (and likely lots of good reasons why you shouldn’t).  If it’s a good strategy for Google, it might just be a good strategy for you.

 

 

Continue Reading

The Danger Of Solving The Venture Capitalist's Problem

February 17, 2006

As a software startup founder, you have a fundamental decision to make in the early days:

 

  1. Do you focus on solving a customer/user problem?  (i.e. spend most of your time trying to build something that does something for someone who cares)

 

OR

 

  1. Do you focus on solving the venture capitalists problem?  (i.e. spend most of your time figuring out how to convince investors that you’ll help them make a return on their money)?.

 

Too many entrepreneurs fall into the trap of automatically picking #2.  Shortly after having their idea, they start crafting a business plan, devising financial projections, doing market research, etc.  Most of this is not because they want to better understand the opportunity, but because they want to better articulate a story to a VC so that they can get funded.  I will posit that most software entrepreneurs are much, much better off initially going with #1.  One of the truly wonderful things about software startups (vs. other types of startups) is that the capital requirements are really, really low.  As such, there’s no requirement that you go off and raise any outside capital.

 

Here’s a typical scenario for founders that pick path #1:

 

You come up with an idea (which is just a fancy way of saying that you’ve discovered some idiotic thing that people are doing, or not doing, simply because there’s no software to do it – or there is software to do it, but it sucks).  These ideas are often generated while you’re an employee somewhere and witnessing the idioticness first hand.  Or, you’re personally doing the idiotic thing, and try as you might, you can’t find a solution to your pain, so you decide to solve it yourself.  Regardless, you go off and start writing code.  For those of you that passed out on the floor because I didn’t mention design, UML or any kind of planning before writing code, relax – you can design first if that’s your thing.  At this point in the process, you’re really telling yourself “its just a prototype” and “I’ll rewrite it later”.  Interesting, you actually believe this.  Along the way, you start to tell a few people about it (because you just can’t contain your excitement).  A few potential customers grudgingly express interest, perhaps a few even offer to try it out “when it’s ready”.  Weeks or months later, you finally have something to show.  You go to your “early adopter customer” (who by this point has likely forgotten that you were off building something that they had volunteered to try out just to make you go away at the time).  You demo your product.  The customer throws up all over your shiny new software and tells you why it sucks so badly that they’re scared to be within a 50 foot radius of any computer that has it installed.  So, you go back and write some more code, tweak this, clean up that.  You repeat this process ad-nauseum.  If you’re persistent enough, you’ll find that eventually, you get it sort of right.  Right enough that people start agreeing to pay small amounts of money for it.  You then listen to these people, do what they tell you, and make the product better.  More people pay, and you’re able to push up the price a bit, and life is good.  Not great.  But good.  Congratulations, you have a software company!

 

Here’s a typical scenario for founders that pick path #2:

 

You come up with an idea.  You’re pretty sure the idea is reasonably good, and you bounce it off of a few people, some of whom say its great (but most don’t even understand the idea).  You start writing your business plan.  You do some market research and discover that low and behold, if you look at the market just right , with the light beaming on it at just the right angle, it’s a $1 billion market!  Woo hoo!  This makes writing the financial projections so much easier because all you have to do is capture 10% of this market and you’ve got a $100 million company.  You refine the business plan some more.  You start contacting friends (and friends of friends) to get introductions to VCs.  You get your first meeting lined up.  You stay up all night putting the finishing touches on your PowerPoint deck.  You have the VC meeting.  During the meeting, one VC seems overtly distracted and the other keeps interrupting with questions that you don’t have good answers to.  On the rare occasions that you do have good answers, they don’t seem appropriately impressed.  At the end of the meeting, they tell you your idea is “interesting”, but that you need to come back after doing X, Y and Z.  “Flesh it out a bit more”.  You go back, write some more, have some more meetings.  You start detecting a similar pattern.  Not a single VC tells you your idea sucks or that there’s no chance in hell they’re going to fund you.  There’s no “upside” for them to tell you this (just in case you happen to be the next Google and they figure this out later).  They’re better off maintaining just enough interest so that you stay in touch, but not so much interest that you’ll linger after the meeting and waste any more of their time.  6 months go by.  You’ve had a dozen meetings, the business plan is on Version 6.7.3 but it doesn’t seem that you’re any closer to an actual check than when you started.  You’re in good company as its likely 90% of the other startup founders that picked “door #2” are in the same boat you are.  You do not pass go, and you do not collect $200 and sadly, you decidedly do not have a software company.

 

Obviously, these are both contrived scenarios, but those that have been through either one will find remarkable similarities to real life.  My point here is this:  Unless you’re a rock star software entrepreneur (which means you’ve done it before and made money for your VCs), your odds of actually getting funding from a VC are really, really low.  And, save the argument of “but, I’m well above average when it comes to other startup founders”.  In venture capital land, we have the Lake Wobegon effect (i.e. every startup founder is well above average).  Even assuming you actually do raise capital, the sad truth is that all this gives you is the opportunity to go solve a real problem.  Important note:  Just because you’ve raised capital does not mean you’ve created any value.  You’ve just earned the opportunity to create value.  But, you had this opportunity already.  In most cases, you could have worked on the original problem anyway (though likely with much less fanfare and no Aeron chairs). 

 

So, this is my long-winded way of saying this:  If you have a software development background (which most software company founders do), then play to your strengths and go write code.  Solve problems.  Iterate.  Don’t play someone else’s game (which you likely suck at anyways) and depress/frustrate yourself in the process.  At least if you write code, and still don’t succeed, you’ll have done something you enjoy and have something to show for it.  Writing business plans and trying to solve the venture capitalists’ problem is just not fun.

 

But, that’s just my opinion.  I could be wrong.  J

 

 

Continue Reading

Thoughts on Paul Graham and YCombinator

February 15, 2006

Let me introduce this article by making clear some important facts:

 

  1. I have read most of what Paul Graham has said and agree with 95% of his thoughts and insights (which is rare).
  2. I think YCombinator is doing some very creative things with respect to funding very early stage companies
  3. From outwardly visible data (I’ve never met him), I don’t think Paul Graham has malicious intent or is intrinsically evil.  In fact, he seems to be a really nice guy.

 

Disclaimer:  Since I am in some sense a private/angel investor myself, there is the risk that some of my thoughts can be taken as “competitive criticism”.  (i.e. I’m competing with YCombinator).  Though this has an element of truth (i.e. I have a biased opinion), it doesn’t necessarily make me wrong.  Will let you judge for yourself.

 

Having said that, I think its important to try and analyze the YCombinator “path” for startup founders and how this compares to other possible alternatives (one of which is to do nothing at all).  If you don’t know anything about YCombinator, I encourage you to read up on them (a Google search is sufficient, and will give you the most current stuff) so I’m not going to post direct links here.  If you already know about YCombinator, Paul Graham and the Summer Founders Program, read-on.

 

Here are things I like about Paul Graham and YCombinator and what they are doing:

 

  1. They seem focused on very early stage companies (which is a good thing).  The options for these companies are generally very limited (when it comes to capital raising).  Its good to see someone focused on this end of the market.  It helps drive innovation.

 

  1. Paul has an “operating” background (i.e. he’s founded a company before).  From what I have read, his company ViaWeb sold for about $50 million “back in the day”.  Though I don’t see this as a huge hit, its big enough to let him do what he does – more power to him.  Having had only modest hits myself, I can relate.

 

  1. He is technically astute (so its easy to like him and respect him).  He’s not a “suit” (which I mean in the most respectful sense possible).  Though some of his views can be a little elitist and impractical (in my humble opinion), this is not a big deal, as this does not seem to cloud his thinking in terms of investments that he makes nor does he seem to bend his portfolio companies to his will in regards to technical platforms and languages.

 

  1. They seem to be pretty quick about their decision making (one of the things I dislike most about the traditional VC process is that it takes so long and consumes so much energy).  The application process at YCombinator seems straight-forward with a relatively quick decision cycle.  As a founder, this means you can focus most of your time/energy on actually solving a customer problem – instead of solving an investor problem (which is rarely ever the same thing).  [Note To Self:  Could be a good topic for a future article, “The Dangers Of Trying To Solve The Investor’s Problem”].

 

  1. There is a strong “communal spirit” amongst the portfolio companies.  This is great.  One of the hardest things about startup companies is that it can be very lonely.  I think its great to be associated with other people that are doing similar things (and are at a different stage).

 

Having said that, there are some things that I think require deeper inspection and are worthy of analysis:

 

  1. YCombinator invests about $6,000 per founder.  I’m not saying this is too low (or too high), but it seems arbitrary.  I have a hard time believing that all possible ideas can be validated (or invalidated) with the same amount of cash.  I would like to see a little more thoughtfulness put into how much capital is infused.  Though simple is often good, there is sometimes the danger of too simple.

 

  1. The “pre money” valuation (i.e. what the startup is worth before the cash comes in) seems to range from $100k-$200k.  Based on the kinds of companies that are applying, this is probably appropriate.  However, its important to note that the average pre-money valuation through most other channels (including angel investors) seems to be higher.  Obviously, the upside for the founder is that the higher the valuation, the less equity (percent of the company) has to be given up – all other things being equal.  Since there is rarely any competition for these deals (you either take money from YCombinator – or you don’t), its hard to assess whether the valuation is fair or not.  See #4 below.

 

  1. Part of the value you are getting is the Paul Graham “label” applied to your startup.  For the right kinds of companies, this has immense value.  Paul Graham has a loyal and passionate following (myself included).  However, if your business idea is not a mainstream “web 2.0” kind of startup then the value that the Paul Graham label can bring to you is severely reduced.  If you’re building software for the plumbing industry (lets say), then its doubtful that pool of potential customers gives a flip about Paul Graham or YCombinator or the fact that you got “chosen” from hundreds of possible applicants.  One of the dangers of startup land is that it’s a very small circle of people (selling to each other), and we often become disconnected from the “real” world.  In many cases (reddit.com for example), that’s OK.  The model is not necessarily for the mainstream right now anyways.

 

  1. I’m a little emotionally disturbed by my use of the word “label” in #3 above (and its connotations back to the music industry).  Basically, at a micro-level, YCombinator has almost zero competition.  You as the aspiring founder/entrepreneur are hoping to get “picked”.  If you do get picked, that’s a great badge of honor and often puts some wind in your sails simply for being “under the label”.  Though there is definitely value here, there’s a dark side as well.  Anytime an entity has little (or no competition), this implies a lot of “power” (or leverage) in the transaction.  When there is an imbalance of power, there is the potential for the weaker party to get screwed.  Its also important to note that malicious intent is not a requirement to being screwed (so even if YCombinator was completely above board and acting with good intent – which I think they are), doesn’t mean that it’s a fair deal for the founder.  This is one of the problems with these kinds of deals:  its not an efficient market.  With only one “buyer” at the table, you don’t know whether you’re getting a fair price or not.

 

So, all in all, I think YCombinator is a good thing, as long as founders walk in with their eyes open and understand the dynamics of what is going on.  I’m hoping that more “very early stage” investors will fill the capital gap for the next generation of software startups.  Meanwhile, I wish continued success to Paul Graham and YCombinator.  I wish such a mechanism had existed when I started my first two companies.  I could have used the help.

 

 

 

 

 

Continue Reading

Revenue Early, Reveue Often

February 13, 2006

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.

 

 

Continue Reading

Raising Capital: Friends, Family and Fools

By admin_www.pshah.com admin_www.pshah.com on February 10, 2006

There comes a time for many software entrepreneurs (and would be entrepreneurs) where they simply need cash to make any further progress. At this time, they start thinking about capital raising. Unfortunately, for too many startup people, capital raising = Venture Capital. This article focuses on the “real world” of early-stage capital raising for software startups. I’m generally not a big fan of venture capital for software startups (but this is a topic for another day). Its not that I don’t think VCs are smart (they are) or that they’re intrinsically evil (they’re not), but that venture capital is often not the right choice for a large majority of software startups, and too many entrepreneurs get overly frustrated with the process of pitching to VCs, ultimately give up, and have little (if anything) to show for it.

In the early stages of a company, many entrepreneurs use “friends and family” money. This is fine (within reason), but its important to remember that in most cases these people are not sophisticated investors, will likely not understand your business and don’t really provide you one critical service that you absolutely need: validation. Its imperative to verify that you’re not drinking your own cool-aid (too much) and verify that your business idea has some modicum of merit and is worth pursuing. Once again, I’m not suggesting “professional” investors (VCs), because often their bar is too high in terms of validation. Not all companies are VC fundable (and many great ideas are not VC-optimized).

Your family will generally give you money because they have likely known you for most of your life, and you have somehow managed not to manifest career-criminal tendencies. If you’ve done well at school, have been able to hold down a job, and are perceived as being “reasonably intelligent” that’s all a plus. This is basically the degree of “due diligence” that this friends/family group as investors will likely go through.

Fools (um, “private investors”) like me, on the other hand, haven’t known you most of your life and have very little to go on to even know that you’re not a career criminal (or possess those personality traits). So, what compels people like me to act so foolishly and invest in people we don’t know that well, with ideas that are only half-baked and that we know are going to become huge time sinks? One, simple answer: we’ve been there before and have a pathological desire to remain involved in the startup process. I’ve made three early-stage investments in technology companies so far, and the thoughts below are a result of thinking back on why I made the investments I did and what common patterns there were.

So, here are my top practical tips if you’re ever looking to attract capital from fools like me:

  1. Be passionate about the idea. If you can’t convince me that you’re laying awake at nights plotting, scheming and dreaming about how your idea is going to change the world, you’re going to have a really hard time getting me to part with my money.

  1. Be likeable. If I’m going to put cash in your company, chances are, we’re going to be spending a fair amount of time together. (If not, then I’m likely not investing anyways). You don’t have to be obsequious (I’d prefer that you weren’t), but a certain level of respectfulness is always appreciated.

  1. Demonstrate that you’ve made some progress on the product/idea before talking to me. I don’t invest when the first use of the capital is to go find a developer to help implement the idea. Or worse – if you’re dismissive of the risks of the entire software development process. Software is hard. Its not simply a matter of saying “we’re going to outsource it to India!” and putting a line item in your financial plan. I don’t give a flip about financial plans, but I care a lot about how you think you’re going to build your offering, and why it’s going to be sooooo cool. I like to see people that are fanatically obsessed with “hand-crafting” their solution and taking pride in their work.

  1. Be realistic about your capital needs. Sure, you’d love to have $5 million of funding so that you can “do it right” and build the software company of your dreams. But, lets face it, you shouldn’t need that much money, and if you do, then go the VC path (and I wish you the best, may your travels be fruitful…) The question you have to ask yourself is: What’s the least amount of money I need to build something that someone will pay a little bit of money for. I’ll give you a hint: Its usually less than $50,000 --- with $25,000 left over to build what you should have built in the first place – but couldn’t, because you hadn’t yet gotten the feedback from your first user/customer who ended up practically throwing up all over your shiny new software…

  1. Seek analog business models. Let me explain: Binary business models are a 0/1 proposition. You go off and build a product after months/years/lifetimes of grueling work and launch it to the world. At that point, it is either phenomenally successful (i.e. result=1) or it’s a complete failure (result=0). Analog business models are those that have incremental value all along the way. You make $2,000 revenue within your first 90 days. Maybe $10,000 the month after that, etc. The nice thing about analog business models is that in the worst case, you’ve at least created something of value. And paradoxically, approaching the problem this way actually increases your odds of a blow-out success. In my experience, overnight successes take at least three years. But a different way (if you’re a programmer, which I’m hoping you are), use “agile practices” for your business, just like you do for your code. In agile development, we have “release early, release often”. In agile business, we have “revenue early, revenue often”. [Note to self: This is likely a worthy topic for its own article. ]

  1. Do your homework. There are excellent resources for learning about the basics of how capital is raised and the legal stuff around it. Though I’d love to teach you about all of this stuff (because I enjoy talking about it), I simply don’t have the time. Others can do it a lot better, and this is the kind of stuff you can learn mostly through reading.

Obviously, the above opinions are my own and may not necessarily be shared by other fools (um, “private investors”) that you talk to. But, I’m pretty sure that none of the above will hurt you. Worst case scenario, even if you don’t raise the money, you’ll be better off having followed the advice anyways.

Good luck!

Continue Reading

On Demand Software and Customer Relationships

February 6, 2006

Many of the software startups I talk to these days are offering a hosted or “On Demand” product.  The virtues of this approach are relatively clear, so I won’t repeat them here.  But, one aspect of the approach that doesn’t get talked about a lot is the difference in the ongoing relationship with customers.

 

In the traditional licensed software model, a prospective customer downloads your software, perhaps tries it (for free) for a while and ultimately buys it, at which point they become a customer.  At that point, you have basically lost connection.  You can send them emails about new releases, setup support forums etc. but in most cases you have absolutely no idea what (if anything) they are doing with the software and whether its bringing them any value.  They could be raving fans of your product, or could have abandoned it a week later.  You hope that they download regular updates, perhaps even pay for a future upgrade (if that’s your model), but that’s about it.  Given that there are 1,000 things you need to be doing as a startup founder anyway, you move on with your life until this customer needs some sort of support.

 

In the On Demand model, the relationship is very different  You have to bring value to your customers every day.  You know immediately (and in detail) whether customers are using the software at all – and if so, which features.  You can build a relationship.  In fact, you must build a relationship because that’s part of what they’re buying.  Its your responsibility to keep the connection. 

 

From, Mark Benioff, the CEO of salesforce.com:  "At Oracle, we signed a deal and we ran away as fast as we could. On demand is a marriage, traditional client-server software is a one-night stand. It's two different ideas."

 

Though I don’t consider this a perfect analogy, it conveys the message.  When providing On Demand software, your profits and margins don’t show up on the day that the check is written (or in GAAP terms, when the revenue is recognized), but are earned during the life of the customer.  This is both a good and bad thing.  We’ll miss the rush of that $100,000+ sale, but it in the long-term, its healthier.  

 

From a software startup’s perspective, the On Demand model creates some unique challenges.  Given that there is no big “upfront” license fee, the capitalization required is different (i.e. since you can’t rely on big payments, you may need outside capital until you can build a steady revenue stream).  But, this is generally more than made up for by the magic of reoccurring revenue.  Once you have a baseline of customers, and you can keep them happy, your revenue keeps growing.  You’re not starting every year (or quarter) from the ground-up.  And trust me, there is nothing like predictable, growing revenue streams.

 

I think On Demand software is here to stay for a while, and particularly makes sense for startups as it allows them to learn more quickly from their customers – and hopefully apply this learning more nimbly and quickly than their larger competitors.  Lets see if that actually proves out.

 

Continue Reading

Building It Well: Increasing Acquisition Value

February 4, 2006

In my last article, we looked at the relationship between decisions you’d make when you are “Building To Sell” vs. “Building It Well”.

 

Now, we’ll look at some practical advice for how you can maximize your acquisition value (and still be focused on building it well).  These are in no particular order, and your mileage may vary.  Please consult a trained professional before attempting to follow any of these guidelines.

 

  1. Ensure you make a “clean” exit from your prior employer.  Read any employment agreements you may have and pay special attention to any “non-compete” clauses you may have.  DO NOT use any of your current employer resources when starting your new company (especially existing code, hardware, software, etc.).  If you don’t have the money to do it right, then wait until you do (total cost for a computer and a compiler is low enough that this should not be a big problem).  Let me repeat this again for emphasis:  DO NOT use your employer’s computer to write code for your new startup.  Buy a new one.  Keep it separate, keep it clean.

 

  1. Start a corporation or LLC.  In most cases, I’d recommend an LLC (it provides decent legal protection, does not manifest the “double taxation” issue and is relatively simple to get started).  Next best choice is an S-corp.  If you’re not going to be raising outside capital, chances are you can stay an LLC or S-corp indefinitely.

 

  1. Keep a clean “capitalization table”.  This means not allocating shares in the company to random friends and family.  If you are going to take outside money, make sure you talk to a lawyer and have sufficient clarity on what rights and privileges your investors have.  Very few things will turn off an acquirer like having many people with equity in your company (many of whom may or may not be happy with the sale, their share in the company, how you’ve treated them, or any number of other things).

 

  1. Have formal independent contractor agreements with any consultants that help you write code (or otherwise help you develop your product).  I can’t emphasize the importance of this enough.  A potential acquirer will dramatically decrease your valuation (and often walk away from the deal) if you can’t support that you have clear ownership and title to your software assets.  This is essentially what they are buying.  Also, though employees have an implicit assignment of rights to the company as part of their employment (i.e. the “default”), any consultants that do work for you own the code they write by default, unless you have a contract that transfers those rights to you.

 

  1. When possible, pick mainstream platforms for your product development.  This one’s going to be controversial, because many people will argue that you should pick the platform/language that makes the most sense and gives you “competitive differentiation”.  Though I recognize the advantages of platforms like Ruby On Rails, LISP, Python and others, in my opinion, mainstream platforms like Java and .Net can often get the job done, have a strong surrounding ecosystem and are much less likely to cause an acquirer to heavily discount the valuation.

 

  1. Implement at least a minimal CRM system.  This means having a database all of your customers, prospective customers, and anyone else that has ever downloaded a trial or looked at purchasing your products.  Maintain regular dialog with your best customers – and document them.  Establish and maintain online support forums.  Foster customers talking to other customers.  Do whatever you can to make it easy for your customers to get value from your products.  Next to any code you have written, strong customer relationships is likely one of your biggest assets.  If an acquirer feels like they can leverage these relationships (or at least maintain them), it will reflect positively on your valuation.

 

  1. Maintain “clean” finances.  You don’t need a full-time CFO, but its critical to ensure that you are keeping your personal and business financials separate.  Don’t buy company things on your personal card and personal things on your company credit card.  Maintain simple and clean records of your fundamental financials (expenses and revenues).

 

  1. Make sure your customer agreements leave you an out.  Though its not uncommon to provide “perpetual licenses” (whereby your customers can continue to use your product indefinitely without paying you additional money), you should avoid perpetual support obligations.  For example:  “Pay $5,000 now and receive unlimited support for life!”.  Instead, approximate what your annual support fees should be and have an agreement that allows you to terminate should the need arise.  The rationale here is that the acquirer may see any long-term obligations that you have to our customers as a liability (and they may want the ability to discontinue certain products).  

 

  1. Pay attention to your “partnerships”.  It is likely you will consider forging partnerships that help you distribute and/or build your products.  This is usually a good thing.  However, be mindful of exclusivity provisions (that restrict your ability to do business with others in the future), as this may be a roadblock for acquisition.  Any time you enter into a new contractual relationship, make sure you look at it from the lens of your most likely acquirers in the future.  Though you may need to sign exclusivity provisions and long-term binding contracts without clean termination rights, its important that you consultant an attorney and business advisor before you do.

 

One thing all of the above items share in common is that they are in your long-term interests, regardless of whether you ever plan to sell your company or not.  This is an important element of your decision-making:  Build your company well, and should you decide you ever want to sell, you will be better positioned to do so.  

 

Continue Reading

Building To Sell vs. Building It Well

By Dharmesh Shah on January 28, 2006

Guess I’m a poet and didn’t even know it…

 

There are many people that believe that you should not try and create a company simply with the mindset of selling it someday.  I happen to be in this pool of people.  However, entrepreneurs often make the mistake of confusing “I’m not building this company to sell it” with “I don’t care about the exit value of the company”.  I have found that the overlap between the decisions you would make when “building it to sell” and decisions you would make to “building it well” is generally pretty high.

 

Lets look at some of the common dangers of “building it to sell”.   For the purposes of this example, lets say you are planning on selling the company sometime within the next 18 months.

 

  1. You decide you’re not going to make an investment in that user experience designer. Your reason is simple.  Hiring this person decreases your earnings (and hence the valuation of your company) and you’ll never really see any “credit” for this investment, because by the time the positive impacts show up, the company has already been sold (or the valuation has already been locked in).

 

  1. You decide to stop what little investment you were making in marketing (like writing blog articles).  This creates an “uptick” in your bottom-line (every dollar you save has a multiplicative effect on valuation), and the negative impacts (if there were any) won’t show up in time to hurt valuation anyway.

 

Most of the mistakes entrepreneurs make when making these kinds of decisions is failing to invest in long-term things (with the notion that it won’t really matter, because the company will be sold in the short-term).  Definitions for what is considered long term and what is short term vary, but are not particularly important to understand the concept.  The danger lies in the fact that you can’t really control your exit.  You can influence it.  You can make the price attractive.  You can talk to tens of potential acquirers.  You can do many, many things to help the deal along.  But in most cases, you can’t make someone buy your company.  In fact, even when you have a potential acquirer, you can’t control when they will actually get the deal done.  The net impact is that the decisions you were making based on your “sell it soon” model will start to create a negative impact on valuation.  This is a negative feedback loop (your company is now even less likely to sell than it was before).  Eventually, all of your short-term decisions start manifesting themselves in terms of angry customers, reduced sales, low employee morale, etc. (based on who you short-changed at the time you made the decision).

 

On the other hand, there is absolutely nothing wrong with making decisions that just happen to also increase the value of your company should you decide to sell it some day.  In fact, the decisions you make that would increase your value for an acquirer are mostly aligned with the decisions you’d make to build a great company.  This is what I call “Building It Well”.  Simplistically, you can think of the value an acquirer places on your company as an equation that looks a little like this:

 

AV = TV + GS – BS

 

Where:

 

AV = Acquisition Value (what an acquirer will pay)

TV = True Value: a complicated concept, but for now, lets assume this is based on sound financials.  This is the value that any acquirer would get by buying you (think discounted cash flows or a multiple of earnings)

 

GS = value of “Good Stuff” that this acquirer gets as a result of buying you (I’d use the word synergies here, if I didn’t hate it so much).  Examples are a list of raving fan customers that they want to reach, but haven’t been able to before.  Or a reputation for building great products (the idea is that some of this reputation rubs off on the acquirer – in some circumstances).

 

BS = value of “Bad Stuff” that reduces the goodness that the acquirer is getting.  Examples include constants (like transaction costs).  Or, that your entire code base is written in Ruby On Rails and the acquirer is a die-hard ASP.NET shop.  They’d have to figure out how to extract value from your “stuff” (regardless of how good it is).  Interestingly, it doesn’t really matter that your platform is better than their platform (I’m not making any judgments on either platform, the example is for illustrative purposes).  

 

In a future article, we’ll look more deeply at how you can increase the GS and decrease the BS (without compromising your morals, and falling into the “Building It To Sell” trap).

 

Topics: strategy
Continue Reading

The Best Way To Generate Good Startup Ideas

January 26, 2006

In my opinion, the best way to generate viable ideas for a startup – is to have a startup.  Though this sounds like a recursive statement, it seems to occur in other areas as well.

 

Examples:

 

  • The easiest way to find a job is when you already have one.
  • You are more likely to get a loan from the bank, when you don’t need one.

 

In startup world, I found in my past experience that’s almost impossible to come up with a good, feasible idea that will stand the harsh light of reality and scrutiny shone upon it.  I personally have never come up with a new startup idea that amounted to anything, and that others got excited about – except (and this is the important part), when I already had a company.  

 

Your probability of having a good startup idea (defined as one where you’ll eventually make money) goes up proportionally to the age of your company (though there is obviously an upper limit to this, as you grow and stabilize).   Net result:  You’re better off starting something, putting yourself in the game, and then filtering new ideas, adjusting your existing ones and doing something about it.

 

The reason for this particular phenomenon is quite simple.  The time it takes to get objective feedback on a new idea is much longer when you are doing it “externally” (from the outside, looking in).  You have no customers to talk to (and not even potential customers), your ideas will tend to be very extreme (instead of “adjustments” to prior ideas).  Also, it seems that the quality of feedback you get as a startup entrepreneur (that already has a company) is much higher than what you get as a “would be” startup entrepreneur.  Yes, this is paradoxical, but its true.

 

Moral of the story:  If you’ve got a decent idea, and a burning passion to start a company – go do it.  The idea you ultimately run with won’t be the idea you have now anyways, so might as well get started now.  If you’re bootstrapping it (which is mandatory in most cases), then time is working on your side so the sooner you start the better.

Continue Reading

The Startup Name Game: Part II

January 26, 2006

As it turns out, there’s been some interest from folks I know in the startup community regarding the naming process.


As a follow-up to the first article on the topic, I’d like to add the following summarization:

The primary purpose of a name is to make things easy for your primary “audience” (which in most cases is your customer base).  Make it easy to remember the name, make it easy to find you based on your name and make it easy for customers to talk about you with others and pass along a referral.


An important point I didn’t get a chance to make in the first article:

There are a lot of good reasons to name your company with a “made up” and distinctive name.  For example, my second software startup was named “Captivo” (which loosely tied back to the Latin root “to captivate”).  This was an empty vessel name as it didn’t really describe the product or the company.

Here are some good reasons to use a made up word for a startup name:

  1. Easier to get a trademark
  2. Domain names are generally easier to find
  3. Internet searches for the name will result in more relevant.  The noise to signal ratio for search results is much lower than if you had commonly used words in your company name (like “Green Frog Consulting”).


I generally keep a pool of such made up company names at hand as there seems to be an ongoing need for such names with companies that I’m starting, advising or otherwise involved in.  Its generally easier to keep these ideas flowing when you’re not under the gun and desperate to come up with a name.

 

Continue Reading

The Startup Name Game

By Dharmesh Shah on November 28, 2005

One of the issues that I find many startups struggling with (including my own) is coming up with a suitable name for the company.

 

Entrepreneurs often spend either too little or too much time on this area.  Too little is not giving it hardly any thought under the assumption that “it really doesn’t matter” (trust me, it does).  But, it doesn’t matter so much that you should go and spend thousands of dollars on a naming consultant.

 

In my past experience, I’ve come up with my own “rules of thumb” when it comes to naming startup companies.  Here they are in no particular order:

 

  1. The name should be clear enough to have unambiguous spelling.  No play on words or tricks with spelling.  If someone hears the name spoken, they should be able to know how the company name is spelled, without doubt.  Example, don’t use something like “SightSoft” (as this could be easily confused with “SiteSoft”.

 

  1. The name should be relatively short (so “Really Fast Computer Software, Inc.” is not a good idea).  Generally, the shorter the better.

 

  1. The “.com” and “.net” domain names should be available – without word games, hyphens, dashes or other “decorations” needed.  So, if your name is going to be LucidLeap, then you need to make sure LucidLeap.com is available (which its not, because I own it).

 

  1. The trademark should be available (check on http://uspto.gov).  

 

  1. The name can be somewhat descriptive of what the company does (though many will argue that you want an “empty vessel” name that can be used for a variety of things as the company grows).

 

  1. The name should be easy to remember and convey some kind of clear “mental image” to those that hear it.

 

Generally, its really hard to come up with a name completely on your own.  I’ve often found it helpful to collaborate with a couple of other people (friends and family) as they will often come up with possible flaws in a name.  If you ever have a name you want to get some feedback on, feel free to email me.  I’ll give you an honest opinion.

 

 

 

Continue Reading

Filtering Startup Ideas

By Dharmesh Shah on November 28, 2005

I have, on average, about 4-5 ideas a month.  These ideas fall into one of the following categories:

 

  1. Ideas that could become new companies
  2. Ideas that could become new products for existing companies (mine or someone else’s)
  3. Ideas that could become great new features for existing products
  4. Ideas that could improve existing features of existing products

 

I haven’t really logged all of my ideas or tried to classify how many of them fall into each of the above categories (though now that I think about it, that’s not a bad idea).  I’ll create a mini database and start doing that.

 

One of the challenges with ideas is figuring out how to “filter” them.  Or more simply, what to do with them.  For obvious reasons, most of the ideas I have are really not worth pursuing as the effort required to make something of the idea is not worth the opportunity cost of other things I’m already doing.  

 

Here’s an example:  Some time ago (I think it was last year sometime), I had an idea for improving how alarm clocks work.  For most of my professional life, I’ve never really had a set time that I needed to wake up (a luxury I’m very appreciative of).  Instead, I generally go to bed at varying times and give myself enough sleep (usually 7-8 hours, on average).  My idea was to enhance an alarm clock so that instead of programming the alarm to go off at a specific time, you could do it as a function of elapsed time (i.e. wake me up 7 hours from now).  The interface would be very simple.  The clock would have two buttons.  One for +15 minutes and one for +1 hour.  If I wanted to take a 45 minute nap, I’d tap the +15 minute button three times and go to bed.  If I wanted to catch 6 hours, I’d hit the +1 hour button six times and go to bed.  You get the idea.

 

Now, this particular idea may or may not be unique (I’ve never really researched it), but I promise you that I did not read it somewhere or happen upon on it.  Its unique, as far as I know.

 

So, what do I do with this?  The answer?  Nothing.  Even the simple act of figuring out if there’s a market, if the idea is original, if there are existing players I could license the idea to, etc. are simply not worth it.  Which brings me to a key insight (at least for me):

 

There is no efficient market for ideas.

 

If there were an efficient market, I could simply “sell” my idea to whoever wanted to buy it for “fair market value” (lets say $1,000).  Right now, the simple cost of figuring out what the idea might be worth is likely more than the idea itself.  This is a clear case of the transaction costs exceeding the cost of the item.  

 

So, what’s the point of all this?  The point is that absent an “efficient” market for ideas, you have to use an inefficient one.  That is, you filter the ideas the best you can, figure out which ones need to be pursued and which ones don’t.  In this sense, a set of “filters” should be applied.  And, for optimal efficiency, the most likely filter to block/kill an idea should be applied first.  The earlier you can take an idea off the list of viable things to pursue, the cheaper it is.  So, instead of trying to find criteria that the idea is likely to satisfy, I look for hurdles that the idea is likely not to cross.  Often, an easy one is “originality” (i.e. has it already been done).  Later, I’ll write about the different kind of mental filters I use for ideas and how I select to apply them.  So that I don’t misrepresent my process here, things are rarely as organized or analytical as I’m describing, but there is a process, and I do go through it.

 

Continue Reading

Selecting A Platform: Part 4

November 5, 2005

This is part four in the series on selecting a technology platform.

Startups generally have more flexibility in picking a platform since many of the factors that would normally drive the decision (existing talent within the organization, existing products that need to be integrated with, existing code that has to be reused, etc.) are not as significant.  Startups may also use their choice of platform as a differentiator (though this is dangerous and should only be pursued if you know what you’re doing).  

A case in point is Ruby, or more specifically, Ruby On Rails (RoR).  I’ve played around with Ruby a bit.  It’s a great language and has a certain expressive elegance that is quite appealing.  The runtime engine is also available for a variety of platforms.  In this regard, Ruby’s a lot like Java.  But, in one very important respect, its very different:  Its new and unproven.  Though there are many groups that are using Ruby to create very cool applications (particularly some of the “Web 2.0” companies), the language and the framework have not been around long enough yet to really know where things are headed.  Though customers are unlikely to care what language the application is written in (as long as it meets a need and is reasonably usable), picking a niche language/framework/platform like this can have major consequences.  Startups that choose this kind of path are assuming two things:

  1. That the platform will continue to grow in popularity and be supported over time (by supported, I mean that updates will be available, new people will be learning the language, books will be written, online forums will be available, etc.)
  2.  That future partners, acquirers and others that do care about platform choice are not going to be important.

This last point is the one that worries me the most.  I can’t tell you how many times I’ve come across a promising startup with “cool” technology that I think could have been a great addition to an existing product, but the overhead in trying to integrate it was simply too high.  Examples I’ve encountered include Tcl, Python, Perl, PHP, etc.  These are all great languages (well, maybe except Tcl) and yes, all of these have ways to be integrated using web services, but my response to this is that the integration is not deep enough and has consequences of its own.  There is nothing like taking a bunch of C++ (or Java) code and reusing it at the “build” level (instead of trying to do some type of arms-length integration.

So, my advice is, unless you really know what you’re doing (and have some immensely compelling reason), try and stick with “mainstream” platforms.  I can almost guarantee you that you’ll be glad you did (5-7 years later, when your chosen platform is still alive and well).  This is one of those cases where there truly is safety in numbers.  If you’ve got some product that simply must be written in a niche language/platform, then by all means, give it a shot.  But, for most of us, mainstream platforms are generally a wiser choice.

Continue Reading

Selecting A Platform: Part 3

November 5, 2005

This is the third part in a series of articles related to platform selection for software startups.

In this article, we’ll look at how target customers and users might affect the choice of platform.  As always, there are no easy answers, but I find it helpful to look at some broad generalities that might sway the decision towards one platform (or the other).

Lets assume we can divide customers into three broad categories:  large enterprises, small/medium enterprises and consumers. 

Today, it seems that many large enterprises (particularly financial services institutions) have a learning towards J2EE (WebSphere/WebLogic).  Without going too deeply into the rationale for this leaning, suffice it to say that this is a fine choice and these types of customers have a lot at stake when picking a platform.  Its less a matter of individual products (and how they exploit a platform) and more a matter of the how their various “portfolio” of products can be made work together and how they can leverage resources (hardware, people, infrastructure).  Large enterprises are concerned with TCO (total cost of ownership) and will generally lean towards a platform that they believe will minimize TCO.  In many shops, this means J2EE – as the platform is already proven, they have internal resources that can support it and often large relationships with application server providers (IBM, BEA, Oracle, etc.) that they can leverage.

Small/Medium enterprises have a different set of challenges (and needs).  Often, these customers value simplicity (and short-term convenience) over any kind of perceived long-term benefits.  These customers also seem to have a larger volume of client/server applications, desktop applications (as they have not made the investment in switching everything over to the web).  As a result, Microsoft and its related technologies (Windows and .Net) seem prevalent here.  Many of the applications these customers buy also need to “integrate” with existing applications they own (like Microsoft Office).  As such, there seems to be a leaning towards .Net (and even classic Win32) for these shops.  They need something that the “IT guy” (possibly the nephew of the CEO) can install on a weekend.

On the consumer front, things get a little trickier and a lot depends on the deliver mechanism (hosted software vs. “packaged” software).  If you are planning on delivering a hosted application (using some type of web application), then the platform choice is not impacted as much by the customer – other variables will more strongly influence the decision.  If you are delivering a desktop application, the choice comes down to picking which operating system you want to support.  If its Windows (which in a large majority of cases it will be), then Microsoft ..Net is the clear path.  If its exclusively Apple’s Mac (which has a smaller, but more loyal set of users), then you would use any of the great Mac development tools.  If you’re looking to support both (Windows and Mac OS) you should look at frameworks/libraries that support elegant cross-platform capabilities (like Qt).  Be careful here.  If you build a cross-OS product using emulation or virtual machines (like Java) though in theory you should be satisfying both your user bases, you will often serve neither.  The windows fanatics will sense there’s something “not quite right” about the interface and the Mac fanatics will find that its not really a Mac application (and their dogs will bark at the screen indicating there’s something wrong).

Note:  If you are building an application that will be sold to large enterprise customers, but the users of the application will be departmental folks running the application on the desktop, and a rich-client is called for, the decision looks more like the consumer platform choice.

In the next installment, we’ll look at how the stage of the company might influence the platform decision choice.

 

Continue Reading

Selecting A Platform: Part 2

November 5, 2005

A platform means many things to many people.  For purposes of this series of articles, we’ll define a platform as being a set of technologies (operating system, hardware, run-time environments, programming languages, frameworks etc.) on which software applications are created.    Also, for purposes of focus, we will look at platform selection from the context of a startup company – though much of the decision process applies equally well to software development projects within established organizations.

The selection of a platform is a critical decision for any startup developing software as this is one of the most difficult and expensive things to change at later stages in the process.  

For most applications that startups would select, the platform wars have been reduced down to a few broad changes:

  1. Java/J2EE and related technologies
  2. Microsoft ...Net
  3. Other

Of course, there are other platform choices (like mobile platforms, embedded platforms and others), but I’m going to focus on the above three as those tend to cover the majority of situations I’ve encountered – and where I have the most experience.

 

Continue Reading

Selecting A Platform: Part 1

November 5, 2005

As part of  “The Software Business” class I am taking at MIT with Professor Michael Cusumano, I participated in a team that presented topics on software platforms.

My segment of the presentation centered around how to strategically select a platform from those available.  More precisely, the theme was identifying the key variables that would influence a particular platform choice and how organizations should go about assessing the various tradeoffs.

This is the first in a series of articles on this topic whereby I drill-down a little deeper.


Here is a brief outline of the topics to come in this series:

1.       What’s a Platform?

2.       Target Market (Customers + Users)

3.       The Dangers Of Niche Platforms

4.       Platform Builder or Complementor?

5.       Reuse and Repurposing

6.       Open vs. Closed


 Stay tuned. 

 

Continue Reading
All posts

Recommended For You

Community

Let's Connect

And, you can find me on Google+, Twitter, and Linkedin.

Recent Posts

Chat with GrowthBot

It's a bot to help you with your marketing and grow. You can research your competitors, improve your SEO and a lot more. http:/GrowthBot.org

<rt id="cw8yu"><optgroup id="cw8yu"></optgroup></rt>
<rt id="cw8yu"><optgroup id="cw8yu"></optgroup></rt>
<rt id="cw8yu"></rt>
<acronym id="cw8yu"></acronym>
<rt id="cw8yu"><small id="cw8yu"></small></rt>
<acronym id="cw8yu"><center id="cw8yu"></center></acronym><rt id="cw8yu"><small id="cw8yu"></small></rt>
<sup id="cw8yu"><noscript id="cw8yu"></noscript></sup>
<acronym id="cw8yu"></acronym>
<rt id="cw8yu"><small id="cw8yu"></small></rt>

金元宝彩票注册-首页

娱乐toya365

韦德|体育

浙江省福利彩票网

中国福彩app下载安装

必威体育手机

捕鱼平台首页

智胜彩票

皇冠足球即时比分网