In my previous post on VRM’s Personal Datastores, I discussed how we can decentralize information services by focusing on the user as the point of integration. Not only would that give the user direct control over their personal data–to the cheers of privacy advocates everywhere–it would provide a more robust, reliable, and scalable approach for important VRM use cases, including personal health care data, media consumption histories (and licenses), personal RFPs, and more.

Three replies sum up the curious or critical responses I’ve had:

• Matthias Gutfeldt: “But how do we do it?”
• William Hayes: “Any idea when someone will step forward to provide the user information mgmt service?”
• Dave Weinberger: “How does VRM (or Joe’s vision of it) differ from federated identity schemes in which the user has control over her personal info? “

I’ll generalize these into two focused questions:

1. What is different with VRM and Personal Datastores?
2. What will it take to implement them?

VRM’s Personal Datastores (PDs) are a new inflection of the familiar paradigm shift of decentralization

The answer to the first question lies in the recent advances in user-centric identity and the upcoming access-rights infrastructure built into XRI and XDI.

Limited versions of user-centric data stores have been around for decades. The PC revolution followed the same paradigm shift: put the applications and data on the user side instead of a central mainframe. The Internet itself echoes that user-centric view of the world, especially when you consider businesses as users and online services as vendors. Any architecture that moves data control from a centralized vendor to the decentralized user resonates with the user-centrism of Personal Datastores.

What decentralized systems don’t necessarily have–and what PDs add–is structured third-party read access to that data store.

Internet Email as Personal Data Store

POP, IMAP, SMTP–essentially all store and forward email architectures–allow independent third parties to input data into a simple user data store. That’s the point. An Internet-based email service that can’t accept email from anyone on the net, isn’t really Internet email. However, with email, there isn’t a way for outside third parties, such as vendors, to access that data store. The privacy reasons behind this are self-evident. Most people don’t want neighbors or “vendors” reading their email.

Blogs as Personal Data Store

Blogs, on the other hand, offer both input and output of personal data and move a little bit further along the spectrum towards a Personal Data store. Blogs are primarily output mechanisms; users write posts and those posts are published to the world. Comments provide an input mechanism from the “cloud” of arbitrary Internet users, giving blogs a limited input and output capability for what is essentially a publicly accessible personal data store.

The access rights management on blogs, however, leaves much to be desired–and is far from enabling many core VRM scenarios.

Access Limitations

Most blogs are simply available to the public–or occasionally to a limited “internal” audience by restricting access to the web page. A VRM data store should have extremely fine grained access privileges, including by “identity class” so that, for example, all legitimate Travel Agencies could access a personal RFP for travel or certified medical doctors who have registered an emergency medical situation warrant could access a personal medical history. These sorts of restricted rights mechanisms require not only the emerging user-centric identity technology, they require an institutional infrastructure capable of reliably authenticating “travel agencies” and “certified medical doctors” who have “registered a warrant”. Ultimately, a Personal Datastore must not only store the requisite data, it must provide secure and effective access to the right vendors and individuals, and refuse access to all others.

Input Limitations

Second, the ability to “input” into a blog data store exists in the form of comments, but it is limited. Sometimes this privilege is restricted by identity (using TypeKey, OpenID, or an InfoCard for example), but not always, and access is usually restricted in a simple way: for example, any InfoCard user can post a comment on Kim Cameron’s blog on any post. This is a good start towards identity-based access rights management, but most sites have minimal distinctions between different classes of users and different data sets. Of course, blogs are for blogging, so they don’t have a need for sophisticated access functionality. However, when you treat markets as conversations, VRM needs to enable conversations between users and buyers. That implies that users can, for example:

• Input data to their Datastore
  • RFPs (requests for proposals)
  • Customer Interaction Data
    • service calls
    • RMA requests
    • bug reports
    • reviews
  • Personal Health Updates
    • Symptom Reports
    • Doctor Visits
    • Medication Log
    • Exercise Log
• Amend/Revise Data
• Reply to Vendors (securely, privately)
• Manage data access
  • publish subsets of the data to specific vendors
  • publish to sets of vendors

It also implies that Vendors can

• Access subsets of the data
• Add new data to the Datastore
  • Prescriptions
  • Proposals in response to RFPs
• Update subsets of data (securely and with reciprocal privacy)
  • RMAs
  • Customer Service History
  • Revised/Updated Proposals

