Boston Angel Bootcamp was well worth the time to attend.
Sim Simeonov presented an analysis of angel investment outcomes. The net is that most angels lose money but a small number do very well. The difference between losers and winners seems to be that winners make a lot of investments; ie portfolio theory applies to angel investments too. In addition, he recommended that in order to improve deal flow, an angel should get a reputation for making fast decisions and should be able to drag additional investors along for the ride. I'm sure I'm misrepresenting a lot this, so I'll be waiting for Sim's blog post where he explains it in more detail.
There was also an interesting discussion of the problems with convertible notes. John Landry of Lead Dog Ventures said that there is a chance that followon investors would not honor the conversion discounts (which prompted audience comment that it was the entrepreneur's responsibility to protect current investors in subsequent rounds) and that the typical 20% conversion discount is inadequate compensation if the note is held for more than a year with no conversion. John says angels should do the work to put a valuation on the company and should take founders shares. John also advocates taking a board seat and being very active with one's investments.
Recorded video of the sessions: http://www.ustream.tv/channel/angelbootcamp
Slides for additional presentations from the #angelbootcamp twitter stream:
David Cancel - http://talks.davidcancel.com/slideshare/
Alexis Ohanian - http://www.slideshare.net/kn0thing/alexis-ohanian-at-angel-bootcamp-boston-june-01-2010
Also: Good summary at xconomy:
http://www.xconomy.com/boston/2010/06/02/calling-all-angels-experienced-aspiring-angel-investors-confer-in-cambridge/
Sunday, June 6, 2010
Saturday, May 29, 2010
Convertible Note Conversion Discounts
I passed on a deal this week because the terms were bad. It was a seed stage deal, I like the entrepreneurs, the technology was cool new stuff invented in a university, and they seemed to understand the landscape well enough that I was willing to break my "no pre-revenue" rule and my "no hardware" rule.
The deal breaker was the convertible note terms. The typical convertible note deal (for Boston in the past couple of years) has 2 terms: an interest rate and a conversion discount. The note for this company had a single-digit interest rate and no conversion discount. If you spend 10 minutes with a spreadsheet to compute the post-money valuation of your investment, you can determine that the discount is the main incentive to do this kind of deal. A convertible note without a discount would have to carry an interest rate of 20%-30% to make up for it.
When I asked about the lack of a discount, they told me they had their agreements done by a Silicon Valley law firm, and this firm strongly advised them to not offer discounts since A-round investors would push back on the discount and make it harder to raise the next round. I explained that without the discount, there was no risk premium to justify investing now versus investing later. Their hands were tied since they had already closed money under these terms, so we parted ways.
So now I really want and need to know if A round investors make a practice of crushing convertible note investors like this, or if this is an echo of deals done after the dotcom crash? Were the entrepreneurs poorly advised by their law firm? Or are Angels just fodder for follow on investors?
Quick Hits
H.R.4213 American Jobs and Closing Tax Loopholes Act of 2010: The House of Representatives is taking another shot at taxing Carried Interest as regular income. I don't see why this is controversial. Carried Interest is not Capital Gains. If you want Capital Gains tax treatment, you should have actual Capital at risk. Trying to argue otherwise is disingenuous.
I'll be at the Angel Bootcamp in Boston on June1. It doesn't sound like a regular bootcamp; it starts at noon instead of 4am and I don't expect to have to do any pushups.
The deal breaker was the convertible note terms. The typical convertible note deal (for Boston in the past couple of years) has 2 terms: an interest rate and a conversion discount. The note for this company had a single-digit interest rate and no conversion discount. If you spend 10 minutes with a spreadsheet to compute the post-money valuation of your investment, you can determine that the discount is the main incentive to do this kind of deal. A convertible note without a discount would have to carry an interest rate of 20%-30% to make up for it.
When I asked about the lack of a discount, they told me they had their agreements done by a Silicon Valley law firm, and this firm strongly advised them to not offer discounts since A-round investors would push back on the discount and make it harder to raise the next round. I explained that without the discount, there was no risk premium to justify investing now versus investing later. Their hands were tied since they had already closed money under these terms, so we parted ways.
So now I really want and need to know if A round investors make a practice of crushing convertible note investors like this, or if this is an echo of deals done after the dotcom crash? Were the entrepreneurs poorly advised by their law firm? Or are Angels just fodder for follow on investors?
Quick Hits
H.R.4213 American Jobs and Closing Tax Loopholes Act of 2010: The House of Representatives is taking another shot at taxing Carried Interest as regular income. I don't see why this is controversial. Carried Interest is not Capital Gains. If you want Capital Gains tax treatment, you should have actual Capital at risk. Trying to argue otherwise is disingenuous.
I'll be at the Angel Bootcamp in Boston on June1. It doesn't sound like a regular bootcamp; it starts at noon instead of 4am and I don't expect to have to do any pushups.
Sunday, May 2, 2010
Angel Renaissance at Nantucket Conference 2010
In the 90's, you needed millions to get a software company to market. Today, software startups might need 5 figures to prove a market, 6 figures to launch the 1.0 version. On the other hand, software startups do require a lot of operational help. Traditional VC firms have an impedance mismatch for software startups: they don't need the large amounts of capital that VC firms need to deploy. And since they don't need the capital, a VC partner cannot justify making a large investment of time. So angels (and small vc funds) can step into this void. Angels can invest 5 figures in a true seed round to prove the market, and can spend the time required to provide operational guidance to the team. The challenge for angels (besides coughing up the cash) is picking winners, and cultivating your picks. This was the basic message at a number of panels and side conversations. There is also an angel bootcamp in a month that will hopefully help grow the population of potential angel investors.
A critique of this message is that it doesn't address the concerns of angels. It's all well and good to talk about how angels should take a chance on young entrepreneurs, and how entrepreneurship is our best chance to avoid economic decline in the US. But, unlike a VC, an angel's concerns in priority order are (1) not losing money, (2) making money, and (3) everything else. So angels will tend to be more cautious investors: there is no pressure to deploy capital, there is the normal human loss avoidance behavior, and once you've made your money it's easier to shrug off opportunity loss. So while the community organizing efforts may grow the population of investors, I don't think we should expect that this will make it easier for entrepreneurs to raise capital.
Nor should we want it to. Based on my short experience as an angel, the problem is not enough good ideas and good teams. Northeast Angels gets dozens of submissions per month on Angelsoft. Most of these are weak ideas that are not suitable for investment. Some are good ideas with a good but inexperienced team. I suppose this is the area where a larger population of angels can have the most impact on the economy.
Best (paraphrased) quote from the conference: the participation trophy for life is called a tombstone. (Jason Calacanis via skype)
Monday, March 15, 2010
Schema Extensibility in Commercial Enterprise Software
This document describes how schema extensibility is typically achieved in commercial enterprise software applications; in particular, in customer relationship management (CRM) applications.
Flexibility Requirements
In CRM applications, implementing organizations need to extend the customer data model with business-specific information. The data model extensions consist of adding single-valued and/or multiple-valued properties to the customer data record.
General Approach
Vendors typically use a metadata-driven approach:
The implementing organization wishes to add a "favorite color" field to their customer records. The extension table has the following schema:
Extension Table Schema:
Through a UI, the user creates the following record:
When the user is satisfied (ie when the user hits a button), the application executes the schema change by issuing the following SQL statement:
ALTER TABLE Customer
ADD COLUMN Favorite_Color varchar(25);
Notes:
The Column_precision column will only be used for NUMERIC fields.
Extension columns must typically be NULL-able or the user must provide a default value for the new column.
Example: Multi-Valued Schema Extension
The implementing organization wishes to associate a list of purchased products with a customer record. The schema extension record looks like this:
The application executes the following schema change in response:
CREATE TABLE Customer_Purchases(
Customer_id INT NOT NULL,
Purchases_id INT NOT NULL,
Purchases_Value INT (11),
PRIMARY KEY (customer_id, purchases_id),
FOREIGN KEY (customer_id)
REFERENCES Customer (customer_id)
);
Thus, the Customer_Purchases table associates a set of Purchases values with the Customer record.
Scalability Issues
Record Length Limits and Views
Databases typically limit the size of a single record. Implementations deal with this by putting all the extension fields in a separate table joined back to the main table. If necessary, a view can be created to maintain the illusion of a single table:
-- this table is not extensible:
CREATE TABLE Customer_Base (
Customer_id INT NOT NULL PRIMARY KEY,
[OTHER FIELDS GO HERE]
);
-- this table is extensible
CREATE TABLE Customer_Ext (
Customer_id INT NOT NULL PRIMARY KEY,
);
-- add view
CREATE VIEW Customer AS
SELECT CB.*, CX.*
FROM Customer_Base CB JOIN Customer_Ext CX
ON CB.customer_id = CX.customer_id
The view is mainly there to hide the details of the customer schema from report writers.
Indexes
It is generally not a good idea to allow users to easily create indexes on the single-valued schema extension columns. Indexes impose overhead and should only be added to extension fields after it is determined that the index will result in a speedup that justifies the index maintenance overhead.
Flexibility Requirements
In CRM applications, implementing organizations need to extend the customer data model with business-specific information. The data model extensions consist of adding single-valued and/or multiple-valued properties to the customer data record.
- The data model extensions must be efficient. The customer data tables typically have tens of thousands to hundreds of thousands of records in a business-to-business setting, and millions to tens of millions of records in a business-to-consumer setting.
- The data model extensions must facilitate efficient query and join processing in the database.
- The data model extensions must not prevent the vendor from easily upgrading the implementation in the field.
- The data model extensions must allow the vendor to ship a single binary code image that can be run in all customer implementations.
General Approach
Vendors typically use a metadata-driven approach:
- Data model extensions are limited to certain tables and are described with schema extension tables.
- The customer of the application can extend the schema by describing the schema extension in a UI, which saves records in the schema extension tables.
- Once the customer has finished designing the schema extension, the application extends the schema by adding columns to the extensible tables (for single-valued properties) or by creating new sub-tables (for multi-valued properties).
The implementing organization wishes to add a "favorite color" field to their customer records. The extension table has the following schema:
Extension Table Schema:
| COLUMN NAME | COLUMN TYPE |
| Table_name | Varchar |
| Prop_name | Varchar |
| Prop_type | Varchar |
| Prop_length | Integer |
| Prop_precision | Integer |
| Prop_singlevalued | Boolean |
Through a UI, the user creates the following record:
| COLUMN NAME | COLUMN VALUE |
| Table_name | Customer |
| Prop_name | Favorite_Color |
| Prop_type | Varchar |
| Prop_length | 25 |
| Prop_precision | Null |
| Prop_singlevalued | True |
When the user is satisfied (ie when the user hits a button), the application executes the schema change by issuing the following SQL statement:
ALTER TABLE Customer
ADD COLUMN Favorite_Color varchar(25);
Notes:
The Column_precision column will only be used for NUMERIC fields.
Extension columns must typically be NULL-able or the user must provide a default value for the new column.
Example: Multi-Valued Schema Extension
The implementing organization wishes to associate a list of purchased products with a customer record. The schema extension record looks like this:
| COLUMN NAME | COLUMN VALUE |
| Table_name | Customer |
| Prop_name | Purchases |
| Prop_type | Integer |
| Prop_length | 11 (or NULL) |
| Prop_precision | Null |
| Prop_singlevalued | False |
The application executes the following schema change in response:
CREATE TABLE Customer_Purchases(
Customer_id INT NOT NULL,
Purchases_id INT NOT NULL,
Purchases_Value INT (11),
PRIMARY KEY (customer_id, purchases_id),
FOREIGN KEY (customer_id)
REFERENCES Customer (customer_id)
);
Thus, the Customer_Purchases table associates a set of Purchases values with the Customer record.
Scalability Issues
Record Length Limits and Views
Databases typically limit the size of a single record. Implementations deal with this by putting all the extension fields in a separate table joined back to the main table. If necessary, a view can be created to maintain the illusion of a single table:
-- this table is not extensible:
CREATE TABLE Customer_Base (
Customer_id INT NOT NULL PRIMARY KEY,
[OTHER FIELDS GO HERE]
);
-- this table is extensible
CREATE TABLE Customer_Ext (
Customer_id INT NOT NULL PRIMARY KEY,
);
-- add view
CREATE VIEW Customer AS
SELECT CB.*, CX.*
FROM Customer_Base CB JOIN Customer_Ext CX
ON CB.customer_id = CX.customer_id
The view is mainly there to hide the details of the customer schema from report writers.
Indexes
It is generally not a good idea to allow users to easily create indexes on the single-valued schema extension columns. Indexes impose overhead and should only be added to extension fields after it is determined that the index will result in a speedup that justifies the index maintenance overhead.
Subscribe to:
Posts (Atom)
Posts
