One of the hallmarks of a great entrepreneur is knowing what you suck at. I suck at plenty of things – Paul Berberian’s blog The Name Game reminded me of one of them – naming things.
I was an investor in Paul’s last company – Raindance Communications – which went through five names to get there (Intellistat Media Research, Vstream, Evoke, Evoke Software, and finally Raindance Communications.) At some point I suggested we change the name to Ekove (read Paul’s story to learn why) but I was over-ruled – or rather, ignored. Paul ends his story with the line "My Advice – don’t do what I did" which should always be an enticement to read it.
My legacy of names for companies is long and troubled. It starts back at the beginning with the name of my first real company – Feld Technologies. Very creative. My dad was proud of me, but I learned rule #7341 – don’t name your company after yourself.
After moving to Boulder, I co-founded a company with Andrew Currie and Brian Makare. The business created the first known (at least to me) email service providers. At the time (1995) none of us knew what an email service provider was. We struggled to name the company. Over beers one night I asked "so – what do we do?" One of Andrew or Brian (I can’t remember) annoyingly looked over at me and said "We publish email." Hence – the name of the company – Email Publishing.
Another company that I helped start at the time was an attempt to create one of the early consolidated web hosting companies. At the time there were lots of companies doing web hosting with loads of creative names that typically included the words "web" or "communication" or "network" somewhere in their names. We named our business "Web Hosting Organization" and then shortened it to WHO, which caused much amusement (and confusion) in the ensuing legal documents we used to acquire other companies.
Around 1999 I gave up naming things. I realized that virtually every company I invested in was going through name changes and the marketing people were gleefully spending investor money "rebranding." I put this in the "what a fucking waste" category and started being more aggressive about my current mantra – "pick a name and stick to it, but please don’t ask me for my opinion on it."
Oh – and the name of this blog fits in that category also. Feld Thoughts? C’mon… But I’m not changing it.
Every day I get inbound emails from entrepreneurs looking for funding. I triage these quickly as I can usually tell within a couple of minutes of looking at whatever is attached (executive summary, overview, intro powerpoint) whether or not it’s in an area that I’m interested in investing in. Since my top level filter is "theme" it’s easy to make a quick call. If you’ve ever sent me something, hopefully you’ve gotten a quick response.
Most of the exchanges I have are generic and aren’t focused on me. Sometimes they are. Over the weekend, I had one that I think is an ideal example of how to get my attention.
It started with an email from Nick Napp of Disruptor Monkey. I remembered Nick and Disruptor Monkey from a previous referral from Square 1 Bank, but I didn’t remember where our conversation went (or didn’t go.) Nick’s email started off with the Subject line "Some thoughts re: Exchange server" and continued with:
Your recent post (Where Is Microsoft In This Party?) rang a few bells over here in Monkey land. Since you are well down the road drinking the kind of coolaid we enjoy, I’d like to share some additional thoughts with you. You are quite right that there is magic in the Exchange data – far more data than just email messages. There’s social network data, implied definitions of individual/personal relevancy and a huge collection of exploitable meta-data.
There’s more which was equally relevant, personalized to what I was thinking (and blogging) about, and simple to process (e.g. a handful of short, clear paragraphs.)
I responded with a quick "So – er – um – when do I get to play with something?" to see how real this was. Nick responded with an awesome video demonstration teaser that was customized for me. There are lots of great attributes of the video including:
Under three minutes and I get that what Disruptor Monkey is doing is interesting to me.
Now, I don’t know if I want to fund Nick’s company, but I definitely want to spend more time with him.
Plus they’ve got a bitchin logo.
I just went upstairs and taught the folks at Lijit how to make money on the Internet. They are all now proud and happy recipients of a bunch of pennies, nickels, dimes, and quarters. Hopefully they’ll remember to share the money with their publishers (and to steal underpants.)
It’s a lot of fun being in the same office building as folks we are investors in, although our previously quiet bathroom has been overrun by Me.dium people. I missed that when we moved to downtown Boulder from our old office that we shared with Return Path and StillSecure. Even if they have a giant turkey in their office.
The notion of “data vs. facts” made its way into several conversations today. I was at an interesting lunch today where we rolled around the in the idea of the different between them and then I had a call with an old friend on my way back to the office where he asked me a series of questions about my view of “fact based organizations” and decision making in startups.
I often say to people, “please recognize that I am just providing data – it’s up to you to decide what to do with it.” I also love the quote “the plural of anecdote is not data.” Without devolving into an analysis of the classic business school data -> information -> knowledge hierarchy, there can be a huge difference between data and facts, especially in an entrepreneurial context.
Entrepreneurs get data continually from all directions. One of the greatest providers of data are VCs and board members. A gigantic mistake that many entrepreneurs make is to interpret the data as facts. Many VCs deliver data in a very self-unaware away – basically as assertions of truth (which I’ll call “facts” even though I know the definition can be murky.) Unfortunately, the data that drives these facts are often invalid resulting in an invalid fact. If the entrepreneur doesn’t view the fact as data, he will immediately build conclusions on a bad (fact free) foundation. Blech.
Rather than train all the VCs in the world to deliver their data differently (and – more importantly – help them understand that data <> fact), it’s better for the entrepreneurs in the world to make sure they are sorting between data and fact correctly.
This goes both ways (e.g. the VCs aren’t the only guilty ones here.) As I drove home tonight, I pondered my end of day wrap up drink with an entrepreneur (who I really enjoy and respect) who spent the day with some of the TechStars companies. I disagreed with some of the assertions he made about several of the companies he’d met with today and the data he delivered to them. I expect he presented them very strongly (that’s his personality) and the entrepreneurs on the receiving end likely interpreted his assertions as fact, when they were only data. Hopefully upon reflection (or maybe reading this blog post) they’ll realize he was merely giving them data.
They should also remember that the plural of anecdote is not data. And – just to make it complicated, it might be the case that his data is fact, but you have to determine that for yourself. Finally, please remember that this blog is merely data.
You hear a lot about successful companies on most VC blogs. It’s a lot easier to talk about success than it is to talk about failure.
Several weeks ago, The Enthusiast Group (a company I have an angel investment in) decided to call it a day. They are in the process of selling off their properties (such as YourRunning, YourMTB, YourCycling, YourClimbing, and YourHorseSports.) If you have any interest in them, give them a shout.
Derek Scruggs – the co-founder – has a very thoughtful interview up on ColoradoStartups describing the experience and some of the lessons that he learned.
I’m proud of Derek and his partner Steve Outing – both for their efforts in starting The Enthusiast Group as well as for having the courage to call the ball when they realized things weren’t working.
I just caught a post my dad wrote today titled Birth Of An Entrepreneur: Brad Feld. Totally unexpected – it made me smile a big smile. My dad knows me well, remembers my antics from when I was a kid better than anyone (except maybe my mom and my brother), and tells great stories. Love ya dad. Thanks for making me. And thanks for investing that extra $1800 in an Apple II in 1978 – it has paid off well for both of us!
I received several questions in response to my post titled The Purpose of Numbers on a Y Axis and my followup post titled The Lack of Numbers of Y Axis Doesn’t Disqualify You. One of the questions prompted a rant in my brain that often spills out of my mouth when I’m on the receiving end of an early stage pitch.
The question is: “what kind of numbers would actually get your attention on a revenue chart for the first 12 months of business (or would income / cash flow be a better measure?)” Before I answer the question, I want to add an explicit qualifier – this answer applies to early stage software / Internet startups – think a few people, an idea, and maybe a prototype.
The answer is – none. I’ve seen around 4,387,215 financial models for startups. I’ve invested in over 100 companies. As far as I can remember, not a single revenue model was anywhere close to accurate in the first 24 months, other than the ones that said there would be $0 revenue.
Now – I invest in software / Internet companies – the vast majority of which don’t make any money in the first year or two. But – the principle scales beyond year 1. I can’t remember a company that I have been involved with that had an accurate view of its revenue dynamics until at least the third year. The vast majority of companies were well below their initial expectations (which isn’t necessarily bad); a few demolished their expectations (on the upside.) In either case, the conclusion is the same: Your Revenue Forecast Is Wrong.
I’m not suggesting that the right answer to the question posed above is “don’t bother with a financial model.” Rather, I’m suggesting that your financial model is going to be incorrect and a credible early stage investor is going to know that before you sit down with him. It’s actually a good test – if your potential investor immediately digs into your financial model before understanding how your actual business works it might be a good signal to you that he doesn’t understand how a startup software company evolves.
As a result of my assertion that your revenue forecast is wrong, I’m less concerned about the absolute numbers and more interested in understanding how you think about them. I’m also very interested in how you see the expense side of the equation growing over time since that is the piece you ultimately have control over. However, I don’t want to spend any time on this until I understand what you are trying to accomplish with the business and whether or not it is in an area that I believe I’d be interested in investing in. Especially because whatever you have forecast and are presenting to me will almost certainly be wrong, although not necessarily invalid.
Before I call it quits on the damp Sunday night in Colorado, I thought I’d leave you with a thought that came up in a conversation last week: “Know What You Suck At.”
While my We Suck Less meme has had its day in the sun, I don’t hear people talk enough about what they aren’t good at. First meetings are peppered with “I’ve done this”, “I’ve done that”, “I’m good at this”, “I’m experienced at that.” However, rarely does someone volunteer that they suck at something. I’m often amused by the pregnant pause that comes after I ask “so – tell me something that you are lousy at.”
I have a long list. They include things like:
I’ve also applied this to my venture capital investing. There’s a wide swath of categories of companies that I’ve failed at, including ones that require significant capex investment or are fundamentally telecom oriented, pure services companies, retail oriented companies (e.g. dotcom spinoffs), and things that play only into vertical markets. This doesn’t mean that these aren’t good investments or don’t have the potential to be successful – they are just things that I should stay away from.
Oh – and restaurants. I’ve never been very good at investing in restaurants. After a couple of lousy experiences, I have no aspiration to be good at it. I’m excellent at eating at restaurants, but terrible at investing in them.
I use my “what do I suck at” filter to guide a lot of my behavior. Rather than try to get better at some of these things (like public market investing), I’ve just accepted that I’m not good at it and I should figure out a way to have other people do it for me (e.g. I do broad market allocations but then have individual managers handle specific public market investing for me – and I happily pay them to do what they love to do – and what I suck at.) This applies at a macro level and helps shape my investing themes, how I spend my time, and where I travel on vacation.
Like the adage that you only really learn when you fail, I think knowing what you suck at is more useful than knowing what you are great at. You have two choices when you identify what you aren’t any good at – you can either work on it and get better, or you can avoid it / structure around it. Either is valid, but unless you know what it is, it’ll limit your experience on the planet.
I went for a mountain run yesterday with a long time friend of mine. In between panting, we spent about a half an hour discussing the differences between a CTO and a VP Engineering. There are a lot of different definitions that vary by size of company, style of the CEO (technical CEO vs. sales-oriented CEO), geography, and the founders (are any of them either the CTO or VP Eng) – after we got into the conversation we decided to focus on what it meant in a startup.
As we went through a number of examples from companies I had been involved in, a few consistent themes emerged. The biggest was that one person could play the role of both CTO and VP Eng until a company got up to around 20 people. Once an organization has more than 20 people, there needed to be a separate CTO and VP Eng. In cases where there was only one person trying to do both roles, there were three cases:
When I thought about which was easier to hire at 20 people, it’s clear that the VP Eng is a much easier hire to find and integrate into the business. So – the natural default of the early CTO into the VP Eng role wasn’t very satisfying.
This led us to the definition of CTO and VP Eng that I was working with. I started with VP Eng and thought of some of the great ones I’ve worked with. They are process / management gods (and goddesses) – totally focused on building and shipping products. Most of them are “medium technical” – strong enough to stand up to the engineers they manage, but not necessarily the best coders on the team. A few were rock star developers; a few were non-programmers (although I think that’s more like me saying I can’t program – where the key word that is missing is “anymore” which implies I could if I didn’t have other things to do.)
In contrast, the great CTO’s usually can’t manage their way out of a paper bag, but have huge vision, the ability to pull an all-nighter and crank out a rough prototype of the thing they are thinking about, have the unique ability to translate complex / abstract thoughts into simple English that a non-technical end-user can understand, and a willingness (or even desire) to get up in front of 1,000 people and talk about the latest greatest thing they are working on / thinking about. They are also perfectly happy to work collaboratively with the VP Eng while leaving the engineering team completely alone.
Now – all of this is from the frame of reference of a startup or emerging company. My experience with the Feld Group (prior to the EDS acquisition) helped me understand this from a Fortune 1000 perspective, which is a radically different one that often includes multiple CTOs and VP Engs in an organization along with things called CDOs (Chief Development Officers), CPOs (Chief Product Officers), and CA’s (Chief Architects.) I never managed to find an R2D2 or a C3PO however.