This also implies that data stored by the vendor should be protected from edits by other vendors and even users (although outright deletion must remain an option). It would be a mess if users could edit responses to RFPs or prescriptions directly. Rather, the integrity of the system requires a mechanism to assure that the data is what the original author intended it to be.

This level of access functionality is essentially non-existent in blogs. Other online markets provide some elements of these features, but none that I know of place complete control in the hands of the user, enabling any vendor (approved by the user) to participate. eBay is a good start; it definitely democratizes the vendor/buyer marketplace. However, you don’t control the types of buyers/vendors who can access your listings and you still need to use eBay to culminate the transaction. It will probably be a challenge for eBay to find ways to make money while putting the transaction context in the Personal Datastore.

However, it is worth noting that CompuServe and AOL faced the same conundrum with the Internet, struggling to learn how to profitably transition from a closed-loop system to an Internet that let anyone access and publish anything. Ultimately separate business models worked quite well with access providers (Earthlink, AT&T, etc.) and service providers (Google, Amazon, etc.). Meanwhile, AOL is still struggling to define its business.

VRM and Personal Datastores will likely create a similar segmentation of silo & service businesses into specialized vendors of Personal Datastore Services and those focused services that leverage PDs to deliver new value.

Blogs + ID access = Personal Data Store?

Blogs with Identity-based access privileges start looking like a workable Personal Datastore for some VRM use cases. Consider posting a Personal RFP (request for proposals) to your blog, with appropriate tags (travel, ready-to-buy, hotel, airfare, car), pinging a pingmarket service like Technorati, and receiving offers via comments to that post. If access to the post–and the ability to reply–were seamlessly moderated by a credentialing service (so only authentic “travel agents” could respond), then we start to have a system that could work. Vendors who subscribe to RSS feeds from the pingmarket see sales opportunities right on their desktop, not unlike Shopatron’s manufacturer-to-retail online distribution service.

This architecture highlights two additional requirements: first, how can we trust the claims of the user? Second, how can we (automatically) understand the requests (and claims) of the user?

Validating User Claims

VRM relies upon users making claims of various types:

• intention and interest
  • In the market for a new car
  • Buying a plane ticket
  • Looking for a home
• affiliations
  • AAA Member
  • Retired military
  • US Citizen
  • Member of the California Bar
  • credit card #
  • employment
• facts
  • Address
  • Age
  • Gender
  • Income
• certificates
  • Licensed to drive by California DMV
  • Insured to drive by BBB
  • Security clearance by US Federal Government
  • Credit rating by Equifax

Many vendors avoid wasting time with unqualified leads, including competitors and window shoppers, as well as individuals who can’t legally purchase the product because they are underage or excluded due to export control laws. In addition, the reputational history of the user enables Vendors to focus resources on the most promising buyers. Buyers with no history or with negative history don’t deserve the same VIP treatment that proven, reliable buyers deserve. We see this on eBay, but have no clear way to leverage our eBay reputation with other vendors. A VRM system would allow reputations of this nature to arise explicitly from multiple reputation vendors, and incorporate our transaction history across multiple marketplaces.

It will be a while before our institutions implement these kinds of authentication services, but it is already happening with the earliest “adopters” (apologies to Geoffrey Moore, in his terminology, these guys are all “hobbyists” even when multinational corporations). Sun Microsystems, for example, now validates employee claims so that third party Vendors can rely on that validation for providing services. With Microsoft’s CardSpace technology built into .Net and Vista and soon Active Directory… plus OpenID and Higgins open source solutions, the Internet identity infrastructure is somewere akin to the World-Wide-Web was in 1993 or 1994. Which is to say, about to seriously explode into corporate and mainstream consciousness.

So, to answer the first question, what is different with VRM’s PDs is incredibly fine grained control over both the data and who accesses it. Today’s federation systems actually move in the opposite direction by allowing a wider and wider system of vendors to access personal data with absolutely no control by the user. The result is, frankly, a culture where people hesitate to provide full or accurate information because of fears of what vendors will do with it.

Standardized VRM Data Types and Protocols

For VRM to scale beyond human moderated interactions–the kind enabled by Shopatron where retailers personally check the Shopatron website to select orders to “bid” on–we need a solution for automated understanding of user data. No, I don’t mean some mammoth Artificial Intelligence, natural-language-processing, all-knowing, all-dancing automated salesman. What we need a standardized way for people to make claims such that Vendors can understand them. This means a cross-Vendor open standard for structuring VRM data, including claims, RFPs, personal health records, etc. In some ways, this parallels the work being done by many many folks building the semantic web. If the original data is presented in a structured, commonly understandable format, then programs can have a reasonable expectation of “understanding” it in a useful way.

