EarlyStageVC

The Teqlo Adventure

Few VCs admit to their misfires, though misses are more common in this business than hits.  One of the reasons I write this blog is to add some transparency to an all too opaque business of private equity.  It has been a while since I talked about Teqlo.com here.  Some of you may be aware there have been some changes recently. Others may have been to the web site recently and said “huh?” or, more precisely, ‘WTF?”

I figure the only authentic thing to do is to talk about this again, even when it is in an ambiguous period of re-birth.  This ugly period is a re-tooling of the premise of the business to give it more clarity of purpose.  It’s not fun being in the sausage phase.

First, let me admit we went down a mashup rat hole. We have a general technology for snapping together web services.  "Because they can" is an insufficient answer to "why do people want to create mashups?"  We failed to commit to solve a specific problem for a specific market, preferring instead the broad appeal of generality.  This has changed. 

No one led us down this rat hole.  We led ourselves.   When we realized we had to make a radical shift, we had to reignite the fire with limited fuel.  We made personnel changes because the fuel demanded it, not to penalize or blame anyone.  So we did the right thing.  We cut, refocused, questioned everything, and sharpened our edge. 

The first thing we did was toss out any pretense of solving everyone’s problem.  There is an old proverb that I just invented for this situation --  “The boiling of the ocean begins with a single puddle.”  We had to define our puddle.  So we did.

A friend of mine told me a few weeks ago that Snapfish is driven by a product team that thinks a hypothetical mom named Emily is their user.  Their design mantra is What Would Emily Want?  We went out and defined our Emily. 

The next thing we did was develop a hypothesis of the ways in which web application integration would please that Emily i.e., what is her pain?  What is she trying to do? What web services does she use to do it? And how does she cope with using 3-5 discrete web applications to get something done?    What  does she do now?  Then we went out and talked to a small army of Emilys. Arrgh!  This will strike everyone as obvious and necessary.  It is. And we hadn’t done it before because we were too busy building.

Along the way we re-learned something. Name your user.  Ask her what she wants; she will tell you, and often she will surprise you.  So we did and they did. One clear consequence is that you will see more emphasis on a configurable application, not a bucket o'widgets that snap together.  Leading with "it's so easy to build what you want" is like making a diet fun – it is still a diet, no matter how much more fun it is. You only do it when you must.

So now the Company is heads down executing what we think is a re-jiggering of the basic components.  We are packaging to solve a problem - not all problems.  Nor are we packaging to provide “examples” of how you can use Teqlo to solve a problem.  Nope.  We have picked a customer, listened to what they want, and are hacking away to get to market.

We now have an Emily in mind, a clear sense of who our natural distribution partners are, what’s in it for them, and how this little puddle becomes a pond and then a lake.  We dream of an ocean, but are navigating the puddle.

I'll tell you this much about the new direction - Web-based workflow.  Teqlo is ideal for making a pre-packaged process made from web applications and stitching them together to get something done.  There is no market for Cut-and-Paste, but Cut-and-Paste is the wow factor in Microsoft Office. There is no market for reconfiguring web applications, but reconfiguration is the wow factor in workflow for specific problems.  Without giving away the punch line, I'll point out that workflow is what's missing from the world of on-demand software.

The site itself has not changed.  It is still as confusing as it ever was.  That is not important, yet.  Over the next few [weeks] [months] the site will begin to molt.  We will shed the mashup cocoon and emerge as very different butterfly. (We may even re-brand the site to clarify what this new application is.) This butterfly will not offer you the universal promise of integration of all web applications. This butterfly will promise a specific user community a way to meaningfully improve the way they use the Web in their daily lives.  And if we do our jobs well, it will also be clear how we make money, not an insignificant question.

Of course, it might still be wrong, but that's the adventure in adventure capital.

Teqlo - A Preview

UPDATE

The crack Marketing Team (a.k.a. Rod) made a terrific teqlo variant of the The Machine is Us/ing Us video showing how Teqlo works. (see the original here, more interesting than the YouTube version, BTW)

ORIGINAL POST

The Teqlo team has decided it is time to provide a sneak peak to show the world what they are about.  So Teqlo.com is open for preview. But before you go there, let me set  a few expectations.  This is a live, production version of the technology, but this is not a demonstration of the business.  You are going to go there and say "why would I use this routinely?"  The answer is you won't. We don't expect you to, and this is not the way we expect average people to use this technology.  We are intentionally exposing the platform part of the technology to test our ability to scale the engine as people bang on it. 

This release is a demonstration of the engine and the technology is not trivial, even though the initial use case looks like it is.   Let me illustrate with simple walk through. 

When you sign up on Teqlo, you'll get a desktop that looks a bit like some more mature products like Netvibes. This is just to give you a home page - a working canvas.  The power of Teqlo is in the Applications and in the Builder.   There is really only one Application on Teqlo.com today - Leads and Calls.  It lets you search Linkedin and DabbleDB to find people and save their names in a contact list.

The magic of Teqlo is behind the scenes and you can see a view of it in Builder.   The Builder is the work area where YOU can build your own applications from widgets, provided the widgets represent real applications like Google Calendar and not just simple RSS feeds.

