Process of Change : innovation

Integration first? Maybe -- but have you done your homework?

bobreb — Thu, 26 Jul 2007 19:16:02 GMT

Recently I found myself wondering about a comment from Sean discussing the order in which an organization should implement web 2.0 features.

Sean's answer was this:

"So, what’s the answer? Simple (simple to say, not do). The answer is none of the above. The most important feature to implement in your web 2.0 strategy is integration with existing systems and processes."

Sean is likely assuming you've done your homework. What I mean is that the what feature question is not the first one to ask.

Unless we're only discussing technical architecture, not user experience, the first thing you have to know is the readiness of your audience. The new "social" requires new behaviors. New behaviors are very costly to introduce. Has your audience already developed these habits of thought and action in any area directly related or not? Can you springboard from that? If not, do you understand what relative advantage participation provides and what personal cost your users will incur obtaining it? If the cost justifies the personal investment, it's time to demonstrate and educate.

If it's not entirely clear what features you should do first -- and the competitive situation could easily dictate a starting set of tactics -- I say think big, but start small. Experiment. If your customers must learn new behaviors, consider embedding the new into the old such that the old still works, but the new is clearly visible. Adding tags to existing support forums might be one example -- though not the least expensive.

If you can go where the audience already is, and you can do it credibly, that could be best. Experimenting with someone else's infrastructure has its good points. (As an aside, I believe there are ways of using existing third party investments without "going there" yourself, but that's beyond the scope of this post.)

In any event, wrap a simple program around the technology: incent the behavior; make the results observable; reward the participation; and, watch (measure) and learn.

Significant infrastructure investments are risky and therefore, appropriately, require evidence. Proof through analogy only goes so far. First hand experience with your customers is the best evidence.

Diffusion Rate Fly-by -- Customer adoption of social networking

bobreb — Mon, 07 May 2007 04:36:00 GMT

The factors influencing the rate at which any given innovation spreads throughout a population are well known. Applying those factors remains a bit of an art, but the exercise is always instructive. That's especially so when we start thinking about marketing investments.

The single best source of information on this subject, imho, remains Rogers' Diffusion of Innovations. Although I've been told recently that Rogers has been challenged in some circles. I'd love to know more about the proposed alternatives.

Diffusion of Innovations, 5th Edition
by Everett M. Rogers, Everett Rogers

Read more about this title...

Overall we consider these things:

The attributes of the innovation
The nature of the culture
The nature of the decision
Change agent impact

Let's look (very) briefly at each of these with regard to how they apply to Microsoft customer adoption of online social networking services.

The attributes of the innovation are relative advantage, observability, trialability, complexity, and compatibility.

Relative advantage: this should be a big plus for us. Adopters will have distinct advantages in terms of domain knowledge generally, and it's currency specifically. Over time this expresses itself as fewer surprises, less downtown, greater productivity.
Observability: This one is harder. You have to be in close proximity and observe an adopter over a period of time to observe greater productivity due to improved knowledge acquisition. And the activity that leads to the improvements isn't highly observable itself. Therefore, we're going to have to increase observability. Contests, for instance, wherein the most connected people are provided observable rewards, come immediately to mind.
Trialability: I don't know if this is an immediate plus or not. Everything we do is immediately trialable, but for compatibility reasons the success of the trial is questionable. Until we've had a chance to deliver the "social network placement" services -- aka subscription services -- ease of trial could be a problem with some people quitting when benefits aren't immediately (first week or two) apparent. Greater knowledge takes time to accumulate. Finding the right feeds takes time to do. As we simplify entry, this will be a big plus, but until then it may well cut the other way. Perhaps this suggests improved tutorial/getting started material?
Complexity: Another problem for us here. While not exactly complex, it is different. We've found that even understanding weak-tie networks as community is something the uninitiated have a very hard time understanding. Once in, however, it all seems so natural. It's the initial bump however that's tough.
Compatibility: Jeez, another problem. To most people using a feed reader is just adding more information to the already too long list of things to read. Microsoft's technology professional customers are mostly in the 35+ category -- me too, btw. That means long established work habits and corresponding habits of thought. Social systems are easily picked up by the under 30 crowd. The trick then, as we've always imagined, will be to integrate the new services into the traditional applications in a way that makes them easy to consume.