Currently, Vendors typically have their own internal data structures and formats. This makes it hard to move data from one system to another. Yet, that is exactly the power of the Personal Datastore, serving as the point of integration between multiple vendors, no matter who is sourcing the original data. So, if Amazon, BlockBuster, and NetFlix all want read/write access to my PD to better understand my media consumption history–and provide better recommendations based on that understanding–then all three need to be able to store the data in a mutually understandable way.

This is a huge problem. We are essentially talking about reversing the damage done at the Tower of Babel, of integrating a formal representation of all possible data.

HUGE.

PROBLEM.

Except if we look at it a bit differently. Taken at 30,000 feet, VRM’s PDs seems to offer a secure, universally accessible and universally understandable read-write data store. That sounds great. It also sounds like an insurmountable problem. However, by breaking the data types down into cohesive use cases–at 1,000 feet–we can start to package the PDs in a way that is implementable, scales with use, and provides high-quality understandable data to individuals and Vendors.

First, think of the PD as a fungible store of any kind of data. Built smart read/write access to that data using user-centric identity systems with third-party credentialing for “identity class”-based usage. The VRM is about vendor-customer relationship data, but once the infrastructure is in place, truly any structured data makes sense. (Unstructured data just acts like another ftp or web repository.)

Second, take real-world integration problems and solve them with relatively small, focused data formats and get Vendors to support those formats. For example, a standard media-history record that any vendor can read and write into our PD. Or a standardized RFP format, potentially with an extensible RFP type so that custom, structured information can be embedded in Airfare RFPs, retail goods RFPs, or service RFPs. By tackling real-world problems and working with a handful of real-world vendors, shared data formats that provide immediate value can be developed in a realistic timeframe. By solving each of these in an open-standard, open community fashion, a library of VRM data formats will start to emerge hand-in-hand with the VRM protocols that manage the creation, distribution, and consumption of that data.

You might think of it like MIME for vendor-consumer interactions. MIME is the Multi-media Internet Mail Extension. It was designed to allow email attachments of files like word documents and images. It also allows webservers to specify the type of a file being downloaded by the browser. In both of these cases, the underlying access protocols of SMTP/POP and HTTP don’t need to know anything about what is in the MIME attachment. Instead, applications use the MIME type to do the right thing once the data arrives. In the same way, a PD should provide an identity-based fungible data store where rich data formats of different types can be intelligently stored, accessed, and managed.

The result is a system that scales by adding new open standard data-types to the open data store, just like email and the World Wide Web scaled to support images, Flash, audio, and movies.

Access Rights and Responsibilities

Now that we have a technological infrastructure–and conceptually an institutional infrastructure for validating Identities and claims–we are still missing perhaps the most critical piece of the puzzle: the legal infrastructure.

In today’s internetworked world, there is astonishingly little control over data other than denying access. If a Vendor knows who I am because they bought my name and information from some mailing list company, they can–and do–bombard me with junk mail. They share it with other divisions or sell it to third parties. Some Vendors do have reasonable privacy policies, and I would be remiss not to give a tip of the hat to eTrust, which has done much to advocate in this area.

However, with the Personal Datastore we are talking about a massive restructuring of the scale and type of information that will be made available to vendors, and making it available at incredibly low marginal costs. Not only will Vendors need a viable system for appropriate use of that data, users will need to be assured that the data they put in their PDs is protected in a rigorous way, minimizing user exposure to spam, unwanted solicitations, fraud, stalking, and identity theft. Having personal data–such as your address–in your PD must feel and be at least as secure as entering that same information at the culmination of an online purchase.

Interfaces and Phishing

There are two parts to this problem. The first is the user interface for how a user securely manages their private or semi-private personal data. Largely this has to do with minimizing phishing attacks while assuring the user can feel comfortable with the correct vendors. Kim Cameron often discusses this topic and it remains one of the biggest security risks for user-centric Identity systems. However, VRM and the PD don’t address this problem, nor do I see them ever doing so. As with the rest of the user-centric Identity movement, VRM will build upon the work of others.

Access Rights Management

