Why B2B exchanges failed...

Putting the Horse First - NET GAINS - CIO Magazine May 15,2002: If you don't have a critical mass of buyers, how do you attract suppliers? And if you don't have most of the suppliers, why would buyers participate? Most B2B exchanges failed because they could not get past that first hurdle. Suppliers resisted joining the exchanges because they feared direct comparison with competitors would erode their margins. And buyers as well as sellers were loath to pay transaction fees for what they felt was a simple matchmaking function.

But the struggle for liquidity is merely a symptom of the real problem, which is that the creation of exchanges to match buyers and sellers preceded the creation of software and services that would make exchanges truly useful.

This article goes on to identify the root cause, that presents another chicken and egg scenario; unless you have users (buyers/sellers) it is very hard to invent the useful services that they want. It is only through the evolution of the service that we can best know how it can add value.

This solution is to build e-services out of existing inter-enterprise business processes, first automating and then transforming to bring real efficiencies.
The lesson of failed B2B makes good sense for any product development strategy, make one customer happy then the next, then the next.


The future of B2B e-commerce lies not in exchanges but in software and solutions that bring real efficiencies to specific business processes. The business of trading exchanges populated by anonymous buyers and sellers is best left to financial exchanges and commodities traders because only pure commodities can be bought and sold in marketplaces. As the founder of Dean whither used to say, "We build success one investor at a time." Similarly, B2B companies will build their business one customer at a time, instead of building marketplaces with no customers



In the context of an exchange that facilities the transfer of working systems intellectual property(WSIP), this begs the question, could WSIP be a commodity?

Probably not until there is tremendous settling in the market or regulation, possibly SBO would provide the impetus!

Community of Creation - Mohanbir Sawhney

There are some interesting research questions in this presentation. A related reference site 'Business Strategy & Innovation Thought Leadership from ManyWorlds.com' with a quick overview can provide more context.

The research questions are on slide 10.

Geoffrey Moore: The Role of Open Source Computing

These comments indicate that it must have been an interesting talk, placing Open source in context and mapping Maslows hierarchy to current corporate culture. To make collaboration work there must be shared context, but there may be a space for competitive collaboration. Think of the laggards looking for a proven solution to problem X. They will pay to collaborate with the best match solution. Being a year or so behind the curve, the market has already solved the problem on many occasions, the solutions have moved from being contextual to being core. For the laggards, find a good match to their context is the real challenge, if such a match can be found, the laggard can make a quantum leap, not only replicating the solution but also replicating some of the context!
This is a big win for the laggard, the compensation for the innovators comes in payment for their IPR and also in the benefits of commoditisation of their core solution. If their solution can become dominant they can benefit from increased buying power for support and service from the original hardware and software vendors.

When Crossing the Chasm - Act Your Age

Act Your Age provides a nice simplification of Geoffrey Moore book and some sensible advice on putting it into practice. I am interested in making use of the chasm from a laggards or conservatives view point. Can I get information on the good work that has been done in taming technology by the pragmatists. They use stuff that works, I would like to leverage their experience rather that depending on consultants to retrofit their views to my problem.
The problem is that the innovators and pragmatists are too busy working on the next best thing to bother with sharing, can technology help? Can IPR protect their assets and allow laggards to reuse them?

If your pockets are deep enough, any technology can be replicated

Memoirs From the Browser Wars gives a nice insight to the reality that is innovative technology development. In the end, the big pockets have most of the clout provided they identify the threat before it is too late and before it is protected by intellectual property rights. The 'throw money at it philosophy' works when you have a huge install base and can give stuff away for free. I saw it first hand with the demise of X.400 in the main stream after MS consumed the emerging X.400 market by bundling a (buggy) X.400 capability with Exchange.

I hated fixing our browser to make it bug-compatible with Netscape even though we had already coded it to 'the standard'. Life's not fair sometimes. :-)

I know what you mean!.

The business model is a.....

The business model is a cognitive device to convert technical aspects of a product or service into economic value. Any successful innovation (vs. invention) needs a business model, and that model must do two things: first, it must create value in its ecosystem, and second, it must capture a portion of that value for the innovator, so that additional advancements will be forthcoming

Henry William Chesbrough provides a very concise view of a business model that nails value creation. Every project undertaken should have a value-based model, sure it doesn’t have to be economic, it could be social, personal, but there is a reward, in some form, that results, so that we do it again!

Chat about 'Open Innovation'

