gtzi's shared items in Google Reader

As the 4th Call for Proposals Ends, the Real Action Begins

2010-12-01T13:59:00Z

The call for proposals for our fourth round of operations was closed this midnight. First of all we would like to extend a warm "thank you" to all the entrepreneurs who entrusted us with their applications and the responsibility to review them. We cannot help being excited by the volume and quality of the proposals that came in and we are now hard at work to make great start-ups happen.

Here are a few more details and demographics on the applications received, next to the steps and dates to the selection process to follow.

The submissions span 24 countries, mostly Europe, but also India, Brazil and the States. Applicants from Greece stood for a diminishing 50% of the total, while the European map below pictures the geographical distribution of the applicants in more detail.

The next graph provides a closer look at the time distribution of the applications received. No surprises here, almost half of the applicants submitted in the last couple of days before the deadline.

Another interesting perspective regards the skills spectrum, as it was reported by the applicants themselves. The graph reports a wide blend of capacities across the founders, both in technical and business issues.

What now follows is the selection process, which takes place in three stages. First, selected executive board members and advisors will review each one of the applications received. The full reviews and feedback collected will be returned back to the applicants by Friday December 10, next to the decision to proceed to the next stage or not.

Successful applicants will then be required to submit a full business plan, before getting interviewed from our full executive board. Interviews will take place on Monday, December 20. Finally, the best teams will get to present in front of our executive board, investors and advisors on Saturday January 8, 2011, with the selected teams being announced right after.

We are enthusiastic for this round and confident that, with such a great pool of entrepreneurs and partners, fantastic start-ups are in the making; stay tuned for the updates.

Investing and Participating in Social Services

2010-10-31T12:51:45Z

Shared by gtzi
"Matt Mullenweg, who in 2005 insisted that I blog as a condition to investing in the company he was starting"

Chris Dixon had a characteristically smart blog post recently where he states that he can’t take Investors or commentators seriously on the topic of social services when they themselves don’t use social services.
Chris owes it to his cofounder Katerina Fake that he became an avid blogger and tweeter. And I owe my own entry into social services to WordPress creator Matt Mullenweg, who in 2005 insisted that I blog as a condition to investing in the company he was starting,
Automattic.
I wholeheartedly agree with Dixon that to be a good social investor requires that you participate in them. But a caveat: while using social services is critical to understanding the medium, relying on one’s personal taste in social services to shape an investment strategy is a recipe for disaster. It makes a helluva lot more sense instead to look to user metrics and behavior, even if limited, than to rely on a data point of one.

Tips to get seed funding and support 3/6 - Product

2010-10-29T12:17:00Z

We talked about the idea and the team, now it’s time to discuss about how the idea will be shaped into a product and hopefully turn into a successful business. Roughly speaking, there are three aspects that you need to consider when applying for support from the Openfund and similar constructs: innovation, revenue and market.

Innovation

First of all, what you’re proposing has to have at least a small amount of innovation. It can be at its core concept, at its technical basis, at its design or just at a key business operation. And although there’s a school of thought saying that copycats can be profitable and perhaps better than the original, everyone wants their startups to be exceptionally successful - not just very profitable. And this can only happen if either something entirely new and disruptive is created or at least if a fresh perspective is implemented at an existing idea. So, yes, iterating on an old idea can mean success - but iteration works only if it achieves serious improvements, i.e. innovating.

Innovation can also mean applying ideas working well in one industry to another industry in need of something new. For example, suggesting relevant and customised content - if applied successfully - to the music business could mean something big. Mass deployment of e-commerce sites may not be innovative - but combining it with social shopping can make a difference. The point is really to try something novel - and that can include a new way to combine old ideas. Just make sure that this supposed new combination has indeed not really been tried before.

Revenue

When it comes to revenue, it’s only obvious that you have to have a clear, well-defined and well-thought out method of how you plan to generate some income, as soon as possible. It’s not necessary for it to have been tried before just to prove that it works, but it has to be based on sound assumptions. If you’re able to make valid quantitative estimates about your business model then you’re on the right track - and you should share those both to confirm them and to convince us. If you’re at a loss of how to do this, try coming up with sensible numbers for three scenarios - the best, the worst and a middle case. Just going through his exercise of setting upper and lower limits is eye-opening - for both you and us.

Needless to say, the more viable and well-thought-out revenue streams you include in your business model the better. Usually at least one will in practice turn out to be not viable or as feasible or scalable as expected so you will have to fall back on the others. You can check out here a quick list of the broad categories of revenue streams to get you started - although probably some apply less than others to startups. On the other hand, don’t include all the streams you can think of just to be sure something will work. More streams mean more features - you simply can’t implement them all! One way to balance these approaches is to create something simple that can be inherently used to generate profit by smartly and flexibly tapping on many revenue streams using the same limited feature set. Another is to plan to tap on different revenue streams depending on the stages of your startup - starting with the easier to implement and gain traction on. In any case, you should support your qualitative descriptions with estimates and ballpark figures. It’s essential you’ve done it for your own use - so why not share it?

No post on revenue streams would be complete if it didn’t include a special mention on ads. You should use this as a revenue stream only if a) you’ve already included a few other solid streams, so ads only have a complementary role and b) if you include an as complete as possible estimate of the revenues expected. Ads scale practically only for Google - the rest of us have to be really smart, specific or targeted to make them work.

Market

Finally, your product should have certain characteristics when it comes to the market it aims at. A quick and dirty way of making sure that there is a market to begin with is to have a short and concise answer to the ‘What’s the problem my startup is solving?’ question. As already mentioned, if you can’t fit an answer for that in a sentence or two, your project probably needs some cohesion or even an overhaul. Other than that, you should be able to identify major groups of people that will be willing to use your business - and probably a few subgroups too. It’s easy to fall in the enticing trap of ‘the entire internet’ but this is usually an indication you haven’t thought things through: you can and you should try to aim for specific groups split by demographics, industry, location or other means. Once decided on that, you can make estimates on market size which can make the difference between an interesting and an insignificant investment.

Also make sure to factor in your approach not just the end user and your company but also any intermediaries, middle men, government bodies, legal requirements and other relevant considerations. Such issues could pose problems in entering the market (additional bureaucracy, less revenue, etc) but they also can be significant allies - for example tapping the developer community to your advantage, outsourcing tasks to specialised agencies, etc. Remember, your target market works as the amplifier or the sink hole of a start-up’s endeavors; make sure you have made a sustainable and wise pick.

Next week we talk competition!

Apple as mobile phone vendor: First in profit, second in sales and fourth in units

2010-10-30T17:36:18Z

Change in top mobile phone vendor market, sales and profit shares rank over time:

A Plea to Amazon: Fix Mechanical Turk!

2010-10-21T05:56:00Z

It is now almost four years since I started experimenting with Mechanical Turk. Over these years I have been a great evangelist of the idea.

But as Mechanical Turk becomes mainstream, it is now time for the service to get the basic stuff right. The last few weeks I found myself repeating the same things again and again, so I realized that it is now time to write these things down...