The second problem is controlling what happens to the data after it leaves the PD. Or, to put it another way, providing restricted use licenses to Vendors who access your data.

I’ve consistently attacked the language of the AttentionTrust and others when they discuss users’ rights in regard to our “attention data”. Many people assert that we, as individuals, own the Attention Data sprinkled around the Internet as we “spend” our attention at various places. I have yet to receive a satisfactory answer to my queries about what it means to “own” that attention data, as it seems ludicrous to me to assert ownership over things like website access logs at YouTube or our transaction history at Amazon. Clearly, the Vendors own that data at least as much as we do.

However, when we store data in our Personal Datastore, we do own it. What the AttentionTrust and APML get right is that by collating our Attention Data in a data store on our computers–or on computers under our control–we are creating a data resource that we do in fact own and control. It doesn’t make sense to then give up that control just to get a better ad from Amazon, does it?

It might. If Amazon were to legally commit to using that data only for presenting that ad. In general, it isn’t usually the immediate use of personal data that we find annoying. What annoys us is the indiscriminant use, propagation, or application of that data out of context and for unexpected uses. I don’t mind telling the bartender what beer I’d like–otherwise she’d have a hard time serving me–but it would be annoying if that choice was broadcast on a loudspeaker “Joe Andrieu orders a Guinness” and posted to the bar’s blog the next morning. Rules of etiquette reinforce these sorts of expectations in real-world society. We call it “discretion”. But until there is something formally restricting Vendors who access a Personal Datastore, we can expect them to use all information as widely and as creatively as they can profitably do so. The consequence is that many users will refuse to expose authentic data, undermining the whole system.

At the same time, we can’t expect every vendor to read, evaluate, and agree to a custom twenty-page licensing agreement for each Personal Datastore they want to access. Instead, what we need is a handful of simple, standard access rights contracts or terms that can legally bind Vendors who access our PDs. Fortunately XRI and XDI have this sort of access rights architecture built-in. However, the actual rights contracts which would use those access protocols remain to be written.

Here are a few rights that users might want to be able to secure for their data, as well as some privileges they could provide to vendors:

1. Reciprocity–That vendors who access a particular type of data also agree to reciprocally provide updates to that data. For example, I might let Amazon access my media history records if they agree to update it with my past and future media purchases at Amazon.
2. Non-propagation–No further distribution of the data beyond the specific services authorized. No reselling to third-parties. No re-use by other divisions.
3. Non-persistence–No retention of the data beyond the session of the current transaction. For example, an emergency room physician can access my personal medical history while I’m under his or her care, but he or she can’t store that data on any internal systems.
4. Anonymous Persistence–Data can be retained, but only if it is suitably anonymized and disassociated from the individual user.
5. Editable Persistence–Data may be retained by the vendor, but it must be editable and deletable by the user.
6. Anonymized Analytic Rights–Vendor has the right to query the PD at a later point for business or operational analysis, as long as that analysis ensures anonymity after the fact.*

*One of the main reasons companies retain detailed customer data is to analyze it for business improvement. Perhaps the product is doing particularly well in certain areas or particular demographics. Perhaps certain customers are having a particularly hard time with certain product features. I expect that many of the largest Vendors will be unable to support non-persistence or anonymous persistence unless they are allowed some way to incorporate rich user data during analysis time. One benefit of the PDs as a source for Vendor analysis is that if performed with non-propagation and non-persistence, it can provide secure, private access to a much broader source of customer data than customers are willing to give and Vendors are able to capture. By shifting this datamining from Vendor silos to Personal Datastores, not only would Vendors get richer, more timely, and more accurate information for their data mining, individuals would gain explicit control over the use of personal data which is currently entirely under Vendor control in their private silos.

We are already seeing quite a bit of activity by the large search Vendors to modify their own data retention policies to be more user friendly:

http://www.mercurynews.com/business/ci_6449050?nclick_check=1

What makes VRM and Personal Datastores different?

In summary, VRM is applying user-centrism to vendor/customer relationships in a way not possible (or not worth the effort) before user-centric identity platforms emerged:

1. Fine grained user control
   • the data
   • who can access the data (and how)
   • access rights and responsibilities for those who do access the data
2. Third-party validation of claims
3. Standardized meta-data schema for sharing data with multiple vendors

What will it take to implement VRM and Personal Datastores?

So, knowing what is different with VRM makes it pretty clear what we’ll need to achieve it:

1. A service and/or software infrastructure capable of offering users control over fungible, identity-accessed data stores. On the open source software side, look to OpenID, the Higgins Project, and Sun Microsystems (amid many others). I’m not yet aware of anyone offering PDs “hosting” services, but I believe we should see PD capable products within a year or two.
2. Institutional infrastructure of organizations providing claim verification services using the user-centric Identity Provider (IDP) architecture. The Department of Motor Vehicles, AAA, Equifax, eBay, National Association of Realtors. All are capable of providing added value for their licensed drivers, members, consumers, users, and Realtors, respectively, by being an IDP and enabling Relying Parties (RPs) to provide new services or capabilities based on validated user claims.
3. Legally binding, and tractable access rights agreements. Before users are comfortable sharing personal data automagically, we’ll need to wrap clear and enforceable rights agreements around our data stores.
4. Open standards and protocols for the exchange of use-case specific data. Within communities of interest, we need to forge common schemas so Vendors can easily work with data provided by others. There isn’t really a general solution to this problem; however, with focused “vertical” approaches, we can define how we share specific personal information across the Internet.

Closing

This is a long post. If you’ve made it this far, thanks for staying with me. =) VRM is an incredibly rich vein for innovation and I hope I have succeeded in exploring that a bit with you. As a focal point for new services, software, and initiatives, VRM provides both a clear moral framework–it’s about empowering the user in their engagement with vendors–and a clear bounds on our scope: reinvent vendor-customer relationships.

There is a lot of fertile ground for VRM… and a lot of ways that the same underlying technology can be used and applied to use cases outside the vendor-relationship context. Those applications will emerge and be delightful surprises as Doc Searls and the VRM crew rally and clarify the vision we see for a VRM future–and create the technology to bring VRM to market.

Hopefully this article has given some depth and concreteness to a few VRM concepts that have been in recent discussions, especially the Personal Datastore. The entire movement is still early in its gestation. No doubt, the ideas presented here will evolve to become something different than what we have started with and I encourage and invite you to join us in evolving VRM. This is an open community effort and we welcome your input.

Jeremy Zawodny of Yahoo!, recently asked Where to buy unlocked GSM mobile phones? perhaps unknowingly following in the footsteps of VRM (Vendor Relationship Management) pioneer Doc Searls.

I’m a big fan of Jeremy’s blog, even if that is where he introduced me to the most time consuming addiction I’ve had in years (thanks a lot Jeremy). It is a nice balance of professional and personal posts, useful enough for folks in the search business and authentic enough to feel like you know Jeremy and even come to like him. In short, an enjoyable and successful blog.

In his recent post, he asked:

I may be in the market for a relatively cheap quad-band GSM phone that can be used in various foreign countries. Nothing fancy. I just need something I can drop a SIM card into and make calls and maybe send a few text messages.

The trouble is that I have no idea where to buy one and what to look out for. I’ve seen some available on Amazon.com and, as expected, they seem to be all over eBay. Plus there are various on-line stores that seem to specialize in selling unlocked GSM phones to people in the United States. But I don’t know which are trustworthy.

So if you wanted a handy little Motorola or Nokia GSM phone, where would you buy it on-line? And, if you happen to have a preference, which phone(s) would you look at or try to avoid?

In case you’re wondering, I’ve been a Verizon (CDMA) user for a few years now and have no plans to change that. I’m just looking for something that’d be handy when I and others travel.

Amazing. This is functionally identical to Doc’s VRM Inquiry looking for a new phone back in November 2006:

Okay, I’m gonna ditch my Verizon Wireless account, and the silo’d-to-hell Palm 700p that goes with it (and not with other providers). The Palm is nice in some ways, but its too heavy, too crashy, too lousy at too many things I depend on. (Dialing, for example.)

So here’s my VRM intention-market gesture of the day…

I want a phone that is GSM-based (so it works overseas as well as in the U.S.), works across as much of the U.S. and Canada as possible (Verizon has been a disappointment in this respect), has a GPS, and has an easy-to-use UI. I don’t care about PDA functions, ringtones (I like the old Western Electric bell ring, though), or camera functions. I like keys that are easy to read and use, and an address book that’s easy to synchronize with a computer. It would be nice, for personal reasons (I work for Linux Journal), if it ran on Linux. I’d rather it not (for the same reason) run on Windows. Mostly I just want it to be a good GSM phone with a GPS. And I’m willing to let the GPS function slide, just to get a good phone.

