Ask the Wizard

Then, shalt thou count to three. No more. No less. Three shalt be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then, lobbest thou thy Holy Hand Grenade of Antioch toward thy foe - Michael Palin character, The Holy Grail

Successful businesses measure and count things. I think that's a safe assumption on top of which we can drop the following hypothesis: unsuccessful business either measure nothing, the wrong things, too many things, or finally, they measure the right things but they don't communicate the measurements efficiently.

Great lessons about what and how to measure can be found, not surprisingly, within companies whose profitability is entirely built around delivering service X more efficiently than the market. Consider a performance-based marketing company such as LinkShare, Performics or the like. These companies have to religiously measure how well certain kinds of affiliate inventory can convert to sales for certain kinds of marketers so that they can more efficiently deliver lower Cost Per Action results for marketers. Since there are lots of performance-based marketing companies, only the ones that convert at the lowest CPA's will stick around. You will find when you peek inside these companies that they measure trends and exceptions, and have very efficient mechanisms for communicating trends and exceptions throughout the organization in a way that facilitates rapid management decision making.

Of course, every company ultimately needs to execute on product or service X more effectively than the rest of the market in order to be most successful (let's ignore monopolies and oligopolies here), so it will help us to understand how we should deal with measurements and metrics reporting within the company.

Measurements and metrics reports should serve two purposes:

• Speed up, not slow down, communications within the business
  
• Provide leading indicators about the state of the business against which management can make decisions

Metrics reports should NOT:

• be a platform for rationalization
  
• necessarily require meetings to discuss
  
• facilitate the illusion of progress

The first two points about the goals of metrics reports shed some light on how our metrics reports should communicate information.

Trends and Exceptions. A year ago, one of our network operations reports was quite detailed. In order to make sure that we never missed an impending issue regarding server load or infrastructure, we had a weekly report that spit out hundreds of numbers. The so and so database is only 23% utilized, the so and so load balancer is processing N hundred million requests a day, on and on. Yikes. If you looked at this report week to week, you would quickly develop the behavior of "there is nothing interesting in this report against which I need to have additional conversations or make decisions", so it became a report that was created around which we had a weekly meeting to talk about the report. Bad. How do you improve communications between the network operations team and management and improve the delivery of information that can help make decisions about the business? Instead of reporting the same hundred metrics week to week, you report only on "trends and exceptions". When you make the network infrastructure report more of a sparse matrix in which the information showing up today is only there because it's exceptional, it becomes a much better communications and decision tool because you are only seeing things that stick out. Your eyes don't glaze over the numbers. If there aren't any exceptions to highlight, well then you probably don't need to meet about the lack of exceptions.

Green Yellow Red. Keeping in mind that the goal of a metrics report is to make communications more efficient and provide data against which decisions can be made, it is amazing how just adding a simple set of color codes to a detailed metrics report can accomplish both goals. Our most necessarily detailed operations report is color coded with green, yellow, red indicators. Green is "here is a good thing that happened you might want to know about", yellow is "here's an interesting issue, but the team is on top of it, no action required" and red is, as you would expect "issue requires management attention - here's what we've done so far". Something as simple as color coding a report improves your ability to see patterns in the business and react to them more quickly.

But certainly there are some kinds of metrics that can't be described in terms of trends and exceptions and color codes. The classic sales pipeline report, for example, helps the sales team and management understand how well the company is doing against a plan and if done right, they serve as a very clear leading indicator of revenue and a great communications tool between sales and management. My one general suggestion around the pipeline report is to avoid the mistake of creating a mechanism for the illusion of progress. What do I mean by that? Only that by creating very detailed levels of customer engagement reporting, ostensibly for the purpose of getting a better picture of how likely a deal is to close, what you can end up with is a mechanism for potentially meaningless changes in status.

The best sales pipelines I've seen are very simple and only have a couple of different stages that a lead can go through along with a simple green yellow red on pipeline vs. plan that takes into account historical close percentages on qualified leads. Frequently, management wants more detailed visibility on qualified leads, particularly n big enterprise software deals, and therefore the company will add varying stages to qualified leads, which we can just call A-E or 1-5. A potential customer at stage 5 is very likely to close, and stage 1 is perhaps just had first meeting. While I understand that million dollar software license pipelines can't just be "unqualified, qualified, and closed", the pipeline report should provide only enough detail to accurately predict results, otherwise you are just facilitating the illusion of progress. I once worked with a company that had very detailed stages that a qualified lead would go through, but of course, these stages are all abstractions until you've signed on dotted lines. Management then felt these very detailed stages gave it a better handle on "where this customer was in the process", however, what you would start to see happen is that the sales team would "manage status" in order to effect the illusion of progress, not even consciously, but just as a way to show effort week to week. We might be on a monday pipeline call, and two big deals would move from stage 2 to stage 3...."we made a lot of progress last week. I think we can bump GiantCo up from a 33% to a 50% likelihood...." and then we would hear another five minute explanation regarding why this was now 17% more likely to close. There are two problems with this kind of measurement. First, it's not real unless management has some very detailed sense of the historical rate with which stage 3 deals close vs. stage 2 deals by these exact sales people, and second and maybe even more importantly, the business becomes more about managing status and soaking up time in meetings around status instead of running the business.

Much better to have one page pipeline summaries that highlight how the next months and quarter look against plan based on historical close percentages, and then sheets behind that with trends and exceptions that are color coded (eg, we have three deals that came in last week that are 50% larger than our average deal size, the GiantCo deal has been in the pipeline for 200 days and hasn't closed so it's yellow because once a deal is more than 200 days old we tend not to close them, etc.).

The bottom line on metrics is that you want to provide everybody in the company with the best information about the health of the company and create a platform for decision making. By just "measuring everything" you can get into situations in which the business becomes more about the measuring and less about the communications and decision making. The things you DO measure, you should measure religiously and take decisive action when the data speak up.

Posted by Dick at 08:50 PM | Permalink | Comments (8) | TrackBacks (0)

A common theme I hope to address in this blog is accepted wisdom, especially when I think I've got a bit of a different spin on things. One piece of accepted wisdom one hears in software circles these days is "release early and often", and as you can tell by the title of this post, through the miracle of foreshadowing, I have a slightly different perspective.

Let's start off with a few hypotheses. Some of these you will take for granted and others you may argue:

1. Extensible architectures generally provide more long-term business value than point solutions, although point solutions may monetize a specific market more quickly
2. Software that hasn't been released can be changed in ways that become less possible N customers after launch. As N grows, so does the difficulty in refactoring some percentage of infrastructure or functionality. Additionally, as more than 1 copy of the software is released into production, these difficulties multiply.
3. You have no idea what capabilities the market will want from your software in one year
4. Customers generally value functionality and speed of ROI over flexibility and extensibility, however in order to maximize your chances for long-term success, your business values flexibility and extensibility over specific functionality.

Since my brain doesn't go as fast as it used to, I'll have to use an example from FeedBurner since I can't remember how we did some of these things in previous companies. Four of us started working on FeedBurner in October of 2003 and we launched around the end of February 2004 with only two simple services: a primitive v1 of our feed statistics and a format transformation service (eg, Atom -> RSS2, RSS2 -> Atom). Five months of four people working full time just to rollout something that resulted in the following initial comments: "I could build this in a weekend" and "It doesn't really do anything".

When we conceived of the idea for FeedBurner, we weren't thinking "we'll rollout these couple services and then see what else we should do based on feedback", because we could have launched something like that in a few weeks. We were thinking "the ability to provide a robust suite of feed clearinghouse services across a broad set of feeds will be a powerful service for publishers. We don't know what all of these are right now, but if we architect the system for extensibility, we'll be able to quickly provide additional capabilities and lead the market". We probably didn't say it like that. I'm sure it had a lot of "um's" and "you knows" and "yeah and then like we could do more stuff", but you get the difference between the two statements.

Sounds great, but what does it mean? If you don't know what you don't know, how do you know what you won't know until you know it? What the heck does "architect for extensibility" mean, and how do you do it without hurting yourself and wasting a lot of time?

I'll use an analogy and then provide another simple and general FeedBurner example that might paint the picture. Like most of my favorite analogies, this one doesn't really make any sense, so just bear with me. Let's say you have two brothers, Kenneth and Jake. They both decide to go into the milk shake business. Jake seems to have distinct advantage because Jake's Shakes sounds a lot better than Kenneth's Shakes, which is hard to even pronounce without giggling. Jake decides that people want vanilla shakes and he quickly deploys a set of vanilla shake shops suited to make only vanilla shakes. Kenneth decides that he's not really sure what kinds of shakes people might want, but he wisely guesses that people might want different flavors, like chocolate or wasabi. This is really a stupid analogy but you see where i'm going; Jake gets to market first and MAY have a big hit or may have limited distribution. One thing we know for sure is that people better like vanilla shakes because that's all he's set himself up for, and the more copies of his store he creates, the harder it's going to be to go back in later and change the business. Kenneth has set himself up for a number of possibilities and will be prepared to rapidly react to the market when he launches some time after Jake, even if he also launches with only vanilla shakes. IF the world loves a smartly branded vanilla shake, then hooray for jake, he's got the better name and was first to market. IF the shake market moves against vanilla, however, or the shake market for vanilla proves to be but a tiny fraction of the overall shake market, then hooray for Kenneth. He will reap the benefits of designing his product for extensibility and be able to hire somebody to come up with a better name than Kenneth's Shakes.

Much more simple to understand the FeedBurner example. We didn't spend the first five months building those two services we rolled out in February. We spent the first five months building out the architecture for feed filtering and feed processing such that we could quickly deploy any new feed service we decided to build, and then we spent about a week building out those first two services. Yes, it was true that somebody could have built a competitor to what we launched in a weekend. However, we would be able to quickly iterate and innovate on top of our release, whereas the built-in-a-weekend competitor would have to keep building one-off services that would eventually either become untenable or require an incredibly long period of underlying architecture refactoring while we continued to innovate.

The bottom line being that you want to invest pre-launch such that you optimize for innovation post-launch. This is never more true than when it seems like you are racing into a market with multiple competitors and your inclination is to hurry up and launch something! The advantage you have prior to launch is that you don't yet have customer demands. Set yourself up to be in a position to rapidly iterate and innovate post-launch and you will be in the best position to put the first movers back on their heels if they aren't in a position to react to market forces as quickly as you.

It would be very easy to misconstrue this post as "you have to make sure you have thought everything through and are ready to scale to milions of customers before you launch". That is not at all what I'm saying here. Architecting for extensibility is not about "making sure you've planned for every contingency". I'm speaking specifically about your core product or service's underlying design and how well it's prepared for speed of innovation. Other aspects of the business like"what if we need to open a facility in Nevada someday" are going to have to wait until later.

I suppose a reasonable question here would be "how do you distinguish between overthinking the architecture vs. architecting for extensibility?" That would be a good question; I frequently think my own questions are good questions, and I'll try to come back to it in a follow-up post. There are also some small things you can do to plan for future growth that I'll address in another follow-up post that I will hopefully remember to call "Planning for Success".

Posted by Dick at 10:20 PM | Permalink | Comments (18)

I hesitate to even start writing about options. They make my head hurt. Anything I write about options will likely be met with the ninety-one different opinions about options that have been forged by ninety-one different prior outcomes for ninety-one different people. Options are like bad tequila, you wake up in the morning with packing tape where your eyes are supposed to be and all you can think is "It seemed like such a good idea at the time when that guy said 'hey everybody, let's issue options!'". I think I'll start the options discussion with some discussion of rudimentary starter points and only dive into the murky depths later on.

StarterTopic #1: The options pool
You have started your company and you're raising capital. You have been fortunate enough to get a term sheet that says these nice people will give you 2 million smackeroos for 40% of your company, thus giving you a post-money value of 5 million smackeroos. You previously owned 100% of the company, so now the investor owns 40 percent and you own 60, right? Well yes, but just for now.

Your investor is likely investing 2 million with the hope that you are going to put some of that capital to work by hiring employees to flesh out your organization, and savvy employees are going to want some form of equity. Far more often than not, your investor's terms are going to mandate that you create an options pool from which to issue these new employees equity. Who gets diluted to create this pool? Nobody and Everybody. Let's say your financing mandates the creation of a 10% options pool just so we can keep the math simple (you should assume you will be creating something between a 10 and 20 percent pool, usually more like 15 or 20). Let's say that your investor owns 400 shares of preferred and you now own 600 shares of common. The way the options pool gets created is that you will now authorize another 111 shares of common that will be unissued.

Why didn't you just authorize 100 options, since 100 is 10% of 1000? because those authorized shares are part of the total equity now and 100 is not 10% of 1100. Capiche?

Do you now own a lot less than 60% of the company? No, you still own 60% of the company because those 111 authorized shares for options are unissued. If you sold the company tomorrow, those 111 unissued shares dissolve into the mist and there are 1000 shares of which you own 600. Once you start hiring however, you will start issuing shares out of this options pool and as those options vest over the years, everybody dilutes. Pay attention because this is the really easy part of options and we haven't even done our first tequila shot yet. We are still having chips and salsa, and everybody is looking at the menu.

Starter Topic #2: Acceleration
When you issue options to employees, you generally issue them along with some vesting schedule. The vesting schedule says simply that you can't exercise the option to buy these shares on day one, you become vested in these options according to the length of your employent with the company. A typical vesting schedule is something like a 25% 1 year cliff with an additional 1/36th vesting every month for the following three years. In plain English, this means that if you issue employee A 1000 options, then none of those options vest until the 1 year mark, at which point 25% of them vest. Then, every month after that for the next three years, another 1/36th of the remaining options vest every month, such that at the end of four years, the employee is "fully vested"; ie, they can exercise their option on all 1000 shares and become the proud owner of 1000 shares of common stock in the company. I guess that wasn't plain English, but it will have to suffice.

Options agreements can vary wildly. Consult your physician thoroughly regarding all of this stuff. I mention it only as a prologue to acceleration.

The notion behind acceleration is that you may have employees who don't want to wait no stinking four years if something exciting happens to your company, like it is acquired or there is some change of control. There are different kinds of acceleration, but you will generally hear terms thrown around like "single trigger" and "double trigger". I'm really over-generalizing now, but single-trigger acceleration generally refers to a situation in which the options agreement states that all of the employee's options vest on a change of control, while double trigger may state something like "50% of unvested options vest on change of control and the other 50% vest on termination after change of control".

I won't go into my various opinions about acceleration here, largely because opinions about options are so frequently colored by what happened to you in the past or at the very least "what happened to me the last time I was issued options", and it's different for everybody, but suffice it to say that you want to nail down your company's approach to acceleration in the early going, have a definite philosophy and point of view about it given the different potential outcomes, and then try to maintain a consistent policy within specific groups of people as you grow the business and add more people. By "within specific groups of people" I mean that you might have one acceleration policy for external board members and another for employees, but try to have a consistent policy for employees and a consistent policy for BoD, etc. Acceleration is obviously dilutive to the existing shareholders but it's employee friendly, so you have to figure out what works for your company. Your investors will have strong opinions about this as well.

As with just about everything I write about here, there are 19 more things to say about acceleration, but this is a good start, and I really just want to lay the groundwork for an eventual discussion about issuing options vs. restricted stock.

My head already hurts, and we haven't even started talking about pricing, IRS 409A, and tax treatment of ISOs vs NQSOs.

Posted by Dick at 09:48 PM | Permalink | Comments (3)

One great way to beat your competitors is to have less of them, and the best way to have less competitors is to stop creating them, inviting them into your markets, and fostering their growth.

Once again, I will discuss the market I know best, software startups. In the software business, I would say that most companies actually create or facilitate the emergence of their biggest eventual competitors. Companies in this market create competitors through the following strategic decisions:

1. No open API. I will do an entire post on API's here at some point, but when you create open api's for your software product or service, all sorts of secondary benefits accrue to your company that you will be unable to predict on day 1. You may even discover interesting business models via 3rd party development that opens your eyes to new possibilities. But the best reason to always build out API's for your product is that it makes it easier for the rest of the world to extend your product or service rather than start competitors. Here's a simple example: there's a smaller content management system that's used mostly outside the US. Because FeedBurner has an open feed management API, a couple of independent developers were able to build a robust FeedBurner plug-in for this content management system that we'd never heard of. If the FeedBurner API didn't exist, there's an opportunity for a competitor to emerge that services this market and gets a beachhead. API's are not an obvious investment for companies because a) it's not obvious how you monetize them and they're a lot of work to maintain and b) people wrongly believe that API's invite competitors to build on your back. In fact, the opposite is true. API's inhibit the necessity to build competitors as third parties will simply leverage the API to extend your own offering. My cofounders and I have seen tens if not hundreds of examples of this over the years.