This entry presents a nice interview with Mr. Henry Chesbrough and some follow up comments on the relevance of blogs for Open Innovation. I am using a blog to simply keep track of some of my thoughts and literature search as I work through to a specific, manageable and interesting research question. I am finding the IdeaFlow blog provides a wonderful source of information. Thanks :-)

Some evolving work on the effect of ICT on Innovation collaboration

This work in progress deals with the issue of trust and reputation in the diffusion of knowlege. I await the official publication.

A nice collection of current articles around innovation

http://www.innovation-enterprise.com/5.1/5.1.60.html

Structure and Design around Innovation

Structure and Design provides a useful list of resources that tackle some of the major issues.

Of particular interest is the theory by Andrew B. Hargadon, "Firms and Knowledge Brokers: Lessons in Pursuing Continuous Innovation," California Management Review, Spring 1998. How this can apply to managing parts of the IS/IT application portfolio? Maybe that is the question :-)

Open Innovation

Open Innovation could provide a model for replicating IP from an early adaptor to a laggard in the technology adoption life cycle or product diffusion curve. For what types of applications would this work? or is there any point in trying to nail it down? Maybe it is best to deal with the some of the potential problems, ownership, maintenance?

Copy cat

Intel do "Copy Exactly", make each new fab an exact copy of the R+D system, they subsequently replicate incremental improvements across the copies. For Intel, the context in each of the fabs is replicated exactly.

How can the replicate approach become valuable to the outside world; Can replication become a procurement strategy for Innovation?
Rather than work in isolation, look at the early adaptors and copy their innovations, pay them for their intellectual capital and collaborate to add incremental improvement.
Replicate the support services, replicate the business processes because technology and people go hand in hand . How could this strategy map to the IT application portfolio.

Some stuff to read:
New Approaches to Innovation Policy: Some Norwegian Examples

The Non-Technological Side Of Technological Innovation:
State-Of-The-Art And Further Empirical Research

MIT SMR Article, "The Innovation Subsidy" - Spring 2004 Michael Schrage. Reprint 45305

MIT SMR Article, "The Innovation Subsidy" - Spring 2004 Michael Schrage. Reprint 45305: "The Innovation Subsidy"

This is worth a read!

To be successful in uncharted waters, the ability to learn from experience is paramount

MIT SMR Article, "Strategic Innovation and the Science of Learning" - Winter 2004 Vijay Govindarajan and Chris Trimble. Reprint 45212:

To be successful in uncharted waters, the ability to learn from experience is paramount.

This is why replication is an option. Take someone's existing working system and replicate or copy it exactly, the risks are known up front, they are known from the earlier experience. Granted the exact copy may not meet the exact need, but why not adapt the need to meet existing best practice, build a community around the solution and treat the system as a tool, something that does a job or provides a service. Unless the system in question is the source of sustained competitive advantage then why not use something that already exists and is proven to work!.

The community can come into it's own as the system evolves, the changes may be shared with the community to increase buying power and share support, evolving the best practice of the tool in this way means we can again learn from experience.

Preamble: 100% and 80% solutions

Olin Shivers makes some good points about doing the right thing and doing a complete job first time:
.

So I sat down to do a careful, 100% job -- I wanted to cover everything in section 2 of the Unix man pages, in a manner that was harmonious with the deep structures of the Scheme language. As a design task, it was a tremendous amount of work, taking several years, and multiple revisions. But now it's done. Scsh's socket code, for instance, *completely* implements the socket API

I guess the 100% goes hand in hand with many 80% solutions, because one of the benefits of Open Source is that people can see other peoples work, the community can see the efforts and evolution of requirements and solutions. A proper 100% job can really only be done in hind sight, otherwise there is a lot of complete solutions but also a lot of wasted time and effort. However, the benefit of what is learned in doing such a 100% job, at whatever stage in the solution life cycle, will never be lost!

'open' systems

IBM VC calls for 'open' hardware
and it makes some sense, once you realize that the shared capital costs can be recouped by value add services. There is lots of scope for differentiation at the services level, the benefits of trusted shared hardware, basically a risk free set of core functionality, free our minds to concentrate on the more intangible and valuable business benefit issues.

Surely this will evolve into complete systems, where the core functions are well proven and shared collaborations and where the extremities or business interfaces provide the 'localization' and real differentiated value.

In the same way the hardware IP needs to be validated, so will core functional systems, the sort of stuff that the early technologies adaptors have worked hard to develop. The market followers can adopt the experience (IP) of the early adaptors once there is some reasonable method to validate the benefit of an existing proven solution.