Open Gardens

This set of articles comprise of four parts

Enterprise 2.0 ROI: Collaborative research and mobility Part One

The ROI for Enterprise 2.0: Part Two: User contributions to Enterprise 2.0 – Doing a Robert Scoble

ROI for enterprise 2.0: Part Three : Collaborative research in new product design

Part Four: Mobility and ROI within the Enterprise

In Part two of this series , we discussed how we can get people to contribute to deployment of Web 2.0 within an Enterprise.

In this section, we discuss ROI for deployment of Web 2.0 in an Enterprise in terms of product development and collaborative research.

My father used to quote Peter Drucker : and one of the quotes I remember is: “The purpose of business is to create and keep a customer.”

Simplistic as it may seem, the basic idea is ‘everything should be aligned to a sales effort’ – and this applies to Web 2.0 deployment.

Everyone in the business understands it’s product set (what it sells) and any initiative aligned towards improving a product will find champions within a business.

A product undergoes a series of steps from conception to deployment.

a) Concept stage: The innovation is proposed. A basic architecture is conceptualized.

b) Product Development : involves engaging with people, development of the architecture, creating iterative prototypes

c) Production : Actually creating the product

d) Product testing

e) Product deployment

f) Support: Promotion, customer relationship,

The end goal being to get some competitive advantage

The basic stages of product development have not changed much.

However, for an outward facing organization, opportunities exist to engage with customers at many levels.

Specifically, the product design process should be changed to actively identify segments / stages in advance where customers can help shape the new product.

In keeping with the core tenets of Web 2.0, the product must improve over time as more people add intellectual input to the product. This leads to a competitive advantage over other products AKA harnessing collective intelligence

The best example of this strategy is Amazon

A book is a physical product .. However, the addition of reviews and feedback over time by millions of customers leads to an added digital/ intellectual component to the ‘product’. In this case, the product is not just the ‘physical book’ but the ‘physical book + customer reviews and ratings’

But the same principles could be employed with more complex products – such as the design of a new airliner from Boeing.

One would not expect Boeing to design jet engines by consensus/community – however – various design and aesthetic aspects of a plane can be designed by user input as Boeing did via the world design program

Harnessing collective intelligence is a complex process. There are at least five ways to harness collective intelligence. To summarise from the above (again by Dion)

>>>

1) Be the Hub of a Hard to Recreate Data Source – ex wikipedia

2) Seek Collective Intelligence out – Google

3) Trigger Large-Scale Network Effects – Katrinalist and CivicSpace

4) Provide A Folksonomy – Self-organization Flickr and del.icio.us .

5) Create a Reverse Intelligence Filter – Memeorandum have been using this to great effect. The idea is that hyperlinks, trackbacks, and other information references can be counted and used as a reference to determine what it’s important.

<<<

The involvement of the community is not happening in isolation. The use of community/Web 2.0 is impacting many areas of the Enterprise – for instance software development as JP Rangaswamy puts it ..

>>>

And the way I think of it is this:

For common problems use Opensource.

For rare problems use Buy.

For unique problems use Build.

An “internal” IT department (or whatever it gets called nowadays) should concentrate the bulk of its resources on solving problems that are unique to the enterprise that pays them. A smaller number of people within the department should concentrate on buying (and thereby paying a premium for) rare solutions to rare problems. And the entire department should work on open source principles, participating in the community for problems that affect the community.

<<<

I am proposing the adoption of an analogous mindset in product development. In other words, like Boeing, the company will focus of solving the unique problems (the Engineering) and at the other extreme – will try to ‘outsource’ the design of many simple elements to the community and harness the intelligence from the community

If properly managed, this approach will lead to better products, happier customers and lower design costs.

In addition, it is not just the customers who could play a part here because the same logic can be applied to business partners i.e. feedback on some elements of the product design can be actively sought out from it’s partners. This leads to an element of collaborative research. The concept of collaborative research is well known but the difference here is to actively and formally incorporate it within the design of the product.

To recap, what we are saying here is:

a) The product design/development process must be changed in advance to identify core elements /segments where Web 2.0/Community will be involved.

b) The involvement and interaction with the community should be actively managed at the product level – both in it’s design and also post deployment

c) Consider collaborative research at a product design level. Formalise this process in the design of specific products by working with partners. Identify specific segments in advance within the product design stage where you can involve business partners

Thus web 2.0 becomes an integral part of product design

Finally, the emotional involvement of the community will lead to a competitive advantage. Not all products will be enticing enough to involve the community – but those that do – will win over those that don’t in a given market segment

To conclude,

a) The deployment of Web 2.0 within an enterprise must be tied to initial and iterative improvement of specific products. This works since a product is understood across the enterprise and improvement of the core product leads to increased revenue

b) Even within a complex product, it may be possible to granularize the product design and development stages so that customer feedback and interaction may be sought in the development of specific aspects(like Boeing)

c) Engagement and contribution should be sought at these levels of the product. Products thus developed have the potential to directly add value to the company and at the same time, serve their customers better

d) The actual implementation is product specific i.e. every product design team must work out for itself how it implements the process.

In the fourth part of this series, we will look at how mobility provides ROI within the Enterprise.

Notes:

Dion Hinchcliffe explains more about product development in this article in the social computing magazine

Source for Peter Drucker quote: Peter Drucker quotes

Tweet This Post