Storytelling: Product Versus Process

Posted on | July 30, 2009 | View Comments

During a discussion in my Social Media class at Northern Kentucky University, we veered onto a topic that is helpful in framing the idea of The Cult of Me: the difference between “product” and “process” storytellers.

The idea of the story as either a product or a process, I think, is instructive because it depending upon how you classify what you do, that story will manifest itself in decidedly different ways. The way that you think about both the gathering of data and the transformation of that data into information will determine how you believe the presentation should happen.

And it’s the philosophical bent that you have about those three idea that will determine how you approach The Cult of Me.

Here’s a basic framework for how Product stories look:

The product people are those who believe that their story — their idea — is self-contained, meant to be protected and distributed, meant to be controlled by one author (although “one” could be a collaborative effort, but there is still a central authority figure) and conceived and delivered in that linear, Beginning-Middle-End structure.

These stories can manifest themselves either as linear stories (e.g. newspaper stories, press releases, ect) or interactive stories (e.g. Flash-based “click-through”) stories. Either way, the philosophical idea of these stories demand a one-to-many presentation, where the feedback comes AFTER the creation of the story.

The presentation then requires the community be built on top of — or around — that linear or interactive story. There will be comments, share functions, track backs. The product story is meant to be a commodity, one that sits at the center of the conversation that other folks have.

While there is talk of feedback, it’s not distributed feedback that encourages an evolution of that story. It surrounds it.

Here’s a basic framework for how Process stories look:

Process stories are tool dependant, allowing communities to create and form around ideas that well up from the community. They are not meant to be started for finished, although certainly moderators, editors and writers can steer communities through conversation and linear and interactive stories.

These tools — aggregation, sharing, friending, personalized design, audio and video tagging, embedding — will allow people to easily pull content they have created in other areas into one location (or multiple locations) using software. It’s a self-publishing tool, for instance, that would enable someone to post a video to YouTube and designate that for syndication on a separate site.

These types of tools don’t exist in mass form, yet, mind you. This is the description of what a distributed story should look like. But — by hand — you can create this. We’ve seen small aspects of this happen with Twitter hashtags, for instance.

When the Iranian presidential protests began, people used the #iranelections hashtag to create a searchable stream of data (which, on Twitter, also included presentation in the form of conversation as people re-tweet and respond to each other directly in the stream). This is one of the better examples of what a distributed story might look like, at least with one tool.

But a truly distributed process story would have multiple tools, used by many people, in various places, all syndicating out. So that other people could grab their data and publish it on their own site.

In this process world, certainly linear and interactive stories will come from here. This is where editors, writers and community managers use their Product stories to direct, call attention to and fill in the gaps. And, when done well, certainly spark new tributaries of data gathering off the original story stream.

How it all plays out:

As we explored this idea of Product versus Process , the basic premise of the cluetrain manifesto became clear as it relates to storytelling.

Those who believe in a protected, linear (or interactive) environment will have a difficult time existing on the Web because that philosophical idea goes against the very fabric of the Internet and Web culture. It assumes that there is one entity that is always right that can guide the conversation.

Those who produce those stories, though, have that idea ingrained within them. (Newspaper and magazine folks, for instance, talk of having a dialogue with their readers. But I think most would readily acknowledge — or I hope they would — that there are far more robust and interesting conversations happening outside their sphere. And if they don’t believe that, you can be certain they are Product people).

What this doesn’t mean is that Product stories are worthless. They are, in fact, meaningful in two ways; they are the directed line into the stream for people who aren’t operating in real time (meaning, who aren’t reading every new data point as it flows in) and they can fill-in missing gaps, provide context and subtly direct the conversation.

This is, though, second-tier importance. Product people who approach the stream with that ingrained sense of self-importance will create poor communities that are destined to fail (and thus, fulfill their prophecy that distributed storytelling can’t work).

To build a distributed, process organization of storytelling means that the value of the stream must be built into the fabric of the company. The development of tools. The creation of moderator communities with rules. The integration of the distributed networks and the linear and interactive stories.

It takes a swallowing of ego. To understand that Product importance still exists, but it won’t be forefront. You attain respect and build community by providing value out, not demanding attention in.

Comments