Personal Relationship Manager
Tristan Louis coined the term “personal relationship manager” in a brilliant post on his blog. With his kind permission, we’re adopting PRM to cover much of what we’re building at FWD International. We’d been searching for a descriptive phrase to describe what we’re up to; Tristan nailed it. Not only did he come up with the right phrase, he also wrote a cogent and complete description of what a personal relationship manager should do (we’ll quietly add any features we missed to the development schedule).
“What I want is a view of my relationship with people that would group:
- The basic type of address book information available in my address book and/or on my PDA and/or phone.
- The rich email discussions I have had with said people
- The similarly rich IM discussions I have had.
- SMS or MMS discussions synched from my phone.
- Social Networks interactions
- Feeds for the person (to things like their blog, their last.fm account, etc…)
- Trackbacks and other blog related discussions.”
Note that Tristan is talking not just about contact information but the full richness of his social graph. Some of this came up in the recent discussion Matt Blumberg, Brad Feld, Phil Hollows, Jeff Pulver, Fred Wilson and I had about the future of messaging.
Here’s a list of the features Tristan would like just in the contact part of the PRM:
- Integration of my address book across different email services
- Integration of my address book across different IM services
- Integration of my address book across different social networks
- Integration of my address book and mobile and VOIP solutions
In the full post he also gives his requirement for conversation and status info as well as means of input. In his programming section he suggests both a rich set of APIs and decentralization because no one wants so much information to be concentrated. These are both parts of our plan as well. In fact, we think that most users will be exposed to our PRM capability through apps written by developers who take advantage of our APIs. Our plan is to link current information, not to aggregate copies of data which will quickly become out of date.
Thanks, Tristan.
Comments