Below is a series of pictures to illustrate the point.  I built a simple Application that
1. Searches Ebay for an arbitrary product (I like 4x5 cameras; so I searched for Linhof brand)
2. Lets me select the ones I want to track and then Teqlo...
3. Automatically puts them in my Google Calendar
4. Automatically puts them on a list to save for later
5. Automatically maps them on Google.

Here is the result

Now this is trivial example, but it illustrates some interesting things. First, if you go into the Builder (tab on the menu bar), you can pick from a few widgets that are in our catalog and you place them on a canvas. See the next picture.

The real key to building this little application is in what we call the Interactions Editor.  The IE (ick, we need a better name than this), allows you to say which interactions you want between any two widgets.  The IE has to know what actions and reactions are permissable for any widget and it has to validate that these two widgets can share data, i.e., share the same data microformat or other representation.  Teqlo automatically routes data between applications continuously as the data change.  So as you actually interact with the Application, such as de-select an entry, it automatically updates the interactions.

This is what's known as non-procedural programming.  The order of the rules in the Interaction Editor doesn't matter.  There is no control logic at all.  Teqlo flows the data to wherever it needs to be.

This is what makesTeqlo different. This "Application" was assembled without any javascript or any other programming by me. Granted, it is not super powerful.  But this is a function of the limited widget library, not the approach.

By the way, to give you a hint of where things are going, take note of the fact that you can have multiple "canvases."  What is a canvas? It is a page or a part of a page.  So you can have real-time applications that render different views to different users on different pages anywhere on the Web, all simultaneously.  You update the search list on Ebay and it can update a calendar (or something more interesting) on a page that I am looking at in real-time.  "Web as a platform" just moved from a Web 2.0 slogan to something concrete.  Think messaging; think feeds and events; think true collaboration.

Stay tuned.  Teqlo looks like a mashup tool today, but we have more interesting, larger, and more focused intentions.  As I said, this release is just a proof point.

Meme-check - Enterprise & Web 2.0

Gartner has now officially anointed Web 2.0 a bona fide IT trend.  BFD. Of course, they straddled the meme, by putting it at the peak of their 'hype cycle' graph.  That is the consultant's version of plausible deniability.  If it turns out to be real, they called it.  If it is not, they still called it.  This idea has picked up a lot of steam since I first noticed it  ten months ago.  Dion Hinchcliffe and Andrew McAfee are the real thought leaders, emphasizing the technologies and social/managerial impacts respectively.  Dion Hinchcliffe does his usual masterful job of deconstructing some of the elements of this Gartner-validated wave.

Before we all jump on this bandwagon, let's exercise some intellectual restraint and rigor, and in the process perhaps abandon the use of 2.0 as a synonym for "new". The original moniker of Web 2.0 has been used to imply/describe/justify/motivate a collection of concepts that range from standards (like RSS) to technical methodologies (like AJAX) to social phenomena (like personal publishing, rating, and sharing).  Web 2.0 has been as much about sociology as technology. But Enterprises are not just big "collections of consumers" and so let's not graft the same concepts and expect a thousand enterprise flowers to bloom.

First, dispense with the sociology. Enterprises have two core attributes that do not exist as widely in the public web -- purpose and accountability.   So 'empowerment' and 'collective intelligence'  are not end points.  Nor are 'discovery,' 'networking,' nor 'sharing.'   These are embedded in processes and are methods for creating context to purposeful transactions.  A sales forecast is 'collective intelligence.'  Mining customer comments is a form of 'discovery.'  A internal blog post is more likely to be linked to a product release status than photos of my vacation. Viewed in this context, a lot of what passes for (aspiring) businesses in Web 2.0 are simply features of larger processes in the Enterprise. 

So Enterprise 2.0 as a platform shift is mostly about the enabling technologies.  Web 2.0 rode the back of Open Source and Moore's Law to crack the economic barrier in building web based services. What followed were technologies for making applications richer (AJAX), easier to build (Ruby on Rails), and easier to integrate (REST and RSS). 

But only a tiny community of developers have built Web 2.0 apps using AJAX, ROR, or LAMP.  It is really just a few thousand people -- and very few work in large enterprises or ever will, again.   So how will the Enterprise 2.0 apps get built?  I doubt it is from a startup like Jotspot who has no business process expertise nor business data management expertise.  I doubt it is Oracle or SAP who pride themselves on selling Sherman Tanks as radiation-hardened compact cars. The users will build Enterprise 2.0 apps, not the vendors. 

The question is who will "get it" first?

• Will the enterprise application guys (the IT dinosaurs) "get it" about embedding communication and social context in long-running transactions, or
• Will the web 2.0 guys (the IT plankton) "get it" about business processes being the purpose of enterprise community and communication?

Tough call.

Maybe there's a third choice.  Maybe the users will be able to imbue business processes with social computing features. 

The growing consensus is that web-oriented architectures in the form of "mashups" will be the first wave of Web 2.0 in the enterprise.  Maybe, but I think these are going to be niche tools, not mainstream.  Why? Because today's mashups are data mashups and once you have the data, you rarely need it again.  As a test, think about how often you got back to a cool mashup you've seen to re-use it over again. 

