The Barrier to Social Technology Adoption in Product Development

Over the past couple of years, the application of social technologies in the context of product development has been discussed quite a bit. I've written about many software provider's efforts to include social technologies in their offerings, including Vuuch not just once but twice, PTC and Nuage. There are also offerings out there from Dassault Systemes, Autodesk, OneDesk and TeamPlatform. I am sure there are others.

The reason why I'm writing about social technologies in product development today, however, is because of a post I ran across a little while ago.

Meaning is the New Money

That's the title of the post  written by Tammy Erickson over at HBR. Yes, I know. It didn't make much sense to me either. But I'd been following Tammy's post for a while. So I gave her the benefit of the doubt and went past the title. Turns out, she had some interesting things to say about social technologies… without saying social technologies.

Over the last year, I've been doing a lot of research on how organizations will need to evolve to meet the demands of the 21st century. The central premise of this work is that new technologies, most of which have appeared only within the last decade, greatly amplify our abilities to interact simultaneously with large numbers of people. The frontier of human productive capacity today is the power of extended collaboration — the ability to work together beyond the scope of small groups.

But doing this successfully turns out to rub up against a number of assumptions that are deeply embedded in the ways most organizations still operate today — assumptions that are no longer valid, but are so deeply buried that we fail to question whether or not it makes sense to do things the same way.

This is where I think Tammy latches on to something relevant. I believe a lot of people see the promise of social technologies in product development and think there must be value. But as you'll see in Tammy's next point, realizing that value may not always be viable.

Working in a world of extended collaboration asks individuals to contribute through a different and, in many ways, more complex set of activities. Workers must deal with rich content that flows through infinite links. Individuals must make intelligent, well-informed decisions about what to share with whom (and what not to) with less guidance from the hierarchy to simplify the patterns of interaction. And they must dig deep within themselves to form innovative ideas and put their best thinking forward.

To a large extent, the conduct of these activities is not something managers can prescribe or even monitor. Unlike process-based work, in which the goal is to perform synchronized tasks consistently and reliably, extended collaboration occurs asynchronously and is often aimed at discovering or developing something new. Rather than requiring everyone to be in the same place at the same time, extended collaboration can occur virtually. In process-based work, quality can be assured through in-process inspection and performance judged on conformity to process specifications, while the quality of collaborative work can typically be assessed only by the results achieved.

This simple premise, I think, will be one of the most important determining factors in whether or not social technologies are adopted in product development environments. However, I don't think there's a blanket conclusion we can draw. Instead, I think the success of this kind of technology will depend on the application in which it is used.

Process, Procedure or Ad-Hoc?

What kinds of applications? Well, interestingly, I've seen a wide variety of people talking about using social technologies in different aspects of the product development process. Let's look at each and figure out how process driven each is.

  • Product Conceptualization and Ideation: This set of activities in early in the lifecycle is used to generate, mature and ultimately select a product concept that will then go into product development. While many companies tend to not formalize these activities, there has been quite a bit of movement in making this far more of a regimented process with specific sequenced steps. Given that, and Tammy's thoughts above, then it's no surprise that this is an area where social technologies have been most successfully deployed in the product lifecycle.
  • Engineering Collaboration: What happens in detailed design? Many would refer to it as a maelstrom of chaos. And in reality, it probably needs to be that way. Engineers need to explore wildly different design alternatives and iterations. That's part of the design process. As a result, the activities they need to conduct can change from day to day. This discovery part of product development tends not to be regimented, other than meeting hard deadlines in the schedule such as building prototypes, testing and most certainly design release. As a result, social technologies have and probably will continue to struggle for wider adoption in this part of product development.
  • Engineering Knowledge Management: This initiative is all about codifying and documenting the design and product knowledge that exists in the engineer's heads in your organization. For those that take this sort of effort on, it tends to be fairly formalized. Topic areas tend to be targeted. Discussions ensue to come to consensus on the guidance that should be documented. Then it is documented. For those that formalize this effort, my opinion is that social technologies can thrive as I have written in a prior more detailed post titled Are Wikis the New Engineering Knowledge Management?

Summary and Conclusion

OK. Let's recap.

  • Tammy Erickson published a post at HBR titled Meaning is the New Money. My takeaway point from her post is that unlike processes, collaboration is ad-hoc, and as a result is more difficult to deploy change.
  • Based on that premise, I believe that social technologies can be successfully applied to Product Conceptualization and Ideation as well as Engineering Knowledge Management because those are two areas, that when adopted, become more regimented and process driven.
  • Additionally, I believe that engineering collaboration has been and probably will be ad-hoc in nature. That's part of the exploratory aspect of engineering. As much as I would like it not to be the case, I think it will be difficult to change and adopt new tools like social technologies in the context of engineering collaboration.

Those are my thoughts folks. What are yours? Do you agree that change is harder to adopt in areas that are not process driven? Do you believe that social technologies can be successful in engineering collaboration? As always, I'm interested in your perspective.

Take care. Talk soon. And thanks for listening.