2. No free version. You don't have a free version? There are lots of people who want a free version of whatever it is you provide. You say you have put too much work into your software to offer a free version? Too bad, there are lots of people who want a free version of what you provide. You say you can't make money with a free version? Too bad, there are lots of people who want a free version of what you provide. Guess what happens when you don't provide these potential customers with a free version? Somebody else builds a free version. Guess what happens when those free version customers are ready to upgrade to a paid version? Nine times out of ten they use their existing vendor's solution since they now have a relationship with this provider. That other company doesn't have a paid version you say? They will. That other company's paid version isn't as good as yours, you say? It will make no difference. If you want to create powerful competitors to your company, make sure you have no free version of your software product or service.

3. Partnerships in non-strategic areas that place company X between us and our customer. This one is particularly dicey for a couple reasons. First of all, you can't do everything yourself and there will be a bunch of services your customers want that aren't a core competency. You can deny them these services or find partners that can provide them, and the right thinking service provider generally believes that happier customers are better customers. Similarly, your customers don't think of themselves as "yours", so attempting to create unnatural relationships in which company X can provide their services through you but only if they don't have a direct connection to the customer ends up feeling weird and wrong to the customer (think mobile operators). In almost every startup I have been involved with, we have created future competitors this way. It's possible, I don't know, that you either have to say "we own the customer and never shall others get anywhere between us and our customers without routing through our proprietary stack" OR "we're going to find ways to provide the most robust set of services to our customers, and we understand that implies we will be fostering competition in specific niches of our potential market". Certainly, the mobile network operators and Apple have taken the former position and it's hard to argue that this has hurt them. However, it's also clear that there's ongoing discussion in the marketplace that an iTunes competitor with a less proprietary/closed stack would be something people would like to see. Yahoo! has traditionally taken the latter path and obviously, they fostered Google's growth by providing the powerful new search engine with a platform for accelerated audience reach. One takeaway here is just to realize and be very honest with yourself that certain partnerships can facilitate the emergence of a niche competitor then make sure you understand the implications before diving into anything.
   

