Or, It's the People, Stupid

Just stumbled across this as I was browsing around looking for something interesting: Charlene Li's post "Web 2.0/social computing explained, thanks to Common Craft."

The video itself I think hits the right notes in terms of demonstrating the value of social media, such as bookmarking tools, to the uninitiated. If I had my druthers, I'd put together something similar in rolling out a suite of social networking services in support of enterprise communities, whatever the context.

Strikes me, too, that in this Brave New World of ours, we've got to break the mold of corporate-speak and do what we can to humanize, as Josh Hallett suggests elsewhere, the ways that companies relate with their customers. The long-term impact on the "bottom line" could be enormous, if we really begin to think about business in terms of relationships where both parties benefit not just from the primary business transaction itself (item or service bought/sold), but also from how they connect as people, whether on a professional or personal level.

Malcolm Gladwell of Tipping Point and Blink fame illustrates this point well. He asks, who do you think gets sued more often for malpractice? The doctors who make the most mistakes? In other words, those who are technically the most incompetent? Nah. It seems that when physicians err or are perceived to err in their practice, the most important factor that separates the sued from the non-sued is whether or not their patients like them. Yes, that's it. It seems that people like to be heard, like it when doctors take time with them, and like to feel like they're understood and cared for. Imagine that people could have such an expectation!

Now abstract this observation and connect it to the software business. Surely, if we want to talk seriously about "winning the hearts and minds" of <insert audience here> or changing perceptions about <insert product or company name here>, it doesn't take much effort to see how important it is to focus in on creating real and meaningful relationships with and between customers.

Of course, you may say, no company of Microsoft's size, for example, can scale in such a way as to have "meaningful" relationships with every single customer. That could mean hundreds of millions (if not more) individual connections. But here we can benefit from network theory--that is, the power of human, social networks to make a difference in people's lives, or more aptly, in the way they connect with the companies whose products or services they buy and/or use.

We are at Microsoft some 80,000+ employees worldwide, per the latest figures I saw in the newspaper or perhaps in Directions on Microsoft. Each one of us is surrounded by a web of connections, some personal, many professional; some very close, others more like acquaintances. Each one of those people is connected to their personal and professional networks.... and so on, until eventually, it becomes possible to be virtually connected to everyone on earth, in varying degrees--"six degrees," by some measures.

We don't have to know, nor should we even try to know, more people than we as individuals have a capacity to know without losing all value in our relationships because we have too little to give any one of them. We've only got so much energy to spread around, after all. But with what energy we have, we can have a personal (albeit indirect) impact on many, many more people by virtue of the interconnected networks that extend outwards from each of us individually. Add to it the influence and impact that all of those people can have on one another, and you begin to get a feel for the potential of business strategies that make community engagement and relationship building--not just "customer relationship management"--ineluctable components of success.

I think that if we take the time to build relationships with our "patients" and help them help each other and themselves, in the long run it will be the greatest of differentiators in the marketplace.

- dave

del.icio.us tags: social_media, Gladwell, network_theory, social_networking, marketing, relationships

Last week, I had the opportunity to speak to a local group of folks who are into software product management, an organization called the Product Management Consortium. My interest in this group was sparked last year when I attended the UW Extension program on software product management, several of the instructors for which ran or were on the board for the PMC. I'm not yet a full-fledged member, mostly because I don't yet want to drop the required chunk of change for the membership fee, but so far my experience from attending three meetings is that it is very useful forum for those interested in expanding their awareness and opportunities in the burgeoning local software development scene.

The general topic of the meeting was "advanced agile product management," with Bryan Stallings of Solutions IQ leading things off with his low-key but abundantly experienced perspective on some of the more nettlesome questions that product managers invariably face when they undertake an agile project. Deb Rakow, a recent hire at Microsoft brought over from VeriSign, followed with a talk on overcoming both individual and organizational resistance to adopting Scrum. I was invited to share my experience with agile methodologies in my tenure as a product manager for the MSCOM Communities Team (which has been absorbed by the MSDN & TechNet organization), most recently on the Tagspace project.

Feeling Fr/agile

After hearing both Bryan and Deb give their spiels, I admit I was a little unsure whether what I had to say to the group would at all be useful or compelling. Bryan's contribution made it clear to me that our experiences with XP and Scrum were anything but pure in their implementation; he was also the acknowledged expert in the room whose impressive and lengthy list of accomplishments in Agile might make anyone feel just a little bit insecure. What's more, Deb seemed to steal some of my thunder on the difficulties of agile adoption and the importance of communication and tenacious, cajoling team-building.

But what could I do? There I was in front of this group of knowledgeable and experienced individuals, and I sure as hell didn't want to look like a total ass.... So I did the only thing I could do: I started flapping my arms frantically and ran screaming from the room, which caused no small measure of discomfiture among those in attendance.

Stand and Deliver 

Ok, in reality it didn't go quite like that. In fact, I gathered my thoughts and simply told my story, sharing the good, the bad, and the ugly of my experience over the past few years--the successes, failures, ambivalent outcomes, lessons learned and what wisdom I might've gleaned along the way.

More specifically, I talked about team structure, roles and responsibilities, using the classic team model of the Microsoft Solutions Framework as a starting point (Microsoft Solutions Framework, "MSF Team Model v 3.1"):

As you can see from this graphic, the classic Microsoft view divides the world of product development between a business focus and a technology focus, the product manager leading the way in the former regard, and the program manager in the latter. I understand that in the broader industry, where roles might not be quite as specialized, the program management and product management aspects are covered more often than not by one person, the "product manager." I thought this was an important point to make because my audience was comprised of folks from many different companies who may not have been familiar with the way Microsoft slices and dices its product management roles and responsibilities among multiple contributors. 

I then drew a comparison with how agile teams can be imagined, using a diagram I found on a blog post by Levent Gurses on "Distributed Agile Development":

The important point here was the emphasis on the customer as central to all roles in the scheme, with project managers and business analysts being the primary leaders and requirements conduits for the development team (represented in red above).

Neither model, to my mind, really described well the structure of our team, so I conceived an adapted team model, which effectively combined what I felt to be the most important elements of the previous two:

One of the main points I wanted to make here was that whatever the formal titles may be, whoever works as the customer proxy (or "on-site customer") needs to work very closely with the product owner--the two are essentially respective sides of the same coin, and projects can rise or fall on the strength (or weakness) of their relationship.

I then went into process and artifacts, providing some examples of the kinds of documents I used to help get the project focused and on track so development could begin and we could all be clear, by virtue of our shared understanding and goals, of exactly what we were trying to accomplish. I also made sure to let my audience know that our efforts overall did not result in unalloyed successes, but the fundamental point was that we learned a lot, worked very well as a team, delivered good business value, and even--dare I say?--had fun doing it.

Keepin' It Real, Yo

And that, my friends, was enough, as it turned out. I definitely got the sense that the audience appreciated what I had to say, the story I had to tell, even if it wasn't the perfect project executed perfectly, a perfect exemplar of agile product management. I did my best just to be myself and, um, "keep it real," as the cool kids are wont to say. Several people complimented me on my presentation, and I could tell that the reason it succeeded was because I had managed to communicate in such a way that they could relate to it personally, based on their own varied experiences, feelings and fears. The lesson I draw from this is that, even if we can sometimes feel insecure about our experiences and accomplishments in this brave new world of ours, sometimes it's really the journey that matters, and it's the sharing of it with others that makes all the difference.

- dave