Check ‘em out: www.chumby.com

Is the phenomena known as “Social Software” ready to be decoupled, or opened up? I’ll go on record saying “No”. Why? Well, for one, because everyone else is saying yes, and I like to be different, but more importantly, because “The Theory” leads me to believe that.

I could be wrong, and that’s OK. I may even be trying to apply the wrong theory to this particular phenomena. I want to inspire thought and conversation here.

One reason I may be wrong, is that software is much better understood then it was just a few years ago, and is behaving much more like modeling-clay in the concept car studio, (thanks in part to better software management and thinkers like [Joel Spolsky] and others) so a software capability may be able to decouple parts of the value chain while leaving other parts available for optimization.

So give this a read and join the conversation in the Comments section at the bottom.

CONTEXT:

(this should roll over the screen in Star Wars perspective fashion along with some tympani music)
We’re living in a brief period of time, where something is particularly new, scintillating and possibly rewarding. Groups of people have learned to use the Internet to communicate remotely with one another and to do it in a variety of manners which have collectively become known as “Social Media”.

Blogs have popped up to discuss it, software has been written to enable it, groups have researched it and people from all walks of life have gravitated towards it to exploit it for business and pleasure. It’s becoming a marketing channel unto itself where , a practical way to affordably interact with people not in your immediate proximity, and according to some, for people to generally waste a great deal of time, which people tend to be quite good at.

[Google] has launched a capability into the marketplace called [Open Social] which promises to level the playing field by offering a standardized way of interfacing with parts of the system. It’s made an “Open Standard” which developers can all use which may lead to more and more people writing software which will live under their sphere of influence.

Are we ready for that; that’s the question.

A LITTLE THEORY:

OK, so what’s this “Theory” and why is Joe poo-pooing the latest industry darling?

I’ll explain, but first off, how about a show of hands from everyone who’s read at least one of [Clay Christensen]’s books… great, that’s not bad; smart group.

Well, for the rest of you, and for those of you who read that stuff and just didn’t get it, I’ll do a quick run down of a couple of Clay’s theories. I’m not going go on here about how incredibly smart Clay is, but just to say I had the pleasure of having WR Hambrecht as one of my anchor clients years ago and was lucky enough to have some of his mojo rub off on me.

The Theory: Offerings (I’ll use the term “Offering” to describe products, services, or a blur of both of them) typically move through their life cycle from being “not good enough” to “too good for the average user to appreciate”. As they move along, they usually do this through a process called improvement.

Users have a set of needs that they hire a product to do. When a product doesn’t meet these needs, the Users has a couple choices: Pay more for a better product, or suffer with an inferior set of capabilities. Usually, unless that user is particularly sophisticated, they stick with what isn’t good enough and welcome the Offering’s “improvements”.

At this stage the Offering isn’t great, and the User isn’t very happy. This is really o.k., because it primes the pump for improvement. It forces the provider of the offering to work its pants off to get better before it starves &/or goes broke. This mandate (survival) forces it to make it’s improvements at any cost, including that of ignoring any standards or the need to cleanly integrate with any of it’s associated components. I’m not going to go into this, though I give practical examples in my speaking engagements, and if you buy Clays books you’ll get plenty.

Suffice it to say, when an Offering isn’t good enough, it pushes its way upstream by designing and engineering whatever it needs to. The only way it can really push the envelope is to optimize itself in a proprietary manner. This is fairly expensive, because everything in the offering has to be hand created – you can’t be proprietary and use generic parts at the same thing. The good thing, the customer is willing to pay a premium for these offerings at this stage, because the potential is so exciting, and the proprietary architecture usually makes them highly optimized, and really special – think of Apple vs. PC in the early days of personal computers.

What happens next is quite interesting. The Offering keeps moving upmarket and eventually moves North of what the customer needs. At that point the average customer isn’t willing to pay more for new features they’ll never use anyway*, and the really sophisticated users have what they need, but their wants elevate; they want customization, speed, reconfigurability.

At this point, it’s no longer profitable to do everything themselves; no one’s paying more for the improvements (this by the way, is what’s called becoming a “commodity”), so the business has to look elsewhere for leverage – to modularity (and other OE techniques).

The big takeaway here is that the converse of this is just as true: if you modularize too early, you sacrifice the ability to push the envelope. It’s why concept cars are designed in clay, and not built on the factory floor… The optimization of the system is what’s important when that system is still not good enough.

WOW, ENOUGH THEORY:

So, where does Social Media and Open Social fit into this?

I think, based on this theory, and my reading of the market, that Social Media is not good enough yet, and is therefore too premature to benefit from open standards. Host applications (like FaceBook and Pownce and others) need to keep their systems (called “Containers” in the field) highly optimized so all these busy developers out in the wild can continue writing add-ons that are tightly coupled to their specific set of capabilities.

Now, it’s possible that the Containers are in fact good enough and it’s time for them to standardize at least some segment of their interfaces so that the Subsystems (the Widgets, or whatever you want to call them) can get more proprietary and drive more value.

Now, there’s one aspect of the The Theory (he-re we go again) I didn’t mention, and that’s that if a market entrant (in this case Open Social) as attacking a segment of the incumbents business model which is important enough, the incumbent will fight, and usually win, especially if they have momentum. And, if it’s not perceived as valuable enough and the incumbent let’s it go, they usually get eaten alive as the market entrant increases the scope of their new offering (which, yes, eventually becomes commoditized and gets disrupted by something else)

