4 years ago
image via Wikipedia
Earlier today in Palo Alto, I met with an old friend who back in the 1990s, built a number of very successful consumer products companies that combined hardware and software. (I’m not sure he wants me to say his name publicly).
We talked about a number of things like his next company and things he wants to build. We also talked about his frustration with VCs and entrepreneurs these days. His view is that we are too afraid of technology risk when creating & funding startups.
I’m probably being too kind here - his belief was that VCs only want to deal with market and business model risk vs technology risk these days. We don’t’ build products that are hard to build or might not be possible to build. As a result entrepreneurs are working on those types of things. The problem in his opinion: ideas get smaller, innovation levels off and me-too thinking sets in as yet another “myspace on steroids” gets funded.
He summed up his feeling by asking me “Where’s the ‘silicon’ in Silicon Valley” ?
I’ve been thinking about our discussion and a few thoughts come to mind:
1 - I do like consumer web services that take advantage of open source, open api’s, and hosted infrastructure and focus on scale. We have several startups in our portfolio that got going with a modest amount of capital. It’s a very nice model where entrepreneurs can start with little dilution (since they are raising little money) and VCs don’t have to invest significant capital upfront to see market traction.
This is a powerful model and I hope to make more investments with this approach.
2 - Just because a company is building something with little capital doesn’t mean it’s a little idea. Twitter started with a modest amount of capital and a few engineers. Boxee started with angel financing and a small team. I think you would agree that these are not small ideas.
3 - I do believe some investors are still comfortable taking technology risk. It’s very apparent in cleantech and biotech. We are taking technology risk in a number of our investments as well. For example, when we first invested in Kateeva, Verivue and Bug Labs it wasn’t a slam dunk that these products would actually work as originally conceived by the founders. Those companies require much great capital to design and build their products. And I know a number of VCs that are also taking technology risk in their investments.
4 - But my friend is right. We are building less hardware companies. We are seeing more companies that can build things in a matter of months not years. We are seeing programs like YC and TechStars help start companies with less than $10k. Those programs are growing and I don’t see them slowing down. That’s a good thing.
It’s true, the term “Silicon Valley” doesn’t mean what it used to. SV has evolved from its roots.
But we don’t have to build hardware to build stuff that matters.
At the same time I’m definitely keeping this conversation in my mind as I meet startups with significant technology risk.
I didn’t rule out those companies before and I’m not going to in the future either.
Here’s to the crazy ones!
4 years ago
People on the business side of internet software, constantly bemoan their inability to code. I’ve been guilty at times of the frequent refrain, “My kingdom for the ability to code.” However, I’ve found over the past year that the emergence of APIs coupled with eLance (or oDesk or one of the other contractor platforms) have made this expression of exasperation largely hot air.
For $500 and four weeks of late night emails to eLance developers, you can basically spec and build simple, rough apps that knit or build upon open APIs to create things that are interesting and potentially valuable. To be clear, you can’t build complicated apps or the next Salesforce.com on this kind of shoestring, but you can achieve the kind of learning, vetting, and experimentation that is left undone if you don’t.
I call this process Hackable Business Development. If you’re interested in a platform or service from an intellectual, career, or partnership prospective, you simply must build on it. APIs are such a vital part of web business growth and extension, that the API is almost more important than the front-end. So if you are really interested in a web site, the only way to understand its functionality and potential is to hack on its API. An API is in many ways the equivalent of a living breathing business plan - replete with the company’s view of its place in a highly competitive, fragmented world of web services.
I consider this the modern day equivalent of reading up on a business and sketching out your thoughts.
When I was interviewing to work at Majestic Research in 2003, I was asked to write up a few pages of ideas to grow the business. I did this, but I’m fond of saying “ideas are like water”; they’re everywhere and they flow. How much more impressive and educational would it have been for me to get a raw feed of API data from Majestic and model it. I hadn’t yet discovered the Hacking Business Development model, and I was lucky enough to get the job at Majestic, but it would have been so much more valuable for me to have hacked for them.
API documentation is basically written in prose, so that’s always a good place to start. Instead of taking a novel to bed tonight, take some API documentation.
Interesting ideas. I think even engineers could start using oDesk. I’ve written enough twitter apps to know a framework others should work in. It would make their job easy, and save me time.
I think it was Fake from Flickr who said APIs are “Biz Dev 2.0”. It’s so awesome.
Having _made_ one for Tipjoy, my take aways are basically that you should make an API first - then build your service on top of it. Eat your own dog food. Also, there is a good argument that if you make good coverage in your API, your data representation will be better.
People don’t talk about this specific issue a lot - but they do talk about it indirectly. When a company needs to do a redesign, the representation of the data is what matters most. If you change the data, you need to evolve what is already there, and swap out the new framework quickly. Also, the speed at which you build new tools is almost always related to the quality of your data representation. If you’ve built something good, new tools can build on top of it with little friction from data representation evolution.
I LOVE this.