VRM development process

Christopher Carfi makes a good point about VRM over at Social Customer [excerpt]:

Immediately diving into code is going to take us exactly down the same path that CRM did, and focus on the technology, instead of the people…

Before diving into creating a new technical spec, step outside and look around a bit.

Don’t reinvent the wheel. A lot of this work has been done, and can be leveraged.

Christopher goes on to introduce some great sources of prior work, such as a EDI, and RosettaNet, including sharing a chart with a few trademarked items.

I agree that there is much to be leveraged and learned from prior work, although I am a bit wary of the IP regime at RossettaNet, mostly out of ignorance but fueled by the little circled ®s and tiny ™s. Any clarifications, Christopher?

Although I introduced the concept of a digital or personal RFP, I think there is a whole lot of thinking that needs to go on here before we actually start production code. But, to me, prototyping is thinking, or at least one way of thinking about and and exploring a solution to a problem.

Christopher again:

Remember that little “R” thing in the middle of both CRM and VRM? The one that says “relationship?” Finding a better way to have vendors compete solely on price does not a relationship (or even a conversation) make. It’s simply a different way to do transactions. (My thoughts on the “transactions to communities” path here, from August, 2005.)

Absolutely. The question of how such relationships can be manifest in a way that contributes to an open marketspace is an research question that I’m looking forward to working on with everyone in the VRM community.

Part of what is exciting about VRM is that it is clear that part of the value proposition could work today with a simple personal RFP mechanism using nothing more than XML or semantic HTML, tagging and pinging. We could add XRIs and open identities and create some bounds of privacy that would make it more viable for discrete transactions. This wouldn’t really address the full goal of inverting the CRM paradigm, but knowing that some of the key use cases could be addressed so quickly is energizing.

Exploring a few prototypes helps catalyze thoughts and deepens our understanding of what we want to actually accomplish. Kudos to Whitney for his work on the Firefox Plugin. Prototypes are about exploration; they aren’t production code and as long as we connect the prototype to innovation based on feedback and lessons learned, they are good thingsâ„¢.

I, for one, embrace the mindset of other successful Internet development efforts:

Rough consensus and working code.

So, in response to Christopher’s “Whoa, cowboys,” I say, “Giddyup, doggies!”

Now, about that consensus part… 😉

We have a lot of questions which would benefit from conversation and consensus building before we can expect an interoperable system to emerge. (Although I do think the pieces will emerge before they are interoperable, hence the interop part.)

1. What does it mean to invert CRM?
   • What principles will be realized in a full VRM system?
   • What is it like for customers?
   • What is it like for vendors?
2. What canonical use cases should a VRM system support?
3. What systems/technologies already provide similar or partial solutions?
4. What would a complete system look like from a conceptual view?
   • Entities
   • Services
   • Communications
5. What would are the requirements for each of those conceptual components?
   • Interfaces (both technical and GUI)
   • Protocols
   • Formats
6. What implementations could fulfill those requirements?

This is exactly what I’m hoping to discuss in a few weeks at the VRM Developers Meeting in Redwood City, CA on January 25th. Christopher will be there, too, so I’m looking forward to getting some of these things on the table. I don’t think the process is necessarily going to be as linear as going through that list, but it certainly should be entertaining.