Now, even if you have a free version and you innovate regularly, and you have an open api, and you don't create unwise partnerships, you may still find yourself facing enormous competition (see Netscape v. Internet Explorer), but you can certainly make your life easier by not choosing decisions that either invite competition or sow the seeds for rapid competitor growth.

Posted by Dick at 08:35 AM | Permalink | Comments (6) | TrackBacks (0)

I've gotten a couple emails lately from would be entrepreneurs that go something like this: "I'd like to start this new company that I've had an idea for, but there are so many companies launching now and the market for software startups is so crowded, that I wonder if it's really a good time to dive in".

I don't recall that my cofounders and I have considered what "the market" was like when we started a company. I can't imagine serial entrepreneurs like Mark Fletcher, Mike Cassidy, or Elon Musk ever give even the slightest thought to whether the general startup environment (economy, access to capital, access to talent, etc) is good or bad.

There aren't "too many companies in the market right now". Even if there are 90,000 more companies, there still aren't too many companies. Neither is there too much capital or too little capital or not enough engineers in this market. There are only specific market forces that you should weigh vis-a-vis your specific company. If you are starting a me-too software startup right now (eg, a video sharing site), then yes, there might be a lot of well-funded companies chasing that specific opportunity and you would be wise to consider that fact in shaping your strategy.