And I’m ready to buy it.

So, who gets my money, and for what? (The Nokia E62 has been recommended, but I’m not sure the phone keys aren’t too small.)

Consider what these posts have in common:

• posted on high-traffic blogs
• written by sophisticated Internet power users
• requests for cell phone and cell phone vendors
• considerable detail about what they want and don’t want in terms of features
• lack of certainty about which product meets their needs best
• lack of certainty about where to buy that product
• a request for help from their readership
• customers ready, willing, and able to buy, right now

What’s fascinating to me is that both of these posts are clear VRM gestures well before any sort of VRM infrastructure is built to handle it. Doc’s worked. And Jeremy’s probably will also, because he has a large enough, friendly enough, and sophisticated enough readership to help him find a phone that fits his needs.

I know that two VRM RFPs don’t make a trend, but for them both to show up in my feed reader and be for GSM phones by sophisticated guys who know as well as most how to research and shop online… I believe it is a bellwether of things to come.

I’ve written a few times about the VRM personal RFP. From my view it is one of the “low hanging fruits” of the VRM world. Shopatron has already demonstrated a viable approach for turning confirmed orders over to a streamlined marketplace of vendors. Now both Doc and Jeremy are showing that even without that streamlined marketplace, for some purchases, just blogging a psuedo-RFP is better than the alternatives.

Many people have raised criticisms about personal RFPs.

1. People don’t want to do all that work
2. People don’t want to wait for responses
3. You can’t change vendor behavior
4. It’s too complicated
5. Vendors can’t handle open-ended RFPs
6. There’s a catch-22: without orders, no vendors. without vendors, no orders.

On the surface, these all seem like valid obstacles. But each one is either untrue or irrelevant.

First, for some purchases, people already do an incredible amount of work. I’ve interviewed a TV buyer who spent 18 months gradually, slowly researching his options before finally purchasing a new 42″ plasma TV. And it took a full three months after he was financially committed to buying it to actually settle on the model and vendor. Another interviewee spend 28 hours over four days researching travel and work options for teaching abroad. She knew what she was looking for, had plenty of experience, and found that this was the kind of research she needed and was willing to do to plan and create her trip.

Clearly, people are willing to put a lot of work into these kinds of purchases. These are complex searches. And it seems clear to me that there are a lot of these kinds of searches that could be made easier with the right tools, including VRM personal RFPs.

Second, there is no reason that a personal RFP requires any more waiting that submitting an HTTP request. Sure, some models of RFP fulfillment have a certain amount of delay, especially if vendors need a human to process the order. I don’t know the reason for the delays at Priceline, but at Shopatron this delay is effectively hidden from the user. Shopatron’s approach works because they have a fixed set of products and vendors–and a fixed price–where they can assure timely delivery: the delay gets eaten up in the shipping and handling rather than in the purchasing.

Once more scalable VRM protocols are defined, vendors will be able to participate in real-time. If Hertz, Avis, and Enterprise are all in the VRM marketspace, there isn’t any reason they couldn’t automate responses to RFPs for rental cars. It’s not automated yet, but then again, neither were any of the direct to consumer shopping services in 1993. The web changed all that, with realtime responses for product inquiries, orders, tracking, returns, and more. So, count on a large number of VRM RFPs creating responses in seconds, especially in well-established markets like travel and real estate.

Third, vendor’s behaviors change all the time. The World-Wide Web changed a lot of things. And so has Shopatron. While new innovations always face challenges the more they disrupt current practices, there are always vendors willing to be first movers if the payoff potential is large enough. There will also be vendors who will fight tooth and nail before they do business any different than what got them where they are today. That’s just part of the challenge. We not only have to find the right vendors, we have to find the right solution, the right way to communicate it, and the right way for them to say “yes.” That’s called sales. Fortunately, I can think of nothing more motivating to a vendor than a confirmed, qualified, and capable customer.

Fourth, it is becoming increasingly clear that people demand solutions to complicated problems. Of course, we want it to be as simple as possible, but we are well beyond the early days of the world wide web where people were learning how to click on hyperlinks. People have sophisticated needs and while the simplicity of the Google search box made a huge difference in how we surf the web, even Google knows they have to move beyond that. We know that getting the right answer can’t happen magically. We are decades away (at least) from mind-reading computers that distill basic needs into real-world products and services. Some how, some way, we must express our intent so that people can respond, even better if computers can respond automatically. The challenge is figuring out how to package RFPs like Doc’s and Jeremy’s without losing the ease, flexibility, and specific vagueness, boundaries that were clear but within which many options would work. The technical challenge is significant, but I don’t believe it is too complicated for users. Instead, I suggest that the solutions we’ve seen so far might be too complicated for users. Sort of like the Internet before hyperlinks.