Mechanical Turk, It is Time to Grow Up

The beta testing is over. If the platform wants to succeed, it needs to evolve. Many people want to build on top of MTurk, and the foundations are lacking important structural elements.

Since the beginning of September, I have met with at least 15 different startups describing their ideas and their problems in using and leveraging Mechanical Turk. And hearing their stories, one after the other, I realized: Every single requester has the same problems:

Scaling up
Managing the complex API
Managing execution time
Ensuring quality

These problems were identified years ago. And the problems were never addressed.

The current status quo simply cannot continue. It is not good for the requesters, it is not good for the workers, it is not good for even completing the tasks. Amazon, pay attention. These are not just feature requests. These are fundamental requirements for any marketplace to function.

Amazon likes to present the hands-off approach to Mechanical Turk as a strategic choice: In the same way that EC2, S3, and many other web services are targeted to developers, in the same way Mechanical Turk is a neutral clearinghouse of labor. It provides just the ability to match requesters and workers. Everything else is the responsibility of the two consenting parties.

Too bad that this hands-off approach cannot work for a marketplace. The badly needed aspects can be easily summarized in four bullet points:

Below, I discuss these topics in more detail.

Requesters Need: A Better Interface To Post Tasks

A major task of a marketplace is to reduce overhead, friction, transaction costs, and search costs. The faster and easier it is to transact, the better the market. And MTurk fails miserably on that aspect.

I find it amazing that the last major change on Mechanical Turk for the requesters was the introduction of a UI to submit batch tasks. This was back in the summer of 2008. George Bush was the president, Lehman Brothers was an investment bank, Greece had one of the highest growing GDP's in Europe, Facebook had less than 100 million users, and Twitter was still a novelty. It would take 8 more months for FourSquare to launch.

It is high time to make it easier to requesters to post tasks. It is ridiculous to call the command-line tools user-friendly!

What is the benefit of having access to a workforce for microtasks, if a requester needs to hire a full time developer (costing at least $60K) just to deal with all the complexities? How many microtasks someone should execute to recoup the cost of development?

If every requester, in order to get good results, needs to: (a) build a quality assurance system from scratch, (b) ensure proper allocation of qualifications, (c) learn to break tasks properly into a workflow, (d) stratify workers according to quality, (e) [whatever else...], then the barrier is just too high. Only very serious requesters will devote the necessary time and effort.

What is the expected outcome of this barrier? We expect to see a few big requesters and a long tail of small requesters that are posting tiny tasks. (Oh wait, this is the case already.) In other words: It is very difficult for small guys to grow.

Since we are talking about allowing easy posting of tasks: Amazon, please take a look at TurkIt. Buy it, copy it, do whatever, but please allow easy implementation of such workflows in the market. Very few requesters have simple, one-pass tasks. Most requesters want to have crowdsourced workflows. Give them the tools to do so easily.