Either way, it’s a great position for Google to be in as it drives the decoupling of other systems which will be built on their framework and is just bound to drive value in a more egalitarian fashion. If it doesn’t drive a massive API battle so there are multiple competing specs it may make life easier on a few developers, but I’m not going to rest my chips on a square saying we’ve got it all figured out so soon.

What do you think?

*based on a macroeconomic principle that goes something along the lines of “the marginal value of a product or service adjusts as a direct reflection of the marginal utility”

This also extends into the Community play of for transparency and value to the customer, as nicely codified by Geoff Livingston in his article on “The Seven Principles of Community Building”

In addition, it’s really nice to see a company like Forrester using YouTube to distribute their talks.

[youtube:http://www.youtube.com/watch?v=oU7WuBRzOlY]

Hey Hugh, it’s me, Lawrence. I gotta talk to you about this new open standard that’s going to revolutionize the way we drink: It’s called the Dixie Cup.

It’s really great. What we’ve done is wax coated a plain old paper cup, and now it’ll hold more types of beverages… it’s almost universal! I mean, from Grapefruit Juice to a Gin and Tonic, this thing holds up. It’s going to change the way companies think about distributing and consuming fluid.

Right out of the gate we have agreements from Rubbermaid, PG and Acme Co to modernize their fluid distributions to be transitionally contained by this exciting open standard, and Saul’s working on a logo as we speak.

We also see an expanding market for dispenser apparatus; think about it: every house in America with a Dixie Cup dispenser in the kitchen. You could show up at a party with Dixie Cups and KNOW they’ll fit in the hosts dispenser apparatus.

Oh yeah, we turned the cone shape into a flat bottom to increase lateral stability thereby extending its intra-usage utility. Ted’s doing some R&D around optimal radius to metacentric height ratio to maximize stability.

It was when I was doing a freelance gig, producing the online version of the 1996 Bank of America Annual Report (kindda ironic, as that’s where I work now), and after showing my client the usual four tiers and types of pages the site would comprise, and getting them approved, and going into production to grind out a couple hundred pages just to have the client (yep, that was you, Cliff ) say:

“Blue… could we change all those table headers from grey to blue?”

That I said “enough of this hand-coding, I’m learning Frontier”, and too this very day, having seen millions spent on all the usual commercial CMS products bought and projects wither, having tried out most of the Open Source CMS’ and having spun more then a couple of my own, Frontier still has the nicest metaphor of object hierarchy and inheritance of any I’ve used.

It’s just a shame it’s throwaway knowledge as the scripting syntax and database are not standard. Someone should reproduce the Frontier style of publishing, but using AMP (Apache, MySQL, PHP).

And EVERYONE should donate to Dave’s fund!!

/Joe

My Dad used to say that he had an unparalleled skill at creating errors on “those Web forms” which he didn’t even realize were called forms.

Cliff and I used to produce a bunch of securities trading applications for clients – first at Wells Fargo (an early, heck, maybe the first “Wells Trade site) then later a couple for WRH+Co. People were always tempted by “wireless solutions”, that is, transporting all those fields and buttons onto a screen the size of a match book. Cliff was fond of saying “our customers already have a wireless interface, and it works quite well; It’s called a Cel Phone and their human voice. When they want to make a trade, they call their broker and make a trade”.

Now, blogs, or micro-content distribution systems are getting into the voice game. Utterz let’s you call in a plog cast by phone… you dial the phone, you speak your mind, your voice shows up on their site – for now, without wanting to investigate their version of an interface, I’m going to assume these files can be accessed, syndicated and sliced and diced at will, like any well behaved pile of web content.

What could be really interesting out of this is to be able to post-facto reassemble a conversation, perhaps including multiple people. To be able to follow the train of thought that get’s spread out over time… perhaps months, and follow an articulate thread… from your iPod, from your networked audio player as you drive across country.

Return to English (or, insert your preferred native language here).

/Joe

In the next 5 chapters I’m goign to describe the 5 phases of design: Discovery, planning, design, execution, and follow-up.

Imaginable.

Think about that word for a minute.

Imaginable.

Not experiences we know how to build… Not even experiences we know.

Just great experiences which will make people say “that was amazing! I want to do it again, and I’m going to tell everyone I talk to about it.”

And I don’t worry about who’s getting the credit; whose “incentive compensation metric” is getting boosted, ’cause that kind of thinking leads to the siloed brain-rot that drives disintegrated experiences that customers hate.

The most amazing experiences: that’ what I’m going to work on.

It gets even better, when a programmer and a designer discuss working Agile methodologies, and gets even better when they have varying appreciations of what exactly agility is.

Designers love to have an open canvas to paint on. They hate to define requirements if it’s going to constrain their designs in any way. They seek agility so they can say “well, we’ll through some stuff up now, and refactor it later.”

Programmers of course see the aspects like “stories are agreements between business and production” ideal places to get formal definition of what they should spend their time on. They do need that… we all need that. Spending your time on low value things isn’t pleasant for anyone, and one of the big contributors to dissatisfaction.

Business folks tend to think of agility as the ability to add and change requirements whenever they want with little to no impact on dates, quality or resource commitment… the eternal “pick any two” triangle. Nothing’s changed.

Of course, there’s a balance to this. Those who have balanced agility with structure have done so after hard knocks in dealing with the different perspectives of business, design and business. One of the inevitable benefits of Agile Methods is getting these all too often separated groups talking together, sharing goals and speaking in English together earlier in the process, before it comes to blows at QA time!