Crowdsourcing with CAUTION !!

A lot is being said about "crowdsourcing" almost everyday, and more and more entrepreneurs are jumping onto the crowdsourcing bandwagon. There is however, need for caution.

Just as the banking and financial services industry in the US jumped on the sub-prime lending bandwagon leading to the crisis we face in the world economy today, any "fad" needs to be taken up with caution. This moment of economic crisis should teach us not to evaluate options based on short-term gain, but do a careful evaluation of its long-term implications before taking it up.

I have been evaluating crowdsourcing with respect to the design of software products, which is my area of work, and I would welcome suggestions and more thoughts on this.

Design broadly consists of four major phases:

1. An initial understanding phase, where a designer employs various tools at her disposal to understand the needs of users of the product and society in general,

2. A second divergent ideation phase, where ideas are generated,

3. A third convergent phase where the final solution is chosen, and

4. A final implementation phase.

One can package this in many different ways, but the essential activities in design will typically conform to these four phases.

It is the second phase of ideation, that typically holds the potential of being crowdsourced. If you are creating a product or service and need ideas, it does make sense to crowdsource. The ideation phase is afterall a divergent phase and you need to explore. You can hire a consultant and pay money to do this exploration or use the crowd for free to do the same - either way you will need to explore ideas. There is just one small glitch - you will end up getting a lot of ideas that are grounded in different contexts and not in the context your business might be oriented towards. This will happen, because the crowd will typically not have done the first phase of understanding your users. You will therefore need to sieve through the ideas and take those that fit your context, when you move to the next converging phase of arriving at a solution.

Therefore, in the third phase of converging towards a solution, you will need expert advice. A deluge of ideas from the crowd can be overwhelming, if you don't know how to sieve through them and you might end up losing your way, and even going away on a tangent that is detrimental to your business model. Therefore, for the third phase of arriving at a solution, you will need an expert designer to bring all the ideas together and connect the dots, using tools and experience at her disposal. Crowdsourcing will provide you with "opinion", but you will need "informed opinion" to make decisions.

Similarly, in the first phase of understanding user needs and studying it in the context of society and the business, you will need an expert who can use the necessary tools at his disposal to capture these needs with the right amount of empathy and understanding, both of which take years to imbibe.

Again, in the final implementation phase, you will need an expert to plan and implement this design - it is a fine balancing act of all the constraints at hand, and comes only with training and experience.

Crowdsourcing enthusiasts, whom I have read so far, seem to be so gung-ho about cost savings in the short-term, that they seem to have ignored all these aspects in their espousal, and this can be dangerous. Traditionally, not having done enough home-work upfront has meant doing multiples of that work down the line - cost savings upfront is a myth that results in more expensive rework later with much pain and hardship as well.

As I see more and more entrepreneurs and enterprises jumping onto the crowdsourcing bandwagon to get design done, I am concerned. I worry that this mad rush will leave most entrepreneurs with burnt fingers and products with lost opportunities that can affect society adversely in the long run. Creating and supporting the creation of good products is not an obligation, but it is necessary for the well-being of each and every one of us. We don't need an economic recession to tell us, that we were wrong - we just need to be positively careful about the choices we make.

Since the fundamentals of product design, apply to all other forms of design - organizational and social - I am of the opinion that the application of crowdsourcing needs to be done with a lot of thought.


(Photo Credit: Christopher Augapfel, Flickr)

The "more is less" paradox in Product Design

Last Wednesday, as part of our "Design Discussions" session, my team and I watched the "Paradox of Choice" lecture by Barry Schwartz. We had watched Barry's talk before but we loved listening to the talk again.

While the whole talk is relevant, one area that is particularly relevant to Product Design of Software is "Capability vs. Usability". Barry opines that customers buy a product on its "potential" or "capability" and its only later, during usage, that they become aware of its "Usability". He goes on to make many more important points that include the point that customers know that the usability of the product is not the same as its capability, and yet many products are bought on their mere capability. Now this is very significant if we extend and evaluate the way we design and sell software products. I know that Product Managers face the dilemma of whether to build features at the risk of feature-overloading or spend effort in keeping the product simple and useful, while road-mapping for their product and I think the "Paradox of Choice" should provide them the starting point to apply to Software Product Development.

A simple way to think about it in the context of Product Development of software both for the enterprise and the individual consumer is as follows (these are just my initial thoughts and I am still trying to wrap my head around it - i am hoping comments from readers will provide more insights):

1. The Feature-Rush Approach : Product Management and Product Marketing almost always rush to build more and more features to stay ahead of competition. Now, this may seem bad, given the fact that this mad rush can hamper quality and usability of the product. However, the fact that most customers will judge and make a "purchase decision" on mere capability (the list of features), makes this "feature-rush" approach attractive. For many large enterprises, software purchase decision is made by the procurement organization or the CIO/CTOs who don't use the software themselves, but buy it for the organization. Such people are more likely to evaluate the software on its capability rather than usability. This is one of the reasons for success of Microsoft software in the enterprise space. Even large and credible brands are not immune to the "Capability-Buy" phenomenon. Enterprise 2.0 vendors, while trying to make the product usable, will still need to be feature-capable in comparison to existing products, if they want to make any impact on the enterprise space.

2. The Use-and-Buy Approach: If you are really concerned about building a kick-ass product, that users love to use or betters their life, you will need to let users use it before they buy it. This is the approach most Social Media and Direct-to-Consumer products take. The best example is Google's Search. To be able to really be successful in this approach, you will need the conviction and the staying power of an innovator and the ability to keep persisting, before users see the benefit of your product and move in. Initially, the field will be spread across multiple such vendors, but if you really have the "killer app" with the best user experience, you can be sure that users will stick by you.

Products are not just a collection of Features

Software products are not just created but also thought out and conceptualized as a collection of features. While this works for extending features on an existing large product, for the conceptualization of a new product, this is possibly the best way to lose your way.

The value of the whole is not always a sum total of its parts.

Let me use a familiar analogy. A house, for example, is not just a collection of rooms, or of its accessories. Each room by itself doesn't have the "value" to its occupants as the whole house has. This is because, beyond the collection of rooms, the house is also built around the social interaction of its occupants. The same collection of rooms, organized in 2 different ways based on 2 different social interactions, will provide a wholly different kind of "value" to their occupants. Similar is the case in software products.

I am a big advocate of the need to think and conceptualize a software product in terms of its social interactions. After all its the social interactions in a product that users of the product experience, and the features are only a means to achieve them. Many of the current range of Web 2.0 applications are actually based on a single social interaction. Many products, in fact, started from a single social interaction, but have since found expression in a wider range of social interactions as well.

Twitter for example, is a simple application that started off with a simple social interaction - "implicit asynchronous messaging" - you could "publish" your status to the stream and let people downstream know about it, without having to explicitly message people. This might have seemed initially to most people (including myself) as not such great stuff, but a little thought will tell you that this is akin to "micro-publishing". The possibilities of extending this social interaction to evolve into a whole genre of social interactions, as people "get it" is endless. Thinking of Twitter as only a feature couldn't have opened up these possibilities, as thinking of Twitter as a publishing-consuming social interaction does.

Of the current crop of Web 2.0 products, those that will survive and grow into the next big thing, will have successfully mapped the next generation of social interactions.

Each such social interaction may involve a single or a multiple set of features. Again, each such interaction may involve some of the features partially. So, those coming from the old world of product management might want to create a matrix/map that co-relates social interactions to features and this might be helpful for them in product development. However, the progress in product development still needs to be measured in terms of how much of the conceptualized social interaction has been achieved and what possibilities lie ahead.