MTurk is shooting themselves in the foot by encouraging requesters to build their own interfaces and own workflow systems from scratch! For many many HITs, the only way to have a decent interface is to build it yourself in an iframe. What is the problem with iframe? Doing that, MTurk makes it extremely easy for the requester to switch labor channels. The requester who has build an iframe-powered HIT can easily get non-Turk workers to work on these HITs. (Hint: just use different workerid's for other labor channels and get the other workers to visit directly the iframe html page to complete the task.) Yes, it is good for the requester in the long term not to be locked in, but I guess all requesters would be happier if they did not have to build the app from scratch.

Requesters Need: A True Reputation System for Workers

My other big complaint. The current reputation system on Mechanical Turk is simply bad. "Number of completed HITs" and "approval rate" are easy to game.

Requesters need a better reputation profile for workers. Why? A market without a reputation mechanism turns quickly into a market for lemons: When requesters cannot differentiate easily good from bad workers, they tend to assume that every worker is bad. This results in good workers getting paid the same amount as the bad ones. With so low wages, good workers leave the market. At the end, the only Turkers that remain in the market are the bad ones (or the crazy good ones willing to work for the same payment as the bad workers.)

This in turn requires the same task to be completed from many workers, way too many times to ensure quality. I am not against redundancy! (Quite the opposite!) But it should be a technique for taking moderate quality input to generate high quality output. A technique for capturing diverse points of view for the same HIT. Repeated labeling should NOT be the primary weapon against spam.

The lack of a strong reputation system hurts everyone, and hurts the marketplace! Does Amazon want to run a market for lemons? I am sure that the margins will not be high.

Here are a few suggestions on what a worker reputation mechanism should include.

Have more public qualification tests:Does the worker have the proper English writing skills? Can the worker proofread?Most marketplaces (eLance, oDesk, vWorker, Guru), allow participants to pass certification tests to signal their quality and knowledge in different areas. Same should happen on Turk. If Amazon does not want to build such tests, let requesters make their own qualification tests available to other requesters for a fee? Myself, I would pay to use the qualifications assigned by CastingWords and CrowdFlower. These requesters would serve as the certification authorities for MTurk, in the same way that universities certify abilities for the labor markets.
Keep track of working history: For which requester did the worker work in the past? How many HITs, for what payment? For how long? Long history of work with reputable requesters is a good sign. In the real world, working history matters. People list their work histories in their resumes. Why not on MTurk?
Allow rating of workers: What is the rating that the worker received for the submitted work? Please allow requesters to rate workers. We have it everywhere else. We rate films, books, electronics, we rate pretty much everything.
Disconnect payment from rating: Tying reputation to acceptance rate is simply wrong. Currently, we can either accept the work and pay, or reject the work and refuse to pay. This is just wrong. We do not rate restaurants based on how often the customers refused to pay for the food! I should not have to reject and not pay for the work, if the only thing that I want to say is that the quality was not perfect. Rejecting work should be an option reserved for spammers. It should never be used against honest workers that do not meet the expectations of the requester.
Separate HITs and ratings by type: What was the type of the submitted work? Transcription? Image tagging? Classification? Content generation? Twitter spam? Workers are not uniformly good in all types of tasks. Writing an article requires a very different set of skills from those required for transcription, which in turn are different than the skills for image tagging. Allow requesters to see the rating across these different categories. Almost as good as the public qualification tests.
And make all the above accessible from an API, for automatic hiring decisions.

It cannot be that hard to do the above! Amazon.com runs a huge marketplace with thousands of merchants, for years. The guys as Amazon know how to design, maintain, and protect a reputation system for a much bigger marketplace. How hard can it be to port it to Mechanical Turk?

(Amazon's response about the reputation system... )

In a recent meeting, I asked this same question: Why not having a real reputation system?

The MTurk representative defended the current setup, with the following argument:

On the Amazon.com marketplace, the (large number of) buyers can rate the (small number of) merchants, but not vice versa. So, the same thing happens on MTurk. The (large number of) workers can rate the (small number of) requesters using TurkerNation and TurkOpticon. So the opposite should not happen: requesters should not rate workers.

I felt that the answer made sense: two-sided reputation systems indeed have deficiencies. They often lead to mutual-admiration schemes, so such systems end up being easy to hack (not that the current system is too hard to beat.) So, I was satisfied with the given answer... For approximately 10 minutes! Then I realized: Humbug!

There is no need for a reputation system for product buyers on Amazon.com's marketplace! It is not like eBay, where a buyer can win the auction and never pay! The reputation of the buyer on Amazon.com is irrelevant. On Amazon, when a buyer buys a product, as long as the credit card payment clears, the reputation of the buyer simply does not matter. There is no uncertainty, and no need to know anything about the buyer.

Now let's compare the Amazon.com product marketplace with MTurk: The uncertainty on MTurk is about the workers (who are the ones selling services of uncertain quality). The requester is the buyer in the MTurk market. So, indeed, there should not be a need for a reputation system for requesters, but the workers should be rated.

And at that point, people will protest: Why do we have the Hall of Fame/Shame on Turker Nation, why do we have TurkOpticon? Does Panos consider these efforts irrelevant and pointless?

And here is my reply: The very fact that we have such systems means that there is something very wrong with the Mturk marketplace. I expand below.

Workers Need: A Trustworthiness Guarantee for Requesters

Amazon should really learn from its own marketplace on Amazon.com. Indeed, on Amazon.com, it is not possible to rate buyers. Amazon simply ensures that when a buyer buys a product online, the buyer pays the merchant. So, Amazon, as the marketplace owner, ensures the trustworthiness of at least one side of the market.

Unfortunately, MTurk does not really guarantee the trustworthiness of the requesters. Requesters are free to reject good work and not pay for work they get to keep. Requesters do not have to pay on time. In a sense, the requesters are serving as the slave masters. The only difference is that on MTurk the slaves can choose their master.

And so, Turker Nation and TurkOpticon were born for exactly this reason: To allow workers to learn more about their masters. To learn which requesters behave properly, which requesters abuse their power.

However, this generates a wrong dynamic in the market. Why? Let's see how things operate.

The Requester Initiation Process

When new requesters come to the market, they are treated with caution by the experienced, good workers. Legitimate workers will simply not complete many HITs of a new requester, until the workers know that the requester is legitimate, pays promptly, and does not reject work unfairly. Most of the good workers will complete just a few HITs of the newcomer, and then wait and observe how the requester behaves.

Now, try to be on the requester's side.

If the requester posts small batches, things may work well. A few good workers do a little bit of good work, and the results come back like magic. The requester is happy, pays, everyone is happy. The small requester will come back after a while, post another small batch, and so on. This process generates a large number of happy small requesters.

However, what happens when the newcomers post big batches of HITs? Legitimate workers will do a little bit of work and then wait and see. Nobody wants to risk a mass rejection, which can be lethal for the reputation of the worker. Given the above, who are the workers who will be willing to work on HITs of the new, unproven requester? You guessed right: Spammers and inexperienced workers. Result? The requester gets low quality results, gets disappointed and wonders what went wrong.

In the best case, the new requesters will seek expert help, (if they can afford it). In the worst case, the new requesters leave the market and use more conventional solutions.

At this point, it should be clear that just having a subjective reputation system for requesters is simply not enough. We need a trustworthiness guarantee for the requesters. Workers should not be afraid of working for a particular requester.

Online merchant in the Amazon marketplace do not need to check the reputation of the people the sell to. Amazon ensures that the byers are legitimate and not fraudsters. Can you imagine if every seller on Amazon had to check the credit score and the trustworthiness of every buyer they sell to? What did you say? It would be a disaster? That people would only sell to a few selected buyers? Well, witness the equivalent disaster on Mechanical Turk.

So, what is needed for the requesters? Since the requester is essentially the "buyer", there is no need to have subjective ratings. The worker should see a set of objective characteristics of the requester, and decide whether to pick a specific posted HIT or not. Here are a few things that are objective:

Show speed of payment: The requester payment already goes into an Amazon-controlled "escrow" account. The worker should know how fast the requester typically releases payment.
Show the rejection rate for the requester: Is a particular requesters litigious and reports frequently the work of the workers as spam?
Show the appeal rate for the requester: A particular requester may have high rejection rate just due to an attack from spammers. However, if the rejected workers appeal and win frequently, then there is something wrong with the requester.
Disallow the ability to reject work that is not spam: The requester should not be able to reject submitted work without paying. Rejection should be a last-resort mechanism, reserved only for obviously bad work. The worker should have the right to appeal (and potentially have the submitted work automatically reviewed by peers). This should take out a significant uncertainty in the market, allowing workers to be more confident to work with a new requester.
Show total volume of posted work: Workers want to know if the requester is going to come back to the market. Volume of posted work and the lifetime of the worker in the market are important characteristics: workers can use this information to decide whether it makes sense to invest the time to learn the tasks of the requester.
Make all the above accessible from an API: Let other people build worker-facing applications on top of MTurk.

So, a major role of a marketplace is to instill a sense of trust. Requesters should trust the workers to complete the work, and workers should not have to worry about unreasonable behavior of the workers. This minimizes the search costs associated with finding a trustworthy partner in the market.

Let's see the final part that is missing.

Workers Need: A Better User Interface

As mentioned earlier, beyond trust, the other important role of the market is to minimize as much as possible transaction overhead and search costs. The transacting parties should find each other as fast as possible, fulfill their goals, and move on. The marketplace should almost be invisible. In this market, where requesters post tasks and the tasks wait for the workers, it is important to make it as easy as possible for workers to find tasks the workers want to work on.

Current Problem: Unpredictable Completion Times

Unfortunately, currently the workers are highly restricted by the current interface, in their ability to find tasks. Workers cannot search for a requester, unless the requester put their name in the keywords. Also workers have no way to navigate and browse through the available tasks, to find things of interest.

At the end, workers end up using mainly two main sorting mechanisms: See the most recent HITs, or see the HITgroups with the most HITs. This means that workers use priority queues to pick the tasks to work on.

What is the result when tasks are being completed following priorities? The completion times of the tasks follow a power-law! (For details on the analysis, see the preprint of the XRDS report "Analyzing the Amazon Mechanical Turk Marketplace".) What is the implication? It is effectively impossible to predict the completion time of the posted tasks. For the current marketplace (with a power-law exponent a=1.5), the distribution cannot even be used to predict the average waiting time: the theoretical average is infinite, i.e., in practice the mean completion time is expected to increase continuously as we observe the market for longer periods of time.

The proposed solutions? So easy, so obvious solutions, that it even hurts to propose them:

Have a browsing system with tasks being posted under task categories. See for example, the main page for oDesk, where tasks are being posted under one or more categories. Is this really hard to do?
Improve the search engine. Seriously, how hard is it to include all the fields of a HIT into the search index? Ideally it would be better to have a faceted interface on top, but I would be happy to just see the basic things done right.
Use a recommender system to propose HITs to workers. For this suggestion, I have to credit ba site on the Internet, with some nifty functionality: it monitors your past buying and rating history, and then recommends products that you may enjoy. It is actually pretty nice and helped that online store to differentiate itself from its competitors. Trying to remember the name of the site... The recommendations look like that:

It would be a good idea to have something like that on the Amazon Mechanical Turk. Ah! I remembered! The name of the site with the nice recommendations is Amazon! Seriously. Amazon cannot have a good recommender system for its own market?

Competition waits

Repeat after me: A labor marketplace is not the same thing as a computing service. Even if everything is an API, the design of the market still matters.

It is too risky to assume that MTurk can simply a bare-bones clearinghouse for labor, in the same way that S3 can be a bare-bones provider of cloud storage. There is simply no sustainable advantage and no significant added value. Network effects are not strong (especially in the absence of reputation), and just clearing payments and dealing with Patriot Act and KYC is not a significant added value.

Other marketplaces already do that, build API's, and have better design as well. It will not be difficult to get to the micro segment of the crowdsourcing market, and it may happen much faster than Amazon expects. Imho, oDesk and eLance are moving towards the space by having strong APIs for worker management, and good reputation systems. Current MTurk requesters that create their HITs using iframes, can very easily hire eLance and oDesk workers instead of using MTurk.

The recent surge of microcrowdsourcing services indicates that there are many who believe that the position of MTurk in the market is ready to be challenged.

Is it worth trying to challenge MTurk? Luis von Ahn, looking at an earlier post of mine, tweeted:

MTurk is TINY (total market size is on the order of $1M/year): Doesn't seem like it's worth all the attention.

I will reply with a prior tweet of mine:

Mechanical Turk is for crowdsourcing what AltaVista was for search engines. We now wait to see who will be the Google.

So You Want to Work for a Startup? Part Two

2010-10-19T18:20:07Z

In my last post, I talked about a few early startup milestones that you, a prospective employee at a startup, should know about.

I covered the following:

Corporate vision defined
Initial product focus defined
Potential customers interviewed
First prototype built
Feedback from prototype incorporated

In this post, I’ll talk about the next few milestones any startup should be meeting, and, as a prospective employer, should be able to answer questions about. As before, I focus on a certain category of SaaS businesses, but the general principles apply broadly.

6. First trial customer

While the prototype is being built, the founders should be canvassing a trial customer. This trial customer could be different from the people that have been providing feedback on the prototype. Ask how long it took the team to find their first trial customer. A long time delta between prototype and trial indicates either an inability to ‘sell’ the idea, or a divergence from the actual market needs – both bad signs.

7. First customer with a working product

When a product first gets in the hands of the customers, more often than not, it’s ripped to shreds. Some of your fundamental assumptions about the target customer go out of the window. The technology just doesn’t work. There are way too many bugs or unplanned border conditions. This is normal. For this reason, the first customer with a product that ‘somewhat works’ might be different from the first trial customer, and this milestone might be hit months after the previous one. Look for humility and pragmatism in the founders – will they be able to go through this hump? Were they?

8. First planned iteration

At some point, the team will need to get into a ‘rhythm’. This is about when sprints/scheduled launches start making sense. Yes, the product does 10% of what it was intended to, and is massively buggy, but customers are able to get at least something out of it. Beware of startups that start planned iterations too early (eg in the prototype stage), or too late (eg when they have a lot of customers already using the product). The former will delay quick iterations during the rapid learning stage, while the latter will lead to massive stability issues and delay scaling up.

9. First paid customer

When the product reaches a certain feature/quality level, it will be possible to charge customers. Determining the actual pricing model for any service is a complicated matter – but every startup should be able to determine when it’s feasible to start charging customers for their services. If they are too early, the product will not be able to thrive as customers don’t perceive enough return on their investment. If they are too late, and not venture funded, it might mean the company will fold too early – and is an indication that they need better business development or sales talent.

Once these milestones are hit, the startup is a real business. However, whether it’s successful or not depends on how well they can scale up – both customer volume and happiness. These are milestones for the next post.

30% customer happiness milestone
70% customer happiness milestone
Partnerships
Revenue break-even
Profitability

Incidentally, I can now share who the mysterious Mr G was from the previous post – none other than Gursharan Singh. Gurshi – welcome to Vurve!

What do you think? Feedback welcome in the comments, or email us at contact@vurve.com. Want to join us for the ride (and find out what we’re actually up to)? Email us at jobs@vurve.com!

This post was written by Amit Kumar, Founder & CEO of Vurve , a True Ventures Portfolio Company.

"It's Too Early"

2010-10-19T17:16:44Z

Sometimes, early stage companies hear investors say that it’s “too early” for them to invest.

It’s a puzzling response when most VC’s are considered “early stage”. The definition of “early” seems to be inconsistent, and the very same investor might turn around and invest in something that seems just as “early” later.

Couple thoughts on this:

1. Consumer internet investors tend to fall into two camps. Those who generally invest before product market fit, and those who invest after (I think Dave McClure put it this way first). It’s fairly obvious who you are talking to when you look at their portfolios and do a little research into what stage the companies were in when they invested. Even if a VC is intrigued by your company, if they aren’t used to investing before product-market-fit, they will be very very hard to convince, and might send you on wild goose chases for directional (but largely irrelevant) data. The best investors are pretty transparent about what they are looking for in specific markets. The best investors also know that the priorities of a company are very different at these stages, and are able to provide the right kind of help at the right time.

2. Most investors have made exceptions to their baseline behavior. So I find that “it’s too early” is usually code for one of two things. 1. I don’t know the founders, and their backgrounds aren’t so amazing that I feel like I absolutely must invest now. 2. This doesn’t fit into the short list of companies I’m specifically looking for. On the first, the thought is that certain entrepreneurs as so good, that they will find PMF even if it doesn’t exist today. “Heat Seeking Missles” as Josh Kopelman calls them. On the second, it’s usually easier to convince an investor about the potential for PMF when they think in part that it’s their idea. This is a difficult needle to thread, so I don’t recommend necessarily trying to find this pro-actively. But investors will sometimes have such strong points of view on a market or a problem that they are willing to take the “leap of faith” with entrepreneurs prior to PMF. The further away you are from an investor’s ideal team and core thesis areas, the higher the traction bar.

Final thought: I’m observing increasingly that there is some confusion between traction and product market fit. Similarly, I think there is some confusion about a successful product that has achieved PMF and a successful company. But that’s a post for another day.

Appreciating Silicon Valley’s Ecosystem

2010-10-20T02:20:46Z

A few days ago I was hosting a foreign government delegation visiting our area in an effort to understand Silicon Valley’s ecosystem and economic development model, and use it as a template for creating or improving their own innovation-driven economies. Many countries but also US regions send such delegations here. Over the course of three days we met with entrepreneurs, investors, bankers, startup advisors, university professors, corporate executives, and lawyers. While I’ve lived in Silicon Valley for the past 20 years, 10 as a startup founder and corporate executive, and 10 as VC, and consider myself an active member of this ecosystem, visits like last week’s bring to focus the Valley’s uniqueness, efficiency, and adaptability.

In a previous post I wrote that people, universities and research labs, risk capital, and modern infrastructure (legal, financial, physical, technical) make up Silicon Valley’s basic ingredients. But during this three-day visit I was able to really appreciate:

Stanford’s central role in this ecosystem. Fifty years after Professor Terman started what is we now know as Silicon Valley, Stanford continues to be not a mere member of the Valley’s ecosystem but its core. It appears that each one of its students is a potential entrepreneur ready to start or participate in an innovative company. Professors advise students on company concepts, often fund these concepts, and actively participate in the resulting companies. Science and business classrooms, cafeterias, and the hallways of the campus buildings are the places where ideas are exchanged and where teams are formed. Recognizing the quality of faculty and students and the IP they create, investors “walk the hallways” in search of the next fundable idea. The University actively encourages the smooth flow of IP from its labs to the startups knowing that it will benefit from their success in multiple ways, as the founders of HP, Google, Yahoo, and of countless other companies have demonstrated over the years.
The ease with which university professors, laboratory researchers and students move between academia and industry, research and development. These people know that without repercussions they can leave their academic or research positions to start companies and create a product or service out of the IP they created in their labs. But they also know that they can as easily return to their old positions to continue their academic or research endeavors.
The willingness and drive to rapidly prototype an idea, test it with prospective customers, evaluate the results, repeat the success and discard the failure, learn from either outcome, change/pivot as appropriate, and try again.
The ecosystem’s completeness, connectedness, efficiency and high execution speed. Many have spoken about the ecosystem’s characteristics but only as you drive from a meeting in Palo Alto (Trident Capital) to one in Mountain View (Fenwick and West) and back to one in Menlo Park (Silicon Valley Bank) you come to realize the efficiency advantages offered by close proximity (VCs, lawyers and bankers within a 10-mile radius). You also realize the advantages of being part of a people-network that has been created and strengthened over many startup-related transactions, focuses on the entrepreneur, and is based on openness, trust, sharing knowledge (successes and failures) and optimism.
The entrepreneurs’ ability to select investors and advisors not based on the money they can invest, but based on the value they bring (connections to customers, connections to executives, help anytime and anywhere on anything from closing the next customer, interviewing and helping to hire the next executive, to refining the business model).

Several countries from around the world, but also many US regions, are trying to replicate Silicon Valley’s ecosystem and economic model in the process of creating innovation- and entrepreneurship-driven economies. Successful will be the ones that analyze this ecosystem and model and properly adapt them, rather than trying to directly copy them. In their analysis and adaptation they must take into account their regional characteristics, peoples’ competencies and temperaments, university environments and IP portfolios, as well as their overall economic environments. While they will make mistakes, they need to remain optimistic, flexible and be willing to experiment, analyze, pivot if necessary and try again until they get it right, just like everybody in Silicon Valley does.

Big Ideas around Big Problems in Big Data

2010-10-20T16:33:00Z

Last Wednesday, IA Ventures held its first annual Big Data Summit. Attendance was restricted to our Limited Partners, portfolio company CEOs and CTOs, leading thinkers and practitioners in fields related to Big Data and a small group of co-investors. There were only 70 people in the room. Thomson Reuters, one of our LPs, was kind enough to allow us to hold the conference in awesome space at the top of 3 Times Square. The sky was blue, the sun was shining and the conversations even more dazzling.

The goal for the conference was to catalyze a series of conversations about how to best deal with problems and capitalize on opportunities in today’s Big Data world. At IA Ventures we structure our thinking about Big Data around three buckets: Visualizing; Learning; and Scaling. Every IA Ventures portfolio company is dealing with these issues day in, day out, but their issues are certainly not unique. One of the most interesting threads in the conference covered how hardware innovation has finally allowed us to tackle Big Data problems. The inexorable drop in the costs of storage, compute and bandwidth, with a related increase in network access has led us to a point where, in the words of Mike Driscoll, CTO and Co-founder at Metamarkets and author of the blog Dataspora, “The economic value of Big Data finally exceeds its extractions costs.” The implications are enormous: we now stand at the edge of a generational wave that will fuel innovation towards solutions for managing the chasm between Big Data problems and Big Data science.

Here are a handful of the Big Data insights I gleaned from the conference:

Widespread adoption of real-time sensors will fuel a Big Data revolution.
Real-time data collection is expanding on exponentially. Passive detection and measurement techniques will provide enormously valuable data to the tools developed by the Big Data community. The skyrocketing richness of data around context, preferences and behaviors will lead to new opportunities for analyzing our “offline” world.

The ability to store everything can lead to problems.
Plummeting cost of storage has enabled many to simply store all their data. Problem is, some of that data is valuable while some is not. The process of identifying and exploiting the data-containing signal can get muddied by avoiding critical thought on the front end.

Algorithms are the game-changer.
So much emphasis has been placed on advances in cloud computing and storage that the value of better algorithms has been lost in the shuffle. Today’s machines with yesterday’s algos or yesterday’s machines with today’s algos? Hilary Mason’s compelling presentation convinced me: I’ll take the latter, hands down.

That said, AWS is a juggernaut and the power of its lock-in should not be underestimated.
While the ease of creating and scaling a virtual data infrastructure has skyrocketed, the difficulty in moving large-scale data has not meaningfully decreased. Many companies who built their businesses on top of AWS will find it both painful and costly to switch.

Scaling development using offshore teams often benefits from moving a core team member to manage the operation.
Coordination between on- and offshore development teams is challenging in the best of circumstances, and as offshore components have grown the importance of global coordination has increased. Migrating the domestic development DNA to the offshore team is vital to achieving long-term success.

Once the wrinkles are ironed out, Mechanical Turk can be a powerful and cost-effective vehicle for scaling data-driven businesses.
We’ve seen several companies leverage Turk to aggregate and QA large-scale data sets with great success. When you let humans do what they’re best at and let machines do the rest, you can take on tasks that were only a few years ago impossible.

NumPy / SciPy have impressed many with its performance.

In the world of visualization, simplicity is king.
Overly complex visualizations with too many data dimensions are almost worthless. Extracting small, highly relevant information from Big Data is where it’s at.

Privacy is dead.
What do we consider to be the boundaries of privacy, especially with respect to items like medical data? In a data privacy-free world, should we be regulating data usage instead? How do we deal with asymmetric access to our personal data, e.g., how is it that insurance companies claim the right to our personal information?

If the past is search, the the future is prediction and suggestion.

With open source and Internet protocols commoditizing software, the advantage will be derived through data.
In this regard, context is king, e.g., contextualizing datasets to surface previously unseen relationships in the feed.

Tim O’Reilly wrapped up his talk with an important message: “Create more value than you capture.” Essentially the ethos of the open source movement. The magnitude of the problems discussed above do not subject themselves to “point solutions,” but larger collaborative efforts leveraging the global brain. The solutions require not only advances in technology but a wholesale re-evaluation of the way data is used, owned and regulated. Preparing for the future is not simply an issue of throwing money at the problem, but of being thoughtful and deliberate in building open standards to facilitate innovation on a large-scale basis.

AIM often proves an unsuitable catalyst for the unready

2010-10-21T17:00:36Z

There isn’t as much talk as there used to be about AIM (London’s junior stock market) which is a shame. Entrepreneurs and their employees and investors need liquidity and a secondary stock market can and should be a good vehicle for servicing their requirements when they have small to mid-size companies.

Not for companies that are too small though – and therein lies the point of this post, which I started writing after reading an article in the FT whose headline I took as my title – AIM can prove an unsuitable catalyst for the unready. Being a blogger rather than a journalist I changed it though, to be a little stronger, because in my experience for every runaway success on AIM like Abcam there are tens of companies that get stuck. (For those that don’t know, Abcam has been a runaway success since it’s $15m listing in November 2005 and recently topped $1bn in value.)

These unfortunate companies find themselves with unhelpful disclosure requirements, significant ongoing costs associated with being publicly listed (anyone know what these are, on average?), and more importantly a shareholder base that doesn’t understand their company and a set of listing rules that often make it difficult to go private or take other radical action.

The FT article was written in response to a PwC survey which concluded that many of the dozens of companies which left AIM last year ‘may not have been suitable, or at least ready for an IPO’. In other words, they would have been better off staying private for longer.

Their alternatives would have been (and, in case anyone hasn’t noticed, I have a clear self interest here) to raise venture capital, raise some other form of private money, or fund growth through profits. I appreciate that none of these routes are easy, and not all of them will be accessible or appropriate for every company, but as the PwC survey makes clear, just because money is available on AIM it isn’t necessarily wise to take it. That said, venture capital is no panacea either, but the restrictions it comes with are less onerous than those that come with a public listing.

So when should companies go to AIM?

I think the answer to that question has two parts:

Value – for a listing to be successful a company should have a large enough market cap and free float that fund managers will be able to take reasonably substantial positions without owning too much of the company, that there is liquidity in the stock, and that analysts want to cover it. A £100m market cap is a good rule of thumb for ‘large enough’.
Predictability – consistent performance is critical for public shareholders who generally speaking aren’t in a position to get to know their investments well enough to understand whether bad periods are blips or indicative of deeper malaise. Unfortunately, most small companies have small numbers of customers and volatile revenues and/or are dependent on one or two partners who may themselves catch a cold – businesses with these characteristics or which are unpredictable for other reasons should think twice before listing.

To close I want to explain that I have concentrated on AIM as a vehicle for finding new shareholders and raising capital to fund growth rather than for providing an exit for existing shareholders because in my experience that is what AIM is mostly about. That is different from a full listing where secondary components are much more common at the point of IPO and greater liquidity also allows shareholders to sell shares more easily post IPO.

You: SMEs Fear of Listing On Bourse (menafn.com)
The illiquidity premium? (aaronkharris.com)

The Best Viral Strategy: A Great App

2010-10-24T12:51:37Z

I was chatting yesterday with one of the early leaders in building highly viral Facebook apps. When I asked him what he was thinking of doing next, I was surprised by his answer: NOT another insanely viral app.

His explanation was instructive. After a few years mastering the viral game, what he came to realize is that the most viral apps need to be purpose built to be viral in a particular channel. The problem this leads to, though, is that this focus on virality comes at the expense of being a great consumer experience.

The flip side is that applications that are wildly popular with users will become “viral” (or at least grow rapidly) in their own right, even if not strictly optimized for it. Mint.com is a great example, as is well described in this Quora thread.

The social app developer ecosystem is, albeit gradually, waking up to this reality. To be sure, plenty of energy is going into working the viral channels; but at the same time I am seeing more and more developers realizing that an overemphasis on virality delivers more short term gain than longterm value creation.

Patents Create Incentives For More Patents, Not Innovation

2010-10-19T16:24:48Z

While many people (especially politicians and the press) like to equate patents and innovation (often falsely suggesting that fewer patents means less innovation), studies have shown that patents are actually a really bad proxy for innovation, in that there's simply no direct link between the two. And that's a problem, considering that the patent system is supposed to be about creating more incentives for innovation. In fact, however, it often appears that the patent system is actually creating incentives to get more patents.

If you want a clear example of this, just look to China. Just recently, we noted that patenting was on the rise by Chinese companies, but a closer look at what's happening in China suggests that it's very much about incentives to increase patents, rather than incentives for greater innovation. In fact, it's quite direct:

The Chinese government has created an ecosystem of incentives for its people to file patents.

Professors who do so are more likely to win tenure. Workers and students who file patents are more likely to earn a hukou (residence permit) to live in a desirable city. For some patents the government pays cash bonuses; for others it covers the substantial cost of filing. Corporate income tax can be cut from 25% to 15% for firms that file many patents. They are also more likely to win lucrative government contracts. Many companies therefore offer incentives to their employees to come up with patentable ideas.

And, as in the US at times, the incentives for the patent examiners is also skewed towards simply approving more patents (which has a snowball effect, in encouraging more people to file weaker and weaker patents):

The bureaucrats in Chinese patent offices are paid more if they approve more patents, say local lawyers. That must tempt them to say yes to ideas of dubious originality.

Incentives are funny things. If you actually believe that patents are correlated to innovation, then such strategies make sense. But if the reality is that patents are simply correlated to patents, then it's a huge dead weight loss to focus so much on patenting, rather than actual innovation.

Permalink | Comments | Email This Story

The Physics of Wet Dogs

2010-10-23T01:52:09Z

Courtesy of Wired:

Tips to get seed funding and support 2/6 - Team

2010-10-21T14:15:00Z

In this post, we'll focus on what's the best way to structure and present your team when applying to the Openfund - or for that matter to any other seed funding vehicle.

When filling out our application you should always, include links to your previous work (and especially the achievements you're proud of), your portfolio, your blog, your Twitter and anything else you would consider representative of your accomplishments and your personality. That way we're only a click way from the parts of your resume that matter and essentially we have a quick way to understand what you're all about as individuals to begin with. Since we try to find as much as possible about the applicants, we'll be definitely looking for all this information ourselves, so saving us some clicks is a good idea. It's also important to provide an email you regularly check so that we can be able to contact you for clarifications on questions not covered by your profile links.

Of course, it's important to show what makes each member a great fit for the business being suggested, essentially what they can bring to the table. Usually this is about 'just' three things: product development, business development and knowledge of the industry. These can be achieved in a number of ways but usually for the sort of startup we're talking about you'll need a couple of technically exceptional people that will develop the product (for example a developer and a designer or two developers) and one or two more that will push on the business development front. All or most of them should also bring some expertise on the domain the startup operates in (e.g. sports, image processing, fashion) - although having one or two people with little experience and a fresh perspective instead, can also be an advantage.

If for some reason, an element is missing (i.e. you need an exceptional designer for a project that relies heavily on that aspect and don't have one) you need to address this, as it will stand out and you'll lose points. It's important to acknowledge the lack and perhaps address it by saying that you're looking for an extra member or external partner - and actually doing it of course (spending a few weeks on this should be enough). Outsourcing a major aspect of your project to a freelancer is a bad idea and should be reserved only for secondary functions.

Apart from that, it's very important to have an accurate picture of each member's availability. Working full time for the project is something we have found makes all the difference. It's best to be open about any future obligations early on rather than surprise everyone later. We're open and flexible to give applicants time to wrap up projects after they've been accepted but this should be done in advance knowledge. Minor distractions may also be acceptable, but they should be indeed minor and in any case addressed in your application. At the end of the day, be prepared that a start-up cannot but be a full time occupation, and if you’re not ready to take the risk and fully commit into that, then you’re probably not that convincing when asking for people to take the risk and partner with you.

Another parameter that is often neglected is how the team actually met and to what extent they have worked together. Obviously old friendships and tried and tested collaborations score the team points but that's not the only way. Putting together a team for a particular proposal may also be fine if it shows off determination and passion for the idea. In any case, a brief story (2-3 sentences at least) of how the team members decided to apply as a team and why they blend with one another is essential.

To wrap up, the team description is very important because at the end of the day, and contrary to popular belief, it's more about the team and less about the idea. This means that your team may realise that they should change significant parts of their concept (main offering, revenue streams, target demographic) and they should be comfortable and flexible in doing it if it means the project flourishes. Unfortunately, changing team composition isn't that easy so it's more important to have a talented and flexible make up that can pivot towards a killer idea - rather than believe you've found the next big thing.

The next post will be about the product itself - stay tuned and keep the applications coming!

I have been looking for this photo for a while. I first saw it...

2010-10-13T17:53:47Z

I have been looking for this photo for a while. I first saw it when I was a student in Richard Tedlow’s class on business history. It’s a really remarkable image because it shows simultaneously the promise and messiness of innovation. It’s a picture where the past, present, and future all overlap. And it shows that at its earliest forms, the next big thing might look impractical or even awkward.

Privacy Violations

2010-10-15T20:16:40Z

All sorts of businesses are being built by violating assumptions about the privacy of data.

Flickr violated the assumption that you wanted your photos private by default. Before Flickr came along, the default photo sharing model, espoused by Shutterfly, Snapfish etc., was that of private photo sharing.

LinkedIn violates the assumption that your resumé is private.

FourSquare violates the assumption that your location is private.

Twitter violates the assumption that some of your thoughts are private.

Instagr.am violates the assumption that your mobile photos are private.

Blippy is testing the assumption that some of your financial transactions are private.

All of these services take your original notion and need for privacy, and trade them off against your need for fame and recognition.

What’s next?

Madison Avenue and the Land of Make Believe

2010-10-14T10:41:00Z

Mass market consumer adoption of Apple iOS and Google Android mobile devices has attracted an unprecedented volume of content, delivered through applications. Because the majority of these applications downloaded are also free, many ecosystem players have assumed that advertising revenue models will dominate how these apps are monetized.

However, new analysis by Flurry reveals that the sale of virtual goods is overtaking advertising in top categories on the iOS platform. Note that because Google’s Android Market does not yet support in-app purchases (micro-transactions), this model is not yet viable for Android apps. This study was conducted using data collected from a sample of leading iOS social networking and social gaming applications, with a combined reach of 2.2 million daily active users.

Reviewing the chart above, the majority of revenue generated from advertising occurs during the 2009 holiday period. During 2010, however, revenue increasingly shifts from advertising to virtual goods sales until reaching a proportion of more than 80% from virtual goods. Admittedly, the idea that consumers acquiring virtual swords, gold coins and respect points can outperform advertising seems counter-intuitive; however, this phenomenon is neither new nor unique to the iOS platform.

In fact, virtual goods sales already represent the primary source of revenue for social gaming on Facebook. Michael Pachter, Wedbush Morgan Securities video game analyst, reports that social gaming has grown from approximately $600 million in 2008 to $1 billion in 2009. Further, he forecasts that social gaming will generate nearly $1.6 billion this year, and grow to more than $4 billion by 2013.

One factor responsible for low advertising levels may be advertising agencies’ slow acceptance of mobile as a media platform, with skepticism about the viability of social games and social mobile media as a channel for advertisement. With these agencies representing and guiding the biggest brands, they appear to be missing a meaningful opportunity to reach a mass market of consumers who have adopted new platforms and forms of content.

As social games continue to expand their consumer reach, demonstrating their ability to attract an audience beyond teenagers using iPod touches, their relevance will increase. In fact, with mobile social game critical mass now rivaling TV prime time viewership, Flurry anticipates a stronger ad revenue generation through mobile social networking and games in 2011. Over the next 18 to 24 months, Flurry predicts strong revenue growth from both virtual goods and advertising revenue from social gaming. We say play on!

Insight as a Service

2010-10-04T14:08:41Z

The survey data presented in last August’s Pacific Crest SaaS workshop pointed to the need for a variety of data analytic services. These services that can be offered under, Insight-as-a-Service, can range from business benchmarking, e.g., compare one business to its peers’ that are also customers of the same SaaS vendor, to business process improvement recommendations based on a SaaS application’s usage, e.g., reduce the amount spent on search keywords by using the SEM application’s keyword optimization module, to improving business practices by integrating syndicated data with a client’s own data, e.g., reduce the response time to customer service requests by crowdsourcing responses. Today I wanted to explore Insight-as-a-Service as I think it can be the next layer in the cloud stack and can prove the real differentiator between the existing and next-generation SaaS applications (see also here, and Salesforce’s acquisition of Jigsaw).

There are three broad types of data that can be used for the creation of insights:

Company data. This is the data a company stores in a SaaS application’s database. As SaaS applications add social computing components, e.g., Salesforce’s Chatter, or Yammer’s application, company data will become an even richer set.
Usage data. This is the Web data captured in the process of using a SaaS application, e.g., the modules accessed, the fields used, the reports created, even the amount of time spent on each report.
Syndicated data. This is third-party data, e.g., Bloomberg, LinkedIn, or open source, which can be integrated (mashed) with company data and/or usage data to create information-rich data sets.

Some of the issues that will need to be addressed for such services to be possible include:

Permission to use the data. For this to be possible, corporations must give permission for their company data to be used by the SaaS vendor for benchmarking. For example, if Salesforce customers are willing to make their data available then their sales forces’ effectiveness can be benchmarked against that of peer companies. It may be more likely for companies to give their permission if the data is abstracted or even aggregated in some way.
Data ownership. The ownership of usage data has not been addressed thus far. Before creating and offering insights, ownership will have to be addressed by the SaaS vendors and their customers. Once ownership is established, as I had written before, this data can, at the very least, be used by the SaaS vendor to provide better customer service or even to identify upsell opportunities and customer churn situations. While some vendors, e.g., Netsuite, are starting to utilize parts of usage data, utilization remains low and scarce.
Data privacy. Company and usage data will most definitely include details that may need to be protected and excluded from any analysis. The SaaS vendors will have to understand the data privacy issues and provide corporate clients with the necessary guarantees. Thus far SaaS vendors have only had to make data security guarantees. Privacy concerns around this data will be similar to those that currently surround the internet data that is being used to improve online advertising.
Potential need for pure-play Insight-as-a-Service vendors. The SaaS application companies may not prove capable of providing such insight services. It may be necessary to create specialized vendors to offer such services. Such pure-play vendors may have more appropriate and specialized know-how which will be reflected in their software applications (essentially analytic applications that can organize, manipulate and present insights). In addition they will be able to offer a broader range benchmarking since they will be able to evaluate data across SaaS vendors. However, having such vendors will also necessitate the move of company and usage data to yet another location/cloud thus increasing the security and privacy risks.
Eligibility for accessing these insights and business models under which they can be offered. One approach would be to only offer such insights to as a separate product by the SaaS application’s vendor to its customers. Another approach, particularly if the insights are to be created by a pure-play insights vendor, would be for such vendors to create data coops. Under this scheme corporations contribute company and usage data to the coop, the Insight-as-a-Service vendor analyzes all contributed data, and only offers the results to the companies that belong to the coop. For this service the vendor can use an annual subscription fee not unlike what industry analysts like Forrester and Gartner charge. Internet data companies such as Datalogix, that has created a coop with retail purchase data, can serve as good models to consider. Another business model may be for the vendor, either the SaaS application vendor or the Insight-as-a-Service vendor, to share revenue with the companies providing the company and usage data. Internet data exchanges like Blue Kai and eXelate would provide good business model examples to imitate.
Geography. As we’ve learned with consumer internet data, each country approaches data differently. For example, European countries are more restrictive with the use of collected data. SaaS companies must try to learn from the relevant experiences of internet data companies as they determine how to best offer such insight services.
Data normalization. Usage data will need to be normalized and then aggregated since each customer, and maybe even each individual user, uses a SaaS application differently. This could be tricky.

Hosted applications need not apply. Not all vendors will be able to offer such services. For these services to be successful, data from the entire customer base needs to be aggregated and organized. This implies that vendors claiming to offer SaaS solutions when they are only offering single-tenant hosted solutions deployed in, what amounts to, private clouds will not be able to provide such insight services. In fact, multi-tenant architectures will be even more important for insight-generation because they make data aggregation easier.

Insight-as-a-service can become the next layer of the cloud stack (following Infrastructure-as-a-Service, Platform-as-a-Service and Software-as-a-Service). In addition to SaaS application vendors that can start offering such services, there exists an opportunity to create a new class of pure-play Insight-as-a-Service vendors. Regardless, vendors will need to start addressing the issues and many more that I can’t anticipate at present. But since surveyed customers are already starting to ask for such services, it is time to start creating them. It means that the time for Insight-as-a-Service has arrived.

Lessons From Silicon Valley VC Legend Don Valentine

2010-10-15T02:00:14Z

With all the fuss surrounding the recent “AngelGate” meetings and the tension between angels and super-angels and traditional venture funds, it’s instructive to listen to one of the legends of the Silicon Valley VC business — Sequoia Capital founder Don Valentine — talk about the approach and the thinking that led to his investments in companies like Apple, Cisco, Google, Yahoo and Zappos. In the video embedded below, he talks to a group of students at the Stanford University Graduate School of Business about what matters and what doesn’t.

Valentine says that many people assume that Sequoia has been so successful because the fund backs “the best and brightest, the greatest managers and all that stuff [but] we do not.” The only thing that really matters, he says, is the market.

“We have always focused on the market — the size of the market, the dynamics of the market, the nature of the competition — because our objective always was to build big companies. If you don’t attack a big market, it’s highly unlikely you’re ever going to build a big company.”

As a result, the Sequoia founder says that the fund isn’t really interested in where an entrepreneur went to school, or whether they have any actual business credentials — all Sequoia is interested in is the size of the potential market they are trying to attack, and the potential value of the problem that they are trying to solve.

“We don’t spend a lot of time wondering about where people went to school, how smart they are and all the rest of that. We’re interested in their idea about the market they’re after, the magnitude of the problem they’re solving, and what can happen if the combination of Sequoia and the individuals are correct.”

In some cases — as with Apple — an idea about the potential market can lead to multiple investments in all of the various players in that ecosystem, Valentine says. Apple “had in mind the idea of you all having your own computer,” he tells the graduate class at Stanford, and the implications of that involved the need for memory makers and disk-drive companies and manufacturers of all of the other parts that were needed for personal computers. So Sequoia wound up investing in more than 15 companies in the PC category, including game-maker Electronic Arts, which was created in the Sequoia office.

The Sequoia founder also says that he had an advantage over some other VCs because he “could see the future,” meaning he understood the transformation that personal computers and microprocessors were going to unleash because he worked at Fairchild Semiconductor and co-founded National Semiconductor. For Valentine’s thoughts on Steve Jobs’ marketing abilities, the failure of Sony and Xerox (which he calls “one of my favorite tragedies”), the importance of storytelling and the launch of Cisco, please see the full video embedded here or at YouTube.

Related GigaOM Pro content (sub req’d):

Moritz’s Provocative Claim: Silicon Valley Needs Just $400M a Year

2010-10-13T17:25:17Z

A lot of venture capitalists are concerned about how their industry is shrinking, but Michael Moritz isn’t one of them.

A partner at Sequoia Capital, Moritz was one of several VCs at yesterday’s DLA Piper Global Technology Leaders Summit who claimed the industry might be better off contracting.

“I don’t think Silicon Valley needs all that money,” Moritz said. Innovation can be funded for $300 million to $400 million a year, he said.

To put that into perspective, venture capitalists invested $7.3 billion in 761 Silicon Valley-based companies last year, according to the MoneyTree report by PricewaterhouseCoopers and NVCA, based on data from Thomson Reuters (publisher of this blog). Since 1990, the median amount invested annually in Silicon Valley has been $6.4 billion, while the average amount has been $7.3 billion, according to peHUB’s analysis of the MoneyTree data.

Moritz’s extreme view might be selling the Valley short. (If VCs put $400 million or less into Silicon Valley annually, that would put the region on par with the amount of money that flows into Dallas and Philadelphia annually.) Clearly he set out to raise eyebrows and spark debate. It is hard to take him literally. Nevertheless, VCs have to look for a new “efficiency of innovation,” says Promod Haque, managing partner at Norwest Venture Partners. It’s a discipline that might be good for the business.

To begin with, there is no doubt startups — particularly Internet startups — are coming together for a lot less. With cheap Intel-based servers and open source software, entrepreneurs can test their ideas for about $500,000 in funding, points out SV Angel investor Ron Conway.

That means an average angel round can be $100,000, and a good sized angel fund $10 million to $20 million in size, says Conway.

If money goes further and startups survive longer on the same dime, then innovation efficiency becomes a new measure of performance. The theory is this new efficiency (perhaps calculated as a ratio of sales to dollars invested) will lead to better returns.

Of course, one barrier exists. Engineers. It is hard to find them, says Haque. The majority of engineers graduating from U.S. universities with master’s degrees or Ph.D.s are not U.S. citizens — and it is not always easy for them to stay in the country.

The solution: Perhaps they should be naturalized upon graduation, suggests Moritz, tongue in cheek.

Well, maybe not so tongue in cheek.