Hi Doc,
This seems not quite right for me and the problem is rooted in historical baggage. The majority of today's commercial computer architecture and the nearly all legal and social norms that govern it were conceived and nurtured when the only way to amortize he cost of entry was across a massive customer base. You can spend $1M on a mainframe when you have a 100k customers, 1M listeners or 10M viewers to spread the cost over.
Now that individuals have the compute power to run commercial-quality apps, and open-source has reduced the cost of such apps to near zero, we want the world we *would have* built if individuals had possessed these things back in the late 80s, early 90's. Doing so would break a foundational assumption underpinning today's digital infrastructure and commerce. Stakeholders in the ecosystem built on the premise that we do *not* have such tools would be massively disrupted. Even for the VRM-friendly vendors, the threshold of entry into VRM for a business isn't just about customer relationships. It's about surviving when coopetition regresses to aggressive competition and all their peers are trying to vote them out of the house and off the island.
There *is* an element of scale here but not because technology allowed businesses to scale. Rather, technology seeped first into businesses that were already operating at scale. But there remain fundamental differences of scale between businesses and individuals, regardless of whether we have VRM. None of those large-scale businesses regularly initiate meaningful contact with each of their customers. They operate on a many-to-one pattern and communication is either all customers (marketing blast emails) or almost none of them (individual customer support contacts). The bulk of communication is outbound broadcasts to customers who, despite being "known" through their accounts, are effectively anonymous since they all see the same thing.
On the other hand, individuals can contact all or nearly all of their vendors. There are some tasks in common across many vendors (i.e. change of address) but these are the exception. There are some routine tasks associated with account maintenance such as bill paying, but even if we automated these they are contain a high degree of dynamic customization. The overwhelming majority of our meaningful communication with vendors is 1-to-1 and bespoke at each occurrence. VRM won't change that and I don't believe we'd want it to. The vastly reduced cost of compute, storage and bandwidth has allowed technology to permeate down to non-scaled individuals, not that individuals are scaling up to take advantage of computing. This is as it should be. Human scale is 1-to-1. We don't want to tailor humans to the needs of large-scale computers. We want to tailor computers to provide value at human scale.
The concept of leverage is closer but only when leverage =/= scale.
When tech delivers the benefits of collective bargaining without the formal collective it's leverage. This example may be as close as we get to scale as depicted in the featured image on the blog post. In this case the vendor can resolve intent from a large, virtual, ephemeral market and modifies their product offerings accordingly. Unfortunately as VRM goes it's the least compelling use case since only those whose intent clusters at the top of the Bell curve benefit.
When tech brings the cost of offering mass customization down to near zero so I can specify *exactly* the product I want, that's leverage. The product now offers millions of permutations of config options but I'm still only buying the one car, computer, or pair of sneakers.
When tech shifts the balance of power more toward the center and away from the vendor (rebalancing) it is leverage. We like to think of this as scale since the power the vendors enjoy has always based on scale and now we have that power too. But in truth that power derives from reducing incremental transaction cost to near zero. That the economics now work at individual scale is not the same as individuals having scale.
When tech shifts the balance of power more toward the customer and away from the center (tipping) it is leverage. Individuals acting independently may open new markets or topple old ones, but short of an organized boycott or action group that isn't scale. Some scaling effects emerge but as individuals we aren't conscious of it any more than the bee is conscious of the hive mind in which he participates.
The statement "Encourage development of tools by which individuals can take control of their relationships with other entities" is all about leverage and naught to do with scale. And it's not wrong. But now that I've told you what I think VRM isn't let me offer thoughts on what I think it is:
In a nutshell, I believe VRM is the realization of Enterprise-quality ubiquitous transactional computing for individuals.
Personal computing was first about entertainment. Then it was about works of authorship. Then it was about personal business management. What it has never been about, what VRM promises to deliver, is real-time transactional processing. It's the personal CICS platform that extends Supply chain Management that last mile to our door. It's our bank reselling ACH services to individuals the same way that larger banks resell ACH to mom-and-pop banks. It's standardized transactional data formats and protocols that work at individual scale and meet the business requirements of operating at individual scale. (Which is a completely different set of business requirements than individuals operating at scale or businesses operating at mass scale.) It's the commodities exchange providing a single market across many vendors (global cart). It's the API of Me that allows me to offer transactional services to the world. While these sound like different things, they are all just different patterns built on real-time transaction processing.
Unfortunately, we can't just install CICS and start porting mainframe apps because those were designed for 1-to-very-many relationships and don't meet the needs of individuals. Nor can we scale up to take advantage of the existing enterprise software. That's why if the goal is real-time transactional computing, the prereqs often overshadow it. VRM isn't about security but if easy security isn't there we have to shoulder the burden of delivering it for our real product to be viable in the market. If only 50% of the population can run our software without getting hacked it's a problem. By business standards, having 50% of the population as customers is a massive success. That asymmetry works against us specifically because we *don't* scale.
Similarly, non-VRM IoT devices are hard to replace without making the provisioning as simple as a Nest or a Drop Cam. That's not easy if the device's idea of phoning home is to contact its owner instead of the vendor. Like security, VRM isn't about the provisioning experience but if what we need doesn't exist it's up to us to shoulder the burden of providing it. Same with questions of local hosting, preserving sovereignty with vendor hosting, disaster recovery, portability, availability, etc. These are all prereqs for VRM, not what VRM is about, but things we have to deliver in forms consumable by individuals of varying skill before the real VRM thing we want to deliver is viable.
The result is that if I'm not careful when explaining VRM to newcomers the project often sounds bigger and more confusing than it really is. These days I just say VRM is Enterprise-grade ubiquitous transactional computing for people. Nothing more, nothing less.
Your mileage usually does differ (where "you" doesn't specifically mean Doc but definitely includes him) so take this with a grain of rock salt. It's just me disliking "scale" enough to offer USD$0.02 worth of alternatives. ;-)
Kind regards,
-- T.Rob
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
An issue is a perception that vendors and customers are "different". At different times we are vendors and at other times we are all customers. We are vendors when we sell our time or give away our attention for something "free".
When we are customers we want vendors to look after our data. When we are vendors we should look after our customer's data.
What is missing from much of the discussion is protecting organisation vendors from their customers who are happy to give away the details of their relationships. In other words, the systems we build should be symmetrical. We as customers want our data protected. We as vendors should protect our customer's data. VRM systems should protect vendor's data as well as protect customer's data.
Somehow the idea that we are all in this together (the Commons) needs to be included.
A work in progress. But see if this isn’t a better way to frame ProjectVRM’s purpose than what people have found hard to remember for almost ten years so far.
I’d explain more but I have to get on a call.
--