It seems silly to me that one would worry about the general market when starting a company, but obviously it's a bit of a common theme. So, that led me to wonder what would cause you to have that kind of mindset, and what I think I am really hearing is fear of failure. I think the questions are really "is this environment one in which it will be harder for me to succeed?", and I will therefore provide a simple answer to this question: Every market is one in which it will be harder for you to succeed. If access to capital is plentiful, then there will be more companies chasing that capital and more well-funded ventures against which you must compete. If access to capital is scarce, however, it will be harder for you to raise money and you will have to endure more investor-friendly terms on financing and have to show more business model progress in advance of further funding. If there are few competitors in your market, then you need to evangelize your value proposition more passionately to the market in order to gain traction. If there are many competitors in your market, then you need to distinguish yourself from competitors more thoroughly. If you're a first-mover, why should anybody need your new service, if you're a follower, why should anybody switch to your service?

On a psychological level, I think a lot of people confuse fear of failure with not having enough confidence in the ultimate success of their idea. They thus conclude that they aren't confident enough in their idea or their strategy because it seems to have holes and flaws for which they don't have answers. This is a tremendous mistake. While I won't pretend to speak for the entrepreneurs I mentioned above, I bet if you asked them if they were confident on day 1 that they had a winner with each of their previous successes, they would look at you sideways and say "of course not". Speaking for myself, I can say that my cofounders and I try to find a market opportunity that seems like it will need to be addressed and for which we think we have some angle and then we just pull out shovels and start digging and figure other things out as we go.