Fifth, while many vendors can’t handle open-ended RFPs, that doesn’t mean the entire system fails. It simply means that that vendor can only respond to limited RFPs. An unnamed car rental agency responded to Doc’s presentation of VRM with the certainty that they could never respond to all the varied options that people ask for. Their inventory management systems simply don’t have that kind of flexibility. However, that doesn’t mean that they couldn’t respond to those RFPs that fit within their parameters or even respond to partial hits with proposals that clearly specify their limitations. When the waiter apologizes because the restaurant is out of your favorite beer, do you leave the restaurant? Not usually. A VRM RFP needs to enable a sales conversation to take place, one that affords vendors a chance to suggest partial RFPs based on existing capability and capacity. High-end vendors who specialize in custom, high margin requests, would be free to propose a solution that meets the full RFP. Ultimately, the user selects which vendor gets the order.

Sixth, this kind of catch-22 is actually a network effect. It is true that in the beginning there won’t necessarily be a lot of users to attract vendors and that as vendors start to participate, there will be limits on the types of products and services available. This is a catch-22. However, as new vendors join, it becomes increasingly attractive to customers. And the more customers, the more attractive it becomes to vendors. And when this is delivered in an open-standard, open-network environment, the runaway tipping point can happen quickly and in many different markets at once. So, rather than complain about the catch-22, find those seed markets where vendors and customers can readily see the value, and build services to connect people with vendors. There will be early adopters. In the right markets, those adopters will trigger a network effect that catalyzes the entire marketspace, just as the World-Wide Web grew from academia to technology markets to technologists to eventual mainstream adoption.

I don’t know if Jeremy realized he was making a VRM gesture or if he would even consider his post an “RFP,” but perhaps he will see this post and think a bit about how VRM is addressing something fundamentally new, and yet, incredibly close to what we people already need.

The $64,000 question: why didn’t Jeremy just search Yahoo!?

There’s a lot of room to go in search… and NONE of the current search providers–not just Yahoo!–could have answered Doc or Jeremy’s inquiry more effectively than their blog posts. In fixing that problem lies the hope of VRM personal RFPs.

What do you get when you turn proprietary data silos inside out?

Users in control.

Doc Searls has been advocating VRM for a while (here too). What’s nice about his thinking — in addition to the open source/open standards approach we’d expect from a senior editor at the Linux Journal — is that he’s working the problem through the entire technological spectrum:

I don’t think VRM should be confined to a browser, either. I think this is something that should work through a cell phone, a card, or any other device or representation that works for the individual.

Not only are the vendor’s silos being turned inside out, so are the technology and network providers’.

My mindset has been stuck in the browser, perhaps with an accompanying helper application that does nice things for users, but still basically software on a personal computer. At the core, SwitchBook’s innovation is useful in larger contexts, but it won’t start out that way. Our strategy in simple:

1. Make it work with current search habits.
2. Augment IE and Firefox.
3. Expand to other OSes and browsers as quickly as possible.
4. Push the underlying API and data format as an open standard.
5. Open the tool for customization as widely as possible.
6. Open source the code for “built-in” customization

But are we going to take the time now to make sure it works in cell phones or datacards or iPods or anything other than a computer? There just isn’t enough bandwidth for that in a bootstrapping startup.

Fortunately, Doc’s VRM work as a Fellow at the Berkman Center gives him the freedom to invest in a solution of that breadth. A VRM solution that is bigger than any one company, technology, platform, or medium. Say goodbye to the silos.

It has also given me a fresh way to think about Complex Search. Much of VRM — as I understand it — is designed to be automagic. Specify your needs, receive bids from selected/qualified vendors using a tool that makes it easy to manage those relationships. But before one can specify needs, most people need to spend time discovering their needs. For all but the simplest purchases, that’s a Complex Search.

For example, take Doc’s latest VRM “Gesture”