This is the promise of process mashups - user-driven, maybe even user-authored, collaborative applications that support core business processes.  Data mashups are the New EII.  Process mashups are the new EAI.  (To be meme-compliant you may want to call them EII 2.0 and EAI 2.0. I don't.)

We are ripe for an breakthrough as big as Visicalc.  The spreadsheet exposed the power of the microprocessor to millions of PC users.  It was and remains the only significant programming tool used by millions of people who know nothing of linting, compiling, scripting, or even looping.   It provides a simple method of assembling data sources to create a custom "application".  The application is really part of a business process, most often a financial process.  A spreadsheet for business processes would be a powerful way to unlock collaboration and process knowledge in Enterprise 2.0.

Recruiting at the Edge of the Web

If you are a frequent reader of this blog, then you probably know that my investments tend toward a theme that I think of as ‘the recombinant web.’  All my recent investments have something to do with structuring or mining information and services on the web in service of the idea of “web as platform.”

Two of the most interesting companies have not yet announced themselves to the world.  They remain quiet, not to escape attention, but to avoid getting wrapped up in a hype cycle.  You can call this stealth if you want.  I prefer to think of this purely as gestation.

Remaining quiet also makes it difficult to find the very best people.  The first few members of the team have the greatest influence on the success, culture, and direction of any company.  This is part of the attraction of a startup and a special kind of person is seeks this kind of empowerment.  Unfortunately the process tends to be haphazard, as great people aren’t usually actively looking for a new challenge and great opportunities are often not easily found.

Two such great “under the radar” companies in my portfolio are Abgenial and Radar Networks.    Neither has really described themselves to the outside world, but both are looking for a few great developers.  By sheer accident these two companies share some important parallels. 

• The founders of both companies have successfully founded prior companies that went IPO,
• The companies are attacking the “recombinant” web from complementary angles (data and applications),
• Both companies have been in development for 3-4 years by the core technologists prior to VC,
• Both companies are on at least the third version of the core technology development,
• Consequently both companies have very rich intellectual property portfolios

Radar Networks
Radar is what is described as a Semantic Web company.  Semantic Web generally refers to a set of technologies for organizing content/information to make it more re-usable and navigable. The founder/CEO is Nova Spivack, well-known thought leader in the Semantic Web community. 

Some Semantic Web companies are enablers, developing specific tools for ontology design and editing,  RDF triplestores, extraction tools and other things.  Radar has developed some of these technologies in-house and is using some 3rd party technologies, too.  The real focus of Radar is a consumer Semantic Web application, not tools.  Since the Series A funding in April, the core team has been heads-down building out the internal tools and prototypes.  Radar has been quietly generating some attention among some VCs and Internet execs who are privy to their plans.  Expect some news shortly.  If you are a software developer who fits this description, Radar is a terrific place to immerse yourself in using state-of-the-art technologies to change the way people find and use information on the web.

Abgenial Systems
Abgenial is solving a complementary problem.  If Radar is about how to make web content interoperable and consumable,  Abgenial is about how to make web applications interoperable and consumable.  The earliest form of this activity today is called mashups.  But mashups have some real technological limitations.

Abgenial has developed a very general and patented technology to allow everyone to create web applications out of components on the web (or behind the firewall).  It is too early to declare the market focus of Abgenial in a forum such as this.   However, suffice it to say that everyone can benefit from combining web servicesinto a more peronalized experience. it ranges from the consumer who wants to have a place where all her “digital me” data all come together (from Myspace, Flickr, Google Calendar,  Digg, etc.)  to enterprise IT who want to create composite applications from web services. If you fit this profile and are interested in seeing how concepts like web services, microformats, and user-created applications can turn the web into a true platform, you should consider joining us.  The Company is still very small, but the opportunity is very big. The CEO is a pretty marginal, but he will be replaced soon enough.

My Second Job

A few weeks ago I wrote a long post about our recent investment in Abgenial.  One thing I didn't mention is that I am the Interim CEO of Abgenial.  The cash comp is lousy, but the karmic compensation is great. 

Rafael launched the blog today in which he blew my cover. So I felt compelled to add a commentary as a company perspective.  Don't look there for an explanation of Abgenial, yet.  It's more of a statement of what Abgenial is not.  Most of all, Abgenial is not a YAMP - Yet Another Mashup Platform. 

I promise to keep my day job and my second job editorially separate.  I will continue to write here as EarlystageVC, with the same lengthy and infrequent posts on venture capital, entrepreneurship, and the Web as I always have.  The blog at Abgenial will be an advocacy blog -- speaking from an Abgenial POV  to whomever cares to listen.  Hopefully I will accomplish my #1 MBO at Abgenial and replace myself soon with a new, improved CEO.  Then I can stay back in my day job, watching others have all the fun, and swoop in once a month for a few hours and tell everyone how the run the business, i.e. be a VC. ;-)

Investing at the Intersection of Opportunity and Serendipity

We just made a new Series A investment in a company called Abgenial Systems.  Dan Primack and Matt Marshall will pick this up soon enough.  So I thought I should get out in front and discuss this a bit. Pardon me for being a bit oblique in what I am about to describe, but it is hard to strike a balance between transparency and pre-announcement when dealing with early stage investments.  I don’t want to pre-announce or hype what they will do, but I do want to describe how we came to make the investment. It wasn't the usual "show us your Powerpoint and wait for the white smoke" dialog that characterizes most entrepreneur/VC interactions. 

---

About a year ago I became interested in the phenomenon called mashups.  VCs try to find Big Ideas that transform existing markets or create new ones. This seemed like a Big Idea, but packaged in a Small Box.  I started thinking about something I eventually came to think of as The Recombinant Web --  a half step between Web 2.0 collaboration and the Holy Grail of a Semantic Web.   After all, the motivation of mashup creators was to recombine otherwise useful silos into new, ever more useful experiences.  Today’s web services are kind of like old, single-tasking PC applications.  They exist largely isolated from each other on a common presentation screen.  Then it was the CRT.  Today it is the browser window. 

The “integration” of Google’s web services or Yahoo’s web services is reminiscent the “integration” that existed in Lotus Symphony, the short-lived successor to 1-2-3.   I especially like this description from 1985  because some things never change. A hit application spawned visions of a platform...

Lotus designed Symphony for access by other programmers. Hooks inside the software help developers write applications for the Symphony environment. Add-in applications directly from Lotus also are expected. Obviously, Lotus wants Symphony to be your only program. Whether this idea is valid depends on several factors, not the least of which is how well the package works with the expanded RAM of such computers as the IBM PC AT. With up to three megabytes possible, Symphony memory problems could become a thing of the past. (Creative Computing, February 1985, p.88)

Sounds vaguely familiar.  "Hooks inside the platform" - the 1985 version of API, and "up to three megabytes possible. Memory problems could be a thing of the past." - the 1985 version of the infinite resource of the Googleplex.

Mashups emerged from the current developer community as a way to exploit the Web as that platform and break  down the stack of proprietary, but "integrated" web applications from GYM.  But “mashups” have lots of limitations as a methodology. Over time I distilled the issues to three fundamental objections. 

• First, the author/user distinction doesn’t scale.  You can’t possibly know what web services I might want to combine nor how.  Only I do.  I want to program the web.  I don’t want you to do it for me any more than I want to go to a site that lists all known queries to search the web.  A corollary to this point is that will be few (no) mashups that are viable standalone businesses, at least not at a scale that has an interesting economic consequences for an investor.


• Second, there is only so much "bookkeeping" that can be done efficiently in the browser. Integrating in the browser is like cooking on a camping stove. It's possible, but it wasn't designed for an elegant and synchronized multi-course dining experience.  Complex and interesting re-combinations are not what browsers and AJAX were designed to support.   

• Third, the idea of users combining arbitrary web services seemed too unbounded and too early. It seemed wrought with lots of nasty issues like service availability/fail-over, financial models,  data formats, and a small issue of programming, programming, and programming.

I started blogging about mashups with the intention of learning-by-publishing.  The more I wrote, the more I learned. The more I learned, the more convinced I became that these issues required a fundamental re-think of how to approach integration. For the concept of re-mixing to become mainstream, It had to be capable of handling sequencing of web services and flows of data, but with a user interaction model as simple as point and click or cut and paste.  A tall order.  The more I stared at concept of "mashups," the more convinced I became that the concept was too parochial.

---

Three or four years ago my friend Pete Kolstad introduced me to Rafael Bracho.  Rafael was a co-founder of Active Software and a pioneer in the 1990’s evolution of enterprise application integration (EAI) software.   Active Software went public with Rafael as CTO and eventually merged with WebMethods.  Somewhere along the way, the original EAI vision of simplified application integration became bloated by layers upon layers of standards, registries, modeling languages, protocols, etc. and promise of nimble enterprise services-oriented architectures (SOA) was DOA.

We were looking at an EAI appliance company about 18 months ago and I asked Rafael to help us with the diligence. Luckily we lost that deal to another VC firm  (it since has not gone well).  Afterward, by pure serendipity for both of us, Rafael started telling me about a technology he and a partner had been working on for several years under the name Abgenial Systems.  It was a radical re-think of how to integrate applications.  It was so radical, in fact, that we didn’t understand where to use it, nor did the other VPs of Software Development that we asked to look at it.  By starting with a new conceptual model for what integration and interoperability would mean, Rafael and his partner Jacoby were able to simplify the enterprise integration problem to the point of near triviality.   

I was stumped as to how to make this an interesting business.  WebMethods, Vitria, Tibco were yesterday’s news.  Who cares if you could steal share from these guys? They were locked in a fight to the death on near-free software, bundled with low margin consulting services, and rewarded with market caps running at 1X revenues. 

---

My most important observation from immersing myself in the concept of mashups was the recognition that mashups were just another form of application integration, done client side rather than server side.  That launched me in to seeing a potential unification of innovative consumer applications with stultified enterprise applications.

All of a sudden the idea of Abgenial pivoted.  Last Fall, Web 2.0 was white hot on “collaboration and mashing” and Enterprise Software was moribund with “legacy vendor consolidation and broken distribution models.”   Software as a Service was the VC industry’s  Great White Hope, combining Web distribution with Enterprise functionality. (Read this as low cost of distribution and tangible value.) Google, Microsoft, and Yahoo were increasingly veering towards web applications (calendars, maps, photo sharing, etc.) – free form of SaaS.

The Abgenial Pivot was to see the dots were connected.  Consumer web….enterprise web…..Saas….legacy apps…. Mashups….SOA were all variations on a theme and that theme was <hype>Programming the Web</hype>.  It was then that I went to my partners and asked to provide a $250K bridge loan to blow away the haze and find the business in this combination of market intuition and technology.

We did. 

And then we screwed it up.

Thinking that the real innovation here was software, we designed a software business.  Sell a product and make money.  A time-honored tradition.  We approached a bunch of VCs whom I know with (1) a team with a record of success (2) real, protectable technological innovation and (3) a short productization plan.  No bites for a co-investor in Series A. The market said, Wrong! Software Still Sucks.

We went back to the Business Model Drawing Board to re-consider how we could accomplish this grand(iose) vision of programming the web, but with a more palatable adoption model.  In retrospect, I think the first pass of delivering the technology as software was a default option.  It was easiest because this is what the team had done before, not because it was what the market wants today.  So, of course, we moved to hosting -  but hosting what exactly?

We went through several theories of what to deliver, looking at various other companies as role models.  We flirted with being a "better this" or a "better that" but constantly came back to the belief we could be so much more than a Web 2.1 company, precisely because the technology was so radically better and different than anything we had seen. Along the way I managed to get confirmation of this point from folks I knew at Salesforce, Microsoft, Google, and Yahoo, as well as the single most-informed thinker on Web 2.0 software architectures I have met - Dion Hinchcliffe.

I was stretched with my partners.  We were thrashing.  We knew we had something Big, but somehow it was the Business We Dare Not Name. Technology, Platform, Application, Solution -- these are all gobblegook businesspeak that don't define anything concrete. 

Then we had a breakthrough.  Oddly enough it came at meeting at one of the largest software companies back in May.  Rafael and I were both there schmoozing and being schmoozed.  A few conversations into the day, a light went on for both of us.  All of a sudden the fog lifted and it was clear to both of us how to go to market and the natural business model. It was a kind of a Steve-Jobs-in-Xerox-PARC moment.

That stunning moment of clarity was enough to get my greed glands going. I no longer wanted a co-investor.  VCs alternate between fear and greed.  Now that the opportunity, differentiation, value proposition, and path to monetization are clear the next steps are about establishing proof and building a team. I outlined the concept to my partners and we agreed fund this post haste.  We closed Series A two weeks later. The team is hard at work building out the business.  Soon we will begin looking for some senior management, including a world class CEO (hint to reader).

Abgenial isn't really in stealth mode. It is not a state secret, but it is clearly in gestation and explaining it is just a distraction right now.  One thing I have learned after 25 years in software is that innovative software defies description. It has to be seen to be understood. Imagine Bricklin and Frankston describing Visicalc before you saw it.  Imagine Ray Ozzie describing Lotus Notes before you saw it. So please be patient.  Abgenial will emerge from the shadows soon enough, and then you'll see why this Aha! was so hard to find, and so obvious once we did.

Chance favors the prepared mind.  Blogging as a form of thinking out loud definitely helped me prepare mine for this one. 

Web 2.0 – Now What?

There have been several posts chronicling the abundance of Web 2.0 clutter companies.  Rich Ziade had a great post showing the 15 minutes of fame that new Web 2.0 companies have as they circulate in the blogosphere for a week or two.

Baris had great survey of Web 2.0 companies detailing the clutter by category. Ismael has compiled a similar database of Office 2.0 companies.  Last week Brian Benzinger pointed to 50 companies online that basically serve the same function – taking notes.

Evidence of the Entrepreneur Bubble continues to accumulate.  And entrepreneurs are not the only ones chasing the future by looking in the rear view mirror.  The VC community seems to have re-discovered the social network yet again.  MySpace and Facebook have spawned a hundred clones.  I get 1-2 inquiries a week from entrepreneurs in the US, India, or China with social network proposals.  Video sharing is another meme-of-the-moment attracting attention and capital.  Imitation is breaking out everywhere. Last week that frustration caused me to reflect on what it means to have a barrier to entry.

But there is a bigger question at hand and I think it is on the collective minds of everyone who has been immersed in the torrent of Web 2.0 creativity.  Simply put, it is

Now What?

Web 2.0 is on the verge of going from Wired to Tired or so it seems.

VCs and some enterprise folks are starting to talk about Web 2.0 in the enterprise as Web 3.0 – Wikis, RSS, collaboration and knowledge management.  Others call it Enterprise 2.0.

I had breakfast with someone yesterday who is joining a very visible Web 2.0 company to become their General Manager of Enterprise solutions. Hmm…

I subscribe to the thesis of enterprises as a natural user of all this technology and have for a while.  Companies are communities. Supply chains are social networks. A customer base is a community, albeit often not interconnected, except by indirect methods like lawyers and analysts.  Shareholders are a community, often interconnected the same ways. 

Companies have known this for a while.  Recruiting has been an exercise in social networking for a long time, both on the employer side ($500 referrals) and the job seeker side (the origin of the concept of “networking”).

But the difference between collaboration in the consumer and business worlds is one of purpose.   Expression is the primary purpose is many Web 2.0 consumer sites.  It may be expression for entertainment, expression for reputation enhancement, expression for contribution to collective knowledge, or something else. 

Collaboration in a business context has a goal other than the act of collaborating itself.  We used to call these goals business processes.  Collaboration is one important component of a business process, but it is not the whole process.  Another interesting dimension of a business process is a transaction.  A transaction is the organization’s transformation of a set of initial inputs  (customer inquiry, need to hire, etc.) into an accomplished goal.  Collaboration is either loosely or tightly bound to the process.  But so are data and systems.  And that’s the other half of Web 2.0 to me – the lightweight integration methods of Web 2.0.    Together these two parts of Web 2.0 can re-engineer enterprise IT. Interesting. And the Enterprise itself.  Much more interesting.

OK Where?
Mash-ups represent a potentially powerful way to create new ad hoc Web applications out of existing enterprise data and web services.   Business intelligence applications are likely to be the first places we will see these appear for simple reporting and visualization purposes. Ultimately, they will emerge as complete business processes that mash (integrate) enterprise applications with applications in the cloud.  And SOA and Web 2.0 will fully converge.

But the Web 2.0 applications in the enterprise are not going to be the same as the consumer apps in the cloud. And this is more than just “behind the firewall” or not.  Applications are going to be more contextual to have value.  A Web 2.0 method of collaboration for product design and management of the bill of materials isn’t a tag cloud.  Nevertheless, tagging and structuring the ideas are an important part of ensuring the original design intent gets expressed in the delivered product.   A Web 2.0 method of managing a customer base as a strategic asset will encourage customers and vendors to share information and product applications, requirements, limitations, and flaws.  It will also change the conversation in unpredictable ways.  Mining and reporting will be just as important as capturing and ease of use.

Creating the enterprise context will be where most “ported” Web 2.0 applications fail in transferring to enterprise uses.  Because the processes do have a purpose in the enterprise, the applications of collaborative computing will need to reflect that context to be high value.  A wiki could be used in a product development team and a wiki used by a major account sales team.  But the real value will be in structuring the usage, content, reporting, etc., to really impact the goals of the teams. The wiki will be a feature of a larger solution.

This is one interesting Now What? impact of Web 2.0 for me.  Enterprises are the ultimate Walled Gardens.  The distinctions of customer/supplier, employer/employee, management/staff, marketing/sales/engineering, Chicago Office/London Office, IT/line of business all become less meaningful in world where information is more easily, more inexpensively, and more rapidly shared, transformed, and consumed. This will put pressure on organizations (and regulators) in a long wave of upheaval.  Enterprises that harness this fountain of real-time and granular information will have a huge competitive edge - an edge equivalent to the first uses of data warehouses and data mining.  They will find and react to opportunities the way that program traders find and react to market inefficiencies. This  may well be the new Strategic IT.  The strategic IT asset is not the software that automates the process.  The asset is the embedded knowledge of all these enterprise communities and its integration into business processes.

Most VCs today think enterprise software is dead, especially for early stage companies.  I don’t.  I think the days of the $1M sale / 18 months to deploy are long gone.  But new, capital efficient Web 2.0 methods of consumer services morphing into lightweight solutions to empower enterprise users are about to emerge.  Lessons learned in Web 2.0 are going to get monetized in new enterprise IT.  Perhaps that's What's Next.

Addendum: Tech Crunch reports today that Facebook now has corporate clients.

A Vast Improvement for Classifieds, Mashups, and the Web

A few months ago I noted the release of Google Base as a pivotal moment in the maturation of the Web.  I said the move from unstructured to structured data was an important improvement in making the Web usable and re-usable. 

I have also discussed mashups as an important, lightweight development paradigm for making this reusability possible.  Thus far the mashups I have seen have been features, mostly visualizations of someone else’s data on Google or Yahoo maps.  The owners of the primary data have Web 1.0 business models, including Google Base.  The Web 1.0 model is “all your data are belong to us.  So come to [oursite].com if you want to see it."   Consequently, mashup innovation stops at the edge of what’s  really interesting, because mashup developers can’t rely on re-mixing those data and building really great destination sites.  This conflicts with the walled garden business model of the data aggregator.  Hence, restrictive licensing models.

Well, now there is about to be a Vast improvement. 

Vast has been in development for about a year, creating what I think of as the first inverted portal.  Now the preview release is up, showing the first three "applications" of the technology. Vast crawls the web for data and extracts that data in vertical categories.  The URL Vast.com is a demonstration site, not really a destination site.  The real destination site is everyplace else on the web – blogs, discussion boards, microsites, social networking sites, etc.  Anyplace where content creates context.

Vast.com looks like a classic classifieds site, but it is not.  It is not a data aggregator.  It is a data disseminator.  It is a hub targeted to the developer community to enable the mashup of structured data in a reusable form.   And it’s not just about classifieds.  It’s about adding structure to content. But the first application of structuring the Web is to take free-form descriptions on the Web and make them structured, searchable listings, i.e. classifieds.

What’s different from the aggregators besides the business model?  It is the data itself.  The data do not come from feeds.  They come from crawls of primary data sources – cars listed on dealer sites, jobs posted on companies’ web sites,  personal profiles listed on blogs, personal web sites, and dating sites.  As a result, the data are Vast – millions of cars, millions of jobs, and millions of profiles, with more categories of objects to come.

This is the true long tail of listings. The user benefit is obvious -- find the exceptional value.   Like the old joke -- why is it always that you find something in the last place you look? -- the exceptional value is always in the long tail. 

You don’t see a lot of end user features on Vast.com – no AJAX widgets, no mapping, no integration with reviews and ratings.  What you will see a Vast amount of data.  If you have a web site about Miami – create Miami-only view of the data.  If you have a Mercedes-Benz discussion site, create an M-B specialty classifieds component.  If you think you can do the next HotorNot.com, build it.   You can even build the next Vast.com on the API.  All the features you see are available in the API for free.

I don’t think of Vast (or Riya) as just Web 2.0.  Web 2.0 is largely about tagging, social annotation, and sharing.  I think of Vast and Riya as bricks in the road toward a Structured Web, beyond Web 2.0. Vast does for free form text what Riya does for images – extracts structure for reusability.  There is some additional discussion of Vast here, here, and here. 

Vast is not a walled garden.  It is  “All your data are belong to you.”  Have at it. 

Microsoft - The New API Price Leader?

There was a lot of conversation today at Mashup Camp about (1) the inevitability of key Web services being re-mixed into interesting new applications and (2) the frustration that business models of the API providers are unclear, at best. This is not going to change until the market forces a change. Here’s one forcing function to consider.

My friend Naval Ravikant had a clever post recently about how Microsoft could take a whack out of Google by adding an AdSense blocker feature in the new version of Internet Explorer. While partially a joke, the idea illustrates how MSFT could leverage the difference between its business model and Google’s to the detriment of Google. However, it would probably be anti-competitive. Just blocking ads per se doesn’t create affirmative value for Microsoft. What I am about to outline does.

A major reason that YHOO and GOOG have not published business models for their web services is that their businesses are based on “direct sales” not “indirect sales.” APIs are indirect sales. End users coming to my web site are direct sales. A change in channel strategy is always disruptive in any business, particularly high P/E businesses that missed their numbers once already, as YHOO and GOOG did last quarter. It makes them even more resistant to disruptions from the number three competitor.

MSN is the clear and distant third in the consumer Internet. Microsoft’s core business remains (1) enterprise-focused and (2) developer-centered. Thus far this sensibility has hampered Microsoft’s ability to build a compelling end-user franchise, as least measured by YHOO and GOOG standards. So why not invert their consumer model and move to an API-centric strategy? And what if the APIs were free and unlimited?

MSN has a web services stack largely equivalent to GOOG and YHOO – mapping, instant messaging, search, etc. Why not center the value proposition to attract developers rather than end users? Make the APIs for all of MSN services unlimited and free. That will attract developers from Google Maps and Yahoo search in droves. Have MSN take the lead in the next generation of the Web by turning MSN into a developer-friendly platform. Build the Web around Microsoft APIs, just like the desktop is built Microsoft APIs. So far this sounds like Naval’s idea – eviscerate YHOO and GOOG by enabling developers without benefit to MSFT. So where’s the beef?

If developers adopt MSN services as their content platform, it’s a short leap to get them to adopt MSFT tools as the development platform. (Certainly not all, but a lot). More importantly, as enterprises adopt web development methodologies (mashups, RSS, etc.) to support their own IT, it’s a natural to drive MSFT software products as the internal platforms. Turn Office 12 into the user interface. Turn Biztalk into the mashup engine. Drive the enterprise to integrate business information with MSN services, e.g. mashup major customers and sales locations onto MSN Maps via MSFT CRM. Use the consumer web to drive the adoption of the MSFT tools and infrastructure stack into the enterprise.

The core of this strategy is to stop chasing GOOG and YHOO with consumers and recognize that IT developers are consumers too – consumers who hack. Get them to hack the MSN version of the Web and accomplish two objectives. Put pricing pressure on your competitors and extend your enterprise franchise in one fell swoop.

MSN has a wonderful strategic opportunity. Who’da’thunk?

Some Problems with Mashups

Reader warning. This is a long, potentially boring discussion about mashups.  Mashups are a geeky new web development activity that fascinates me and a small community.  If you don’t know or care about mashups, don’t waste your time reading this.

There is tremendous interest in the developer community in the concept of mashups.  The upcoming and oversubscribed Mashup Camp, and its derivative Mashup Camp II, and Mucho Camp are all signs of the attraction of the idea of re-mixing Web data into new, richer user experiences. 

I, too, am fascinated by the promise of mashups.  (I didn’t quite move fast enough to make the 300 signup cutoff for Mashup Camp.)   But I see some real problems in turning mashups from an interesting parlor trick into a real business. 

Let’s begin by differentiating a mashup-as-feature from mashup-as-business.  Mashups as Features (MAFs) are great, but I suspect this is not why developers are so taken with mashups.  By a MAF I mean a feature like visualizing houses or jobs on Yahoo maps.  This is useful, but is really just a feature of a classifieds user experience.  This is logically equivalent to a click-to-call integration -- useful, but not a standalone economic activity. 

I have yet to see any “mashup” that is anything more than a MAF and I think there are several important reasons why.

Problem 1 – Can you add value?  Mashups sit on the shoulders of others.  The components of the mashup are real, substantial applications by themselves.  Ebay is a business (as in Ebay mashed with Yahoo).  Craigslist is a business (as in Craigslist mashed with Google.)   To be a Mashup as Business, the new business must add value beyond the value created by the sources.   That added value could be new proprietary data or new proprietary logic or both.  Merely joining two existing sources doesn’t add enough value to build a business.  It’s like buying hard disks, CPUs, and motherboards at Frys and trying to be in the computer business. Mere assembly of components is convenient, but not worth much, unless you're Michael Dell.

This is the challenge in mashing together consumer services.  Can you add enough value?  Have the sources left enough room for you to add value? If you have a proprietary new data source, you could integrate with other data sources and build a new experience.   Zillow is but one example, using tax assessor data to estimate home values.  Your value add is your data, not the data integration. If the data are not proprietary, e.g. job listings, you may be better off finding distribution channels for the data (syndicating the data) rather than mashing it yourself.  If the data are proprietary, e.g. sellers’ reputations (Ebay), then their value greater within a captive experience. 

Problem 2 – Can you build real applications? Developing a proprietary data source is a high cost route to differentiation.  The lower cost, tried and true route is proprietary process or application logic.  Integrate 4-5 web sites into a proprietary consumer experience.  This sounds straightforward.  But there are two key problems.  First, you can’t do this integration easily with browser-based technologies.  Polling data sources with AJAX is one thing, but executing application logic and maintaining state across sources is another.  Tracking long-running transactions is just too much bookkeeping to do client side.  Even if you did suffer the pain of doing all this in the browser, a large part of the source code to your application logic is now potentially downloaded by every user everywhere in the world!

Problem 3 – Consumer processes are simple. OK, even with these problems still you’ve decided to build a new consumer application mashing together four sites with your own application logic.  The next problem is the inherent triviality of most consumer processes.  Consider the following illustration.  I am buying a house.  The process is complex  --  house search, investigate neighborhoods, loan search, qualify, apply, etc. But how many people want a site to thread all these into a single process?  Which do you do first? The consumer choice process is to optimize each step serially, not globally optimize the process.  The real problem with consumer mashups a business is that consumer’s processes are rather simple, making it hard to add process or logic value.  If you disagree, do your own thought experiment.  Can you imagine four sites you visit where what you do on one depends on the results of the prior sites? That dependency is called process.  If you have counter examples, I'd like to hear from you.

Problem 4 – Consumer business models are tough on mashups.   I have written on this before.  When you use someone else’s API you become a reseller.    That is to say you provide distribution to their service.  Most web services don’t have business models for their APIs because they don’t have reseller business models, yet.  Consider the language in the API for Last.fm as a classic example of the conundrum. 

If you're trying to do anything remotely high-traffic, we'd very much appreciate a heads-up first. We don't have infinite resources to support this. 

Last.fm is not unique.  Google’s API FAQ contains the following:

Pricing Questions
1. Does it cost anything to use Google Web APIs?
No. This is a free beta service. However your program is limited to issuing 1,000     requests per day to Google.
2. Does Google have any plans to sell Google Web APIs as a service?
Not at this time.

So how would I build a custom music search experience that mashed together music search (Last.fm)  with concert search (Tickets.com) with web search for band member information (Google) with a group calendar (Trumba) and an invitation engine (Evite)?   Be successful, just not too successful.

I am also a huge advocate of the beauty of quick and dirty over never and elegant.  Mashups are quick and dirty SOA.  Let’s wave a wand for a moment and assume enterprises actually were buying software solutions from small companies again.  Then the enterprise would be a wonderful petrie dish for mashup businesses.  Processes are more complex, the alternative of deep integration is too brittle and expensive, and business models are clearer.  Mashup Siebel and Google Maps and Skype-In into a customer self-service application.  Mashup Great Plains and Salesforce and Fedex into a customer RMA/package tracking solution.   This will happen. And when it does, mashup technologies are going to do to enterprise applications what the PC did to enterprise computing – move the solution to the edge where quick and dirty has more value.

This may all sound like I am a Luddite about mashups.   Far from it.  I am bullish as can be. These problems are some of the biggest opportunities.  We have made four investments in the past year in and around mashups. And we expect to make more. A company that has an innovation to solve any of these barriers is likely to be a big important company in the evolution of the Web stack because the re-mixing of the Web is inevitable.

PS. A reader of this post named "Long Ago Y!" (a former Yahoo product manager) has another take worth noting if you are a developer playing with APIs

Mash ups and open API's allow goog and yhoo to get their integration ideas and product R&D done on the cheap. Open the API's, let people build mash ups and watch what happens. The cool apps, yhoo and goog will go and build themselves (they might buy out the developers, they might not), the lame ones? Free market research. Free prototype development and testing.

Worth noting.