Personally, I know going into any new company that there is a 90% chance we have the business model wrong on day 1. I also know that I have a historically poor track record for understanding what will and won't attract customers or defeat competition (I didn't get Twitter when Obvious Corp first launched it without an "e" in the name, I thought eBay would be out of business in six months after Amazon launched auctions, and I was certain Netscape would crush Microsoft in the browser wars because Netscape was more nimble). But the opposite of 'fear of failure' isn't confidence. The opposite of 'fear of failure' is just not bothering to think about failure (BIG difference between this and thinking about risk profile for your idea/company).

Of course there are entrepreneurs and CEO's who pitch their supreme confidence in themselves and point to some ability to work out all the angles that guaranteed their success. Most of them do this in retrospect after they've been successful, and maybe this leads other would be founders to think "I don't have the faith in my idea this guy/woman does. I'm passionate about my idea, but i don't have that supreme confidence in it". The key is to just get on the bike, and the key to getting on the bike is not the confidence in knowing you will be successful if you do x,y,z. The key to getting on the bike is to stop thinking about "there are a bunch of reasons i might fall off" and just hop on and peddle the damned thing. You can pick up a map, a tire pump, and better footwear along the way.

This set of mixed metaphors and loosely coupled analogies was brought to you by guy-with-no-formal-writing-experience.