I want a phone that is GSM-based (so it works overseas as well as in the U.S.), works across as much of the U.S. and Canada as possible (Verizon has been a disappointment in this respect), has a GPS, and has an easy-to-use UI. I don’t care about PDA functions, ringtones (I like the old Western Electric bell ring, though), or camera functions. I like keys that are easy to read and use, and an address book that’s easy to synchronize with a computer. It would be nice, for personal reasons (I work for Linux Journal), if it ran on Linux. I’d rather it not (for the same reason) run on Windows. Mostly I just want it to be a good GSM phone with a GPS. And I’m willing to let the GPS function slide, just to get a good phone.

That’s a mouthful. Doc is famous enough in the blogoverse to get feedback without the VRM infrastructure. He may not have a vendor make an offer directly (although a smart vendor would seriously consider sponsoring Doc), but he’ll probably get enough direction from peers to narrow down his vendor choices. With a fully operating VRM, the fulfilment side of that gesture will be streamlined and automated so that any vendor who wants to can cost-effectively make Doc a competitive offer, perhaps even a bundled package that leverages their unique value-add. That will take a lot of work, but the potential value to everyone in the transaction is clear.

Compare that to the broad, politicized, unfocused brush strokes of the AttentionTrust and you can see why I think the AttentionTrust goals are still too blurry and ambiguous to generate much success. VRM is working with Intention. It is highly focused. Its output is clear. The benefit to users and vendors is evident. AttentionTrust is stuck thinking about everything, all the time, and only online, then mashing that into some anonymized goulash from which magic is supposed to emerge. Bah humbug. I’ll believe it when I see it.

I think Doc is on to something, though. The Internet so radically drops the costs of so many different modes of communication, it will continue to restructure our society for another couple of decades, at least. Most of the success to date has been based on one-to-many marketplaces, such as Amazon or many-<aggregated-as-one>-to-many marketplaces such as eBay. VRM lets us create inverted “many-to-one” markets. Markets of one. Make your gesture, create a market. That’s powerful.

And yet, Doc’s gesture — as every request for bids must — also contains a treasure trove in the form of Doc’s requirements, a wealth of needs Doc learned the hard way. He’s a power user with heavy demands and he pushes technology to its limits. He is fed up with his current options and, having experimented enough, he knows just what wants. But he’s lucky to have that experience. Most people have no idea what the deciding factors could or should be for the products they want to buy. (Can you say megapixel?) Doc is anything but a typical consumer.

Consider what it was like when the web started taking off in 1994/5/6. At that time, I was out selling Internet marketing services and helping companies figure out what to do online. Overwhelmingly, time and again, smart, capable, professional people asked “How much does a website cost?” Well, what kind of website do you want? Their question was inherently non-sensical, but people didn’t understand that yet.

First, you have to figure out what you want, then, and only then, can you send out an RFP to get bids on it. Sure, you scale your RFP based on what your budget is — and unless you have deep pockets, it pays to be prudent in what you include in your request — but at the end of the day, only a detailed specification provides enough direction for vendors to submit a bid. The result of these conversations was often a small strategy and/or requirements engineering contract to distill their needs into just such an RFP.

So how does that work with VRM? How do people develop enough expertise and understanding of their needs so they can present a request like Docs? How does VRM work for regular folk?

In short, they search. They explore. They learn.

From friends. By reading reviews. Going to various manufacturer’s and vendor’s websites. By learning from people like Doc, either through blogs, reviews at CNET or ThisNext, pricing at PriceGrabber, Google, or through direct conversations. By trying out products. Even from advertising and retail stores. I happened to learn about Verizon’s data services in the Verizon store. Imagine that.

This is Complex Search. People aren’t going to rely on any one vendor or reference point, unless they have an absolutely trusted guide like a brother or daughter or college roommate to point them in the right direction. They are going to check out different sources, browse multiple websites, collate and corollate a lot of information from a lot of different places. Then, after they have searched and narrowed their needs down to the details, they can put it in the form of a digital RFP and see the power of VRM kick in. Zing! A Market of One.

VRM is still evolving. Questions and answers of many varieties must work their way through the community, from people’s and companies’ needs to draft technological frameworks, APIs, protocols, and working code. Good stuff.

Somewhere in there, I’m confident Complex Search will meet VRM and lots of real value will be created for people, vendors, and innovators alike.

Doc will be at the Identity Workshop in early December to discuss VRM and Identity with all comers. It should be a great opportunity to figure out where VRM is headed and how we can contribute. I hope you can make it.