I’ve been very fortunate to have been able to spend some quality time lately with folks much smarter than me – and while that seems to be the case more often than not, it does get my little mind turning. One topic that keeps popping up is “the crowd” – mainly, the definition of “crowd,” and what it means for product development.
Crowd is definitely a buzzword in the context of product development and social computing. Certainly, some credit for the conversation is due to Quirky, a social media-savvy, self described “Social Product Development” company based around the idea of crowdsourcing product ideas and then bringing those products to the market. Admittedly, the concept is pretty cool – you suggest a product idea (for a fee), it gets voted on, passes through various stages of approval and, if it’s lucky, becomes a product.
When I heard about Quirky, my first reaction was that they were going in the absolute opposite direction of “Social Product Development” as we think of it. After all, crowdsourcing in its traditional interpretation seems to be more about finding an alternative to your product development team than finding ways to enhance it. Wikipedia defines crowdsourcing as “the act of outsourcing tasks, traditionally performed by an employee or contractor, to a large group of people or community (a crowd), through an open call.” Now, if my title includes anything related to product development, this definition might make me a bit nervous. And if I’m a manufacturer, I might fret about a brave new world where crowdsourcing rules and innovation is outsourced. After all, creative IP developing solely outside of a company seems to bring with it some inevitable questions about competitive differentiation.
So, I asked a few questions. First, is crowdsourcing really the greatest area of potential value that social can bring to manufacturing? Second, are the concepts of crowdsourcing and Social Product Development really that divergent?
Well, for the first question, fret not manufacturers – you’re probably not going to be replaced by homegrown inventors anytime soon. Why not? Well, let’s assume the widest possible definition of crowd, to start. Crowds on their own aren’t always the best drivers of innovation. Henry Ford once famously said, “If I had asked people what they wanted, they would have said faster horses.” The crowd tends to think at a compartmentalized feature/function level – but responding on the feature/function level risks commoditizing your product and potentially strapping you with a hypothetical car that looks like it was designed by Homer, not Henry. And secondly, crowds aren’t always the best predictors of success – if I remember correctly, there was a lot of excitement about Google Wave around this time last year.
The core assumption of crowdsourcing is that you are choosing the unqualified crowd over a skilled product development team. It’s not by accident that companies appoint really smart people to important R&D positions, build teams around them, all over the world, and anoint them with the obscene power to get people to do whatever they want. Okay, okay, so maybe that last line should be edited to read, “…get marketing people to do whatever they want.” But I digress. The point is, each member of your product development team was most likely carefully selected based on their strengths and expertise relevant to their job role. You hire your experts for a reason – you think they’re the best at what they do. With this in mind, it makes sense to me, at least, that you can find more value by using social computing to give these experts additional tools.
But what if we change the definition of crowd? I asked IDC’s Mike Fauscette what he thought. Mike recently co-authored a report called Product Life-Cycle Management and Wisdom of the Crowds, so he’s a pretty good guy to listen to:
So here’s where Social Product Development and crowdsourcing do agree – people are important. Social tools allow a wider pool of people to contribute to product development. And widening the pool of people that can contribute to product development can have a positive impact. The key for Social Product Development is defining and qualifying your crowd, perhaps by granting or limiting access, creating relationships between contributed content and contributor experience and skills, or establishing communities of practice for functional-specific collaboration.
But I think there’s one other crucial difference between crowdsourcing and Social Product Development that bears mentioning. That difference is ownership. Crowdsourcing implies giving up ownership of tasks, processes, and decision points by moving them outside of the company and into the crowd. Think back to those smart R&D folks – even when you change the definition of the crowd, I still want those R&D folks to have control. So, in my view of Social Product Development, you may still use web 2.0 tools to invite feedback from your customers, partners, cross-functional team members, and others within your defined crowd, but your core product development team has the freedom to decide how to incorporate that feedback. If we think back to the Ford quote, this level of control allows your team to capture the user request of a faster horse, interpret it as a customer requirement for increased speed, and use the understanding of that requirement to drive development of a solution that the crowd didn’t see coming. And THAT is pretty cool too.
So what do you think? I’m pretty grateful for the car, myself.
And yes, as you may have suspected, that’s not the only question I asked Mike. I’ll blog about a few more of his answers coming up next, and then make the whole interview available for download.
The original post has an embedded video. Can’t see it? Pop out and go here.