The nature of the culture here might just help. Information workers generally, and technology professionals specifically, remain effective as long as they have access to the right information at the right time. Therefore, they have an enormous amount to gain picking up the new tools. Because technology changes as often as it does, "new" is not as horrifying as it might be to some information workers. The pace of technology change may make it conceptually easier to jump into the new tools for the technology professional.

The nature of the decision is interesting in this case. No government is going to mandate participation. And not everyone has to play for the game to be productive. Further, we're already past the need for a bootstrap solution. There are already enough players to get things going for anyone that wants in. I say this is a net neutral -- maybe a positive.

Change agent impact is a wild card cause we're the change agent at the moment. We don't currently have budget, and we're still figuring out how the new organizational reality we face is going to effect us -- could go either way in the short term, though I don't think it can be anything but positive in the longer run. But do we need marketing budget? Part of me likes to spend money. And I do think spending money could accelerate adoption -- it could certainly raise awareness. On the other hand, no money forces us to be creative. We like that part of the job the most. Another part of me thinks there might be another change agent in the works...

That's just a very quick look. I can imagine expanding any of the above considerably. But it's a start.

Ever used this model? Got a better one?

Crossposted, as always, on theworkingnetwork.

Tags: innovation socialsoftware community

Extreme Product Management

bobreb — Sun, 03 Dec 2006 03:02:42 GMT

Dave’s one of the guys on my team. He’s the Tagspace guy – among other things. A recent post of his fairly expresses some of what we’re experiencing as we define our “product manager” jobs in the context of a team pursuing an Agile development methodology. Do check out his post. In it, he points to Scott Bellware and his views regarding the value of product managers. Dave focuses his comments on the “voice of the customer.” My two cents follow:

It pains me to say that I agree with Scott on many levels, but must disagree with his conclusion. At the same time, I think you (Dave) understate your role vis-à-vis the "customer" and the development of software.

The means of software development, in fact, the means of accomplishing any series of related tasks is eventually expressed in a more or less fixed process – at least traditionally. Two problems emerge. The first is the misapplication of the process. In other words its application to problems that are not sufficiently similar to those that gave rise to the process/methodology in the first place. And the second is the fact that all processes, or paradigms, have a lifespan. The first and second are often related in that misapplication tends to happen with greater frequency toward the end of the life of a particular paradigm. This occurs because of the very real fact that there are fewer problems to which it applies, and perhaps worse, lives (or at least careers) have been built around successful corporate contribution within the context of a now failing paradigm. Exhausted processes are applied by people that only know how to work one way. Many of them are product managers. However, just as many are software developers, and program managers, and public relations specialists, and general managers, and VPs, and whatever.

In any case, some things will remain true: what needs built will have to be determined, and then it will have to be developed. When it comes to things that are broken and need fixing, we need the voice of the customer. When it comes to innovation, we need more than the voice of the customer -- we need his imagination, his deep understanding of the situation well beyond appearances, his knowledge of relevant trends, his understanding of historical precedent, his appreciation of business relevance, his willingness to consider alternatives, and his willingness to experiment, to risk, to ask the wild and shocking questions, and to keep pushing forward in the face of old paradigm complaints and threats. And then the distillation of all that must be expressed in code.

Should developers do all of that? Hmm, perhaps today and perhaps to some, the answer to that is yes. But as a person that has focused his career on enabling, refining, extending, and enhancing the ways and means by which people discover one another, form community, and solve knowledge problems through association, I think that is a rather narrow view and one that is largely without merit. (Yes, I'm aware of the Google model -- or at least the mythology that surrounds it -- and I stand by my view that "developer only development" is largely without merit. Lots of things are shiny when you first bring them home. Maintaining the luster is another matter altogether.)

You, Dave, are a product manager in title, but you are also researcher, planner, and business development manager -- oh yes, and designer, and project manager, and agile business owner, and whatever other hat needs wearing. You're a recently evolved breed of product manager at Microsoft. Perhaps we should call you an Extreme Product Manager.