Posted by Dick at 09:28 AM | Permalink | Comments (12) | TrackBacks (0)

I was asked by a commenter on my Best Available Athlete post if this theory implied that I was a subscriber to the hire fast, fire fast method and what I thought about Joe Kraus' No False Positives hiring philosophy.

Briefly, the "No False Positives" school of hiring says that bad hires are worse than no hire because bad employees infect the company with all sorts of issues. Better to march on with nobody filling an important slot than to bring in a sub-par performer.

The hire fast, fire fast approach basically can be boiled down to "it's really almost impossible to understand whether a person is going to be a killer A+ match before they start working with you day to day, so best to find somebody that seems close enough, and then remove them quickly if they don't work out."

I have a couple general observations I'll make aobut these kinds of hiring philosophies. One of these observations may contradict another, but such is life....hiring is hard and nobody said the wizard was consistent.

I buy the hire fast, fire fast line of thinking for Sales Reps or VP Sales roles but I don't buy it for Engineering, Marketing, Finance, etc. The problem with hire fast, fire fast in the engineering department is quite simple: you don't end up executing on the fire fast part of it and the bad hire infects the organization for an extended period before you figure out how to remove them. Engineering goals are more generally team goals, there can be lots of reasons code can ship late, and performance criteria are more subjective than sales performance criteria. The mediocre hire ends up becoming part of the team and it just ends up taking longer to fire that person on the team, by which point they've added more subpar work to the mix. So, I am a subscriber, outside of sales, to the thesis that you have to interview rigorously and that it's better to leave an urgently needed role empty than to bring in a "false positive" who will infect the organization. You can only try to accomplish this by having multiple people interview the candidate over multiple days with multiple interviewing techniques.

