http://unhub.com/dharmeshparikh
Comments (View)

Where is the “silicon” in Silicon Valley ?

bijan:

Looking west over northern San Jose (downtown ...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!

Comments (View)
giantrobotlasers:

I’ve made a little utility to log tweets and searches on tweets forever. No paging or time horizons. This is for personal use, but clearly can turn into some kind of subscription based product.
Have you ever tried to find an old tweet of your own or a friend? Have you ever tried to create a measure of usage stats based on tweets, only to find the search API only goes back 1500 tweets?
If so, you might like this. So help me test it. Give me some (reasonable) search terms so I can test this more.
It ran last night on a home machine, and just started in a deployed configuration. The service as is will likely just accumulate functionality to expose to other consumer facing sites I make via an API. Yes, I made the API first.

giantrobotlasers:

I’ve made a little utility to log tweets and searches on tweets forever. No paging or time horizons. This is for personal use, but clearly can turn into some kind of subscription based product.

Have you ever tried to find an old tweet of your own or a friend? Have you ever tried to create a measure of usage stats based on tweets, only to find the search API only goes back 1500 tweets?

If so, you might like this. So help me test it. Give me some (reasonable) search terms so I can test this more.

It ran last night on a home machine, and just started in a deployed configuration. The service as is will likely just accumulate functionality to expose to other consumer facing sites I make via an API. Yes, I made the API first.


Comments (View)
black-and-white:

(via cupcakemugshot)
waiting for papa to come home…. *im hungry already*

black-and-white:

(via cupcakemugshot)

waiting for papa to come home…. *im hungry already*

Comments (View)
Never regret. If it’s good, it’s wonderful. If it’s bad, it’s experience.
— Victoria Holt (via brokenmachine) (via quote-book) (via hiten)
Comments (View)
hiten:

cyan1975:

Who is lining Google’s pockets today?
(via mary1in)

hiten:

cyan1975:

Who is lining Google’s pockets today?

(via mary1in)


Comments (View)

Hackable Business Development

hiten:

joeconyers:

giantrobotlasers:

jonsteinberg:

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.

Comments (View)
Comments (View)
cyan1975:

The evolution of Nintendo’s game controller.
(via solipsism & marypoppinswasajunkie)

cyan1975:

The evolution of Nintendo’s game controller.

(via solipsism & marypoppinswasajunkie)


Comments (View)
cyan1975:

Types of Engagement
(via mary1in & dataviz)

cyan1975:

Types of Engagement

(via mary1in & dataviz)


Comments (View)