Product Strategist: Multisided Markets

Today, I'm building on yesterday's post on Freemium and Multisided Markets at http://tinyurl.com/bhpy66. I used my triangle model notation yesterday. It obscured channels and the model-view-controller pattern, so I came up with a different way to describe the underlying structure of multisided markets.

Multisided markets start with a producer-consumer stack or chain. I've laid them out horizontally, so we'll call it a producter-consumer chain.

The producer-consumer (P) (C) or (PC) chain around your application might not be that long, or it might be much longer. Such chains provide a means to describe your ecology. More than likely they branch and converge and look more like a network. The producer-consumer chain echoes a value chain in that each interaction creates value for the next interaction. Value chains also realize themselves in networks, as in a value constellation.

At any consumer facing producer, you can insert an application. We can represent that application as a model-view-controller (VC) (M) or (M) (VC) pair.

The producer enters data into a view. The data is transferred to the model where it is stored and computed upon. Once in the model, a consumer requests the data from a view. The model provides data satisfying the request to the view. One of the model-view-controller pairs use the application for free. The content that the free user provides creates value for the paying user. Each user plays specific roles in the creating the value provided by the application. It may require a large collection of producers to produce the value obtained by a single user. In this figure, the model (M) might include both data and metadata.

Here, I've linearized the representation.

Here, the model and its metadata is represented. In yesterday's discussion, I mentioned channels. Consider the producer-consumer chains to be channels. Both data and metadata can be used to foster producer-consumer chains.

When we input content into an application, that application serves as a codec, which means that the application encodes and decodes content. Codecs typically involve signal processing, but any conversion from real to virtual involves a codec. Here the yellow area represents the encoded. Within the codec one model can share data with another model. Codecs implement protocols. The content within the yellow area complies with a particular protocol. Additional codecs may be involved as you move from one model to another. Google Maps provide searches correlated with the current location, but largely based on Google's Web search. Google Maps restricts the search conducted by Google.

Each channel is annotated in the figure. Modifying the figure somewhat give us the following representation.

Here the model becomes one or more assets. Each asset can foster one or more multisided market. The payment for each channel is independent of that of other channels. At some point the prices should provide a profit.

This figure provides an example of a multisided market. The vendor provided a form that you could host on a webpage, as a widget or n-tier provisioned feature. It displayed a form that your customer filled out. The content of the form was then forwarded to you as a request for a phone call. Wonderful. However, further investigation revealed that the vendor also collected that information and sold it as part of their leads provision business. This probably violated your privacy policy and left you exposed to lawsuits. Ouch! Your free phone call request cost your customer plenty.

The application at the center of a multisided market will evolve over time increasing the scope of the data collected. It will also accumulate increasingly larger volumes of data as well.

This is where SOAP and aspect-oriented programming (AOP) can come to the rescue. SOAP processes data to the extent to which the data is present much like an unknown tag in HTML is ignored--missing data can be ignored without generating an exception. AOP allows you to add aspects to data. This architecture extends beyond the purely technical and demonstrates how a technical architecture facilitates the marketing aspects of the application.

In the technology adoption lifecycle, entry into the late market leaves the vendor facing the end of organic growth. Once this end of growth is communicated to the financial markets, the vendor is facing a stock stall. The vendor needs a new technology. And, they need it in less than a quarter. They need a technology, not a product, a technology coming out of the bowling ally and engaging in the tornado where the vendor will fight it out for the market leadership in a new category. That technology has to be disruptive. The current customers of the company's earlier technology will not buy that disruptive technology. The current customer's are far to pragmatic, and the market for the second technology is much less pragmatic.

This is one place where Christensen's separation makes clear sense. But, the vendor will try to cross sell the second technology. They might try to build it into the product roadmap of the first technology. Bad ideas. The real winner here is to create a model exchange channel and tie the two technologies together in a collection of multisided markets. The customers of the first technology can then adopt the new technology as it proves its value proposition. The first technology would be a SaaS application or service. The second would still be a product.

Talk back! Leave a comment. Or, for those of you out on an RSS feed, email comments to locke.david@rocketmail.com. Or, tweet me at @DavidWLocke 

Thanks!