Second observation: You can hire fast, fire fast with sales people. It's very very hard to comprehend a priori who will be able to best sell your service/product in a particular region to a particular customer base. Since this is an area of the company where people generally are responsible for very straightforward, measureable and explicit individual goals (ie, sales targets), it's much easier to communicate and implement a hire fast, fire fast kind of policy with this group. You have to ensure you really stick to it however, and understand when company processes and products are causing the sales ramp challenge(s).

There's one big problem with a pedantic devotion to the "No False Positives" approach, and it's that you can miss out on really high quality people that don't have all the t's crossed and the i's dotted but that can have an assymetric positive impact on your company. In the "Best Available Athlete" post, I was trying to describe a way of bringing these people into the company. You find a person that's just a dynamite all around person who excels in all sorts of ways but maybe they don't answer all the java questions correctly if they're an engineer or they don't have all the requisite experience for a vp operations or they're interviewing for a marketing position but they spent the last 2 years as a bank teller in Toledo Ohio for some reason. I think when you find this kind of person, you try to slot them into a role in the company instead of looking for a more classic fit.

Posted by Dick at 12:18 PM | Permalink | Comments (5) | TrackBacks (0)

When entrepreneurs are raising Venture Capital, it seems like attention and focus are weighted 80% to pre-money valuation and a couple percent each to all the other terms, and I think this is a mistake. I've talked previously about obsessing over pre-money valuation in an early round (seed, A, B) at the expense of other terms, and I'll start talking about some of these other terms now in a series of posts. I'll try to interlace these posts with operations and company structure posts to keep things interesting for everybody.

Today's VC term sheet topic is Dividends. FeedBurner investor Brad Feld wrote about this topic extensively in one of a series of posts about Term Sheets from the VC perspective. I'm going to copy Brad's typical Dividend section language here and discuss it briefly from the entrepreneur perspective.

"Dividends: The holders of the Series A Preferred shall be entitled to receive [non-]cumulative dividends in preference to any dividend on the Common Stock at the rate of [8%] of the Original Purchase Price per annum[, when and as declared by the Board of Directors]. The holders of Series A Preferred also shall be entitled to participate pro rata in any dividends paid on the Common Stock on an as-if-converted basis."

The first thing to point out is that you should pay careful attention to the areas in here that will vary from deal to deal. Brad has done a good job of highlighting these. There are three of them and I'll talk briefly about each. Before I do that, let's briefly consider the "founding fathers' intent" behind the dividend section. The explanation you will sometimes get from Venture Capital investors is that the dividend is just there in case the deal goes sideways (not a home run, not a complete bust), and it therefore provides for some return on investment at some point that juices the investment and drives some value back to the investors. As Brad note in his post, "...[they] don't provide venture returns, they're simply modest juice in a deal."

So, as an entrepreneur, you would like to minimize the impact of any dividends you have to pay out. To simplify it in the extreme: Automatic cumulative dividends bad, non-cumulative non-automatic dividends good. If you're accruing an automatic cumulative 8% dividend on the investment dollars, you won't like what those kinds of numbers start to look like in year 5 and year 6. More importantly, cumulative dividends are an accounting nightmare and you will spend more time than you care to even know working with your finance team and auditors on how you should account for cumulative dividends and their effects.

Fortunately, Brad's typical language above makes our job easy, and we can quickly highlight what you want to negotiate in your term sheet. You want three things: a) you want non-cumulative, not cumulative, Dividends; b) you want the lowest possible dividend percent, let's say 6%; c) you really want "when and as declared by the Board" in this section because the board will include operating executives of the company, perhaps a founder, and different investors, and these will rarely, if ever, be declared.

Having said all this, an obvious question that arises is "if non-cumulative when declared" is so benign, why not negotiate the section out altogether? Obviously you can try to do whatever you want, but one thing any private equity investors are going to look to do in any deal is look for some opportunities to manage the downside risk. This is one of those sections, and just get this sucker to the point at which it causes you no pain. Non-cumulative when and as declared by the board is reasonable and causes you no pain.

I would suggest you read all of Brad's Term Sheet posts if you're out raising money. Brad writes in a very common sense way that generally reflects both sides of the discussion about Term Sheets.

Posted by Dick at 11:34 AM | Permalink | Comments (2) | TrackBacks (0)

In my previous strategy post, I talked about something I called Quantum Hidden Barriers to Entry and why businesses that had those are great businesses. This post was misinterpreted in some circles as "you can get so far ahead of your competition that they can't catch up" and a number of folks wrote to me saying that no competitor can defeat hard work, passion, innovation, etc. This is simply not the case, otherwise there would be seven compelling competitors to Digg and AdSense right now, and there aren't. Instead of re-explaining what I mean by quantum hidden barriers to entry, I'll instead talk about how I think you compete against companies with lots of hidden barriers to entry. It's quite simple - you don't attack them by trying to compete with them head on, you don't meet force with force. You attack them by either changing the rules of the game that's being played or even better, you pull out the Aikido bag of tricks and use your competitor's strength against them.

By way of real world example, look at the way Jason Calacanis decided to compete against Digg when he relaunched Netscape as a community news site. Instead of simply trying to do what Digg was doing with more passion and harder work (always a bad idea to assume you're smarter or more passionate or harder working than the competition!), he started with an assumption that Digg was the dominant player in the market. He then wrote a very public and widely discussed blog post in which he laid out a case that Digg's community had become so big that it was too big, and no community of that size could create quality. Then in a later post he noted that the community was so powerful, that nefarious beings from the spammy underworld would surely start trying to game the system by paying the top diggers to digg stories, etc. (this is the 1-2 Aikido....redirecting your competitor's strength and energy, attempting to make that strength a weakness). Jason then hypothesized that the better way to build community powered news was to pay the top voters because you have to pay to get quality and direct payment will dramatically reduce or remove their incentive to take money from spammers since it would put the direct payment contract at risk.

It makes no difference whether you think Jason's challenges to Digg were accurate. I would further caution against measuring the success or failure of this particular attempt as validating or invalidating the strategy. Note only that Jason's means of competing meant not having to address some of the hidden barriers to entry around community news systems that have been erected in Digg's wake because he changed some of the rules by which he was going to play the game when he launched with paid contributors.

There are lots of ways to compete against an entrenched competitor with strong market share, but force against force is generally not the most fun approach.

In another post soon, I'll explain how I think you should consider competition when you're in a new market without entrenched players.

Posted by Dick at 09:44 AM | Permalink | Comments (2) | TrackBacks (0)

A commenter on a previous funding post noted that I discussed having personally done different sorts of financings including Friends and Family but then didn’t elaborate on this point. I’ll remedy that now in a short post on the matter.

There are two things I hate about friends and family financings and one thing I really like about friends and family funding.

First, the good news. I generally think these are great ways to finance companies that might not need much more capital. If you can get off the ground with a small financing that friends and family can perform and that ultimately takes the business to cash flow positive, then this is a great way to go. You don’t have investors that necessarily need to get liquidity at some point, you probably have much more favorable terms, etc. You can grow the business at your pace and everybody’s happy.

However, as the commenter on my previous post noted, the more emotional connection that one has to friends and family investors can be a real problem and may lead to one or more of the following: a) not throwing in the towel when you really really ought to throw in the towel, b) not being honest with your friends/family/yourself about the state of the business if things aren’t going well (and you’re going to want SOMEBODY to turn to!). Finally, there's the general emotional distress if you are in a situation where you aren’t as far along as you thought you’d be at this point and your friends and family "need their principal back". Uh-oh, that’s not going to be a good time for anybody.

The second reason to dislike friends and family funding is when you follow it up with a more formal venture financing. Your venture investors are going to want preferred stock with all sorts of special rights and privileges and now you are in the uncomfortable position of telling your Uncle why John Doerr’s dollar is worth more than his dollar. Although that wouldn’t be too uncomfortable a position as you could follow that by describing some of John’s other investments, but I digress, and hopefully, you see my point.

One last thing – the comment on my other post asked that I blog how it worked out when I raised friends and family money. Fortunately, it worked out fine. It was my first entrepreneurial endeavor, it was family not friends money, and when things were rough sledding after a few months, there was a healthy dose of motivation due to “owing” the family money that probably got me through some early jitters and second thoughts.

Posted by Dick at 07:03 PM | Permalink | Comments (4)