fantasy founder - relationship management is engagement management

Continuing an occasional series about products and companies that I’d like to build or see built someday.

There’s a natural cadence to communication. We meet or talk or email or txt or whatever. And we do it over some topic, even if it’s just catching up. The mixture of who we are to each other, the last time we connected, how often we connect, and what we connect over plus our personal contexts (and some other stuff) make up how much of an impression is left and for how long. At least for a moment, you get to front of mind. 

Nothing new there. We can maintain different sizes of connections in our brains. Social butterflies are great at wide swaths of shallow relationships. Most people are good at small numbers of deep relationships, bigger number of casual or business relationships, etc. See Dunbar.

But social networking and freelancing blow all the numbers away. How do you both organize the people you want to keep in touch with and maintain the connection? How do you deal with the fact that relationships wax and wane and change?

• Personal social networks let you organize people and give you the updates about them that are prompts to connect
• Professional CRM systems let you organize people and track communication for the purpose of getting someone through the funnel and keeping the money flowing
• Professional social networks (taking LinkedIn as the only example that matters) don’t really do either
• Contact managers let you organize people
• Communications apps let you connect
• We need to keep track of who matters to us and why
• We need to keep track of when we talked to them
• We need to remember to talk to them again
• We need to be true and authentic to actually have real relationships (nothing’s going to do that part for us!)
• We forget to stay in touch with people we want to
• We want some relationships to grow
• We don’t care if others drift off
• Some relationships change without us even noticing

So what do you do? Actively manage relationships? There’s prior art here: Nimble, Mingly, Contactually, fellowup, Promptivate, CRUMBtrail, Highrise, Google Plus, ICQ (way ahead of it’s time). And I pitched the idea a few years ago to ___, which didn’t work out. But the idea of personal relationship management hasn’t really taken off. Everyone either charges too much, doesn’t have a functional enough (or any) free tier, or is just a poor man’s CRM.

The things I want:

• Integration with email, messaging, contact lists, social networking for both comms recording and metadata acquisition
• Inferring relationship tiers in terms of depth and frequency of communication, but not assigning any meaning—example: you talk to someone infrequently but consistently, which might mean a great old friend or a casual connection you see at a conference every year
• Arbitrary tagging or categorization, because real life is full of Venn diagrams
• Indicators that say, “hey, you’re normally in touch with this person every week and now you’ve dropped off to every month.. is that what you want?”
• Reminders that say “hey, you’ve said you want to be in touch with this person every week, so go talk to them”
• Unobtrusivity
• Refusal to turn into a CRM replacement, integrate with SFDC, Marketo, etc.. if it gets to that point, make another product**
• Freemium, with either a contact number limit or some feature based limitation

**And now it gets interesting. There’s a generalized application here, that for some reason is missing. In a world of SaaS, social networks, and mobile apps—the same relationship persists between the app and the user. Any user has some attentional budget and the same cadence of communication applies with the app. We call this “engagement”. The same ideas and algorithms that are needed for a good PRM would work well for a kind of engagement management (EM). You could set engagement targets (this many high value touches a month, that many low value touches a week), infer engagement quality and relationships status, prompt the user to engage, prompt the app to engage, prompt sales/marketing/account/whatever to engage, etc.

Added Feb 12th: P.S. The CEO of Nimble got in touch after reading the post. Check it out. Although it is targeted at professional use without a fremium model, it does go a long way towards what I'm talking about here. 

provided vs exposed

If you're offering infrastructure as a service, you have to have infrastructure to offer and it has to be exposed.

But if you're offering something else, then:

The infrastructure doesn't need to be exposed, THUS you don't need to have it.

Examples:

• You offer VMs, so you need to expose VMs, a management console for VMs, and (hopefully) APIs to connect to and operate them
• You offer a runtime, so you may or may not have VMs--but who cares since what you need to expose is the runtime, a management console for that runtime, and (hopefully) APIs to connect to and operate it
• You offer an application, so you may or may not have VMs or a particular runtime--but who cares since what you need to expose is the application, a management console for that application, and (hopefully) APIs to connect to and operate it

It gets a little more complicated when someone wants to build something else on top of what you offer. Then they probably want and/or need more exposure to, and more control knobs for, the underlying stuff.

Basically, this is what makes IaaS (specifically VMaaS) different in kind from anything else. 

What you provide guides what you expose dictates how you can build.

What you've built limits what you can expose dictates what you can provide.

the three cloud questions you have to answer

The bit about 3 lines in "what we don't know about private cloud" seems to be making sense to everyone I discuss it with (end users, vendors, investors), so I've reformulated it as a set of questions.

Taking an application portfolio perspective.. looking across the entire set of apps you run, you have three decisions to make:

1. Of that set, what do you NOT want to develop or run, period?
2. Of the remaining set, what do you NOT want to develop or run on your own infrastructure?
3. Of the remaining set, what do you NOT want to manually provision and have manually requested?

The consensus on these questions, if one ever emerges, will produce the actual (vs pick-your-pundit's projected) terraforming of the tech landscape.

what we don't know about private cloud

This is not one market, it's a hundred (or hundreds of) markets. There is no real big pattern to where the inflection points are. There are lots of little patterns.

We do not know:

• The line between what applications we will run and what we will totally outsource to SaaS
• The lines between what we will leave bare metal, what we will virtualize and what we will actually run in any cloud
• The line between what we will do on a public cloud and in a private cloud
• The degree, magnitude, and timescale of how "virtual private cloud" and "hosted private cloud" moves those lines
• The degree, magnitude, and timescale of how various approaches to cloudifying "legacy" apps via encapsulation, migration, replicating, etc., moves those lines

These lines are being drawn in different places by everyone--including similar orgs by sector or size or whatever and also by different groups within the same org.

Add to that the range of things that are called "private cloud"--everything from "I have a data center with some servers in it" to "I've built my own EC2, EBS, S3, ELB, SQS, and SNS with open source software on commodity hardware and can automate ALL THE THINGS".

Here's something I do know: any number put forth for private cloud market size, growth, or spend is utterly daft.