In previous blogs, I've discussed what a meta-product is and how it works well with the concept of N=1. Now I'd like to talk about the implications of selling a meta-product -- a product used to create other products. As a meta-vendor, you truly co-create products with your customers. So, how do you gauge the correct level of complexity of the user interface of such a product? And who determines that -- you, your customer, or both?

How do you present to the market a meta-product that can be tailored by a customer who isn't technology-literate or analytically inclined, without dumbing down the product to the point where it isn't flexible? Must you limit the market for your meta-product to the technically proficient, or dumb it down in order to expand its appeal to a wider audience?

This resembles the old argument about user interfaces -- how much choice do you offer the user? But this problem goes deeper; the choices actually determine the functionality of the product, not just the way the user interacts with it. This is exacerbated by globalization, which requires internationalization: delivering user interfaces widely is complicated by the need to accommodate different international locales (language, customs, currency punctuation, etc.).

You can view the range of product flexibility as an issue related to "binding" -- a term I'm borrowing from the computer language compiler/interpreter community. The more you "bind" a product to a particular set of features or capabilities – such as a particular customer demographic -- the closer you are to a traditional (non-meta) product. As with compilers and interpreters, there are big potential advantages in delaying "binding" as long as possible. The downside is increased complexity, both conceptual and practical.

As a meta-vendor, you could use your meta-product to create products for various levels of customer proficiency, from a full-blown meta-product down to a "black box" (point solution) with perhaps a few knobs and dials poking out that the user can twiddle. This, then, is a spectrum ranging from "fully unbound" (meta-product) to "fully bound" (traditional product). But this requires that you, as the meta-vendor, have a flexible production facility and an untraditional approach to production.

I believe the answer goes back to the basic tenet of N=1: "co-create" the product with your customer. Train your customer's technical staff to create products from your meta-product, and provide support for them while they do it. This opens up opportunities for service revenue to complement your product revenue, and the resulting service relationship, if done well, cements your customer's loyalty.

I'll use my company's software engineering automation meta-tool as an example (again). Our engagements with customers range from fully training and supporting them while they create their own automation tools, to creating such tools for them and helping them deploy them. We also work with IT service providers, training them and helping them use our meta-tool to create automation tools that they then either use to provide services or offer to the market as point solutions. The closer we can get to 100% automation, the more the offering looks like a traditional point solution. However, some software engineering tasks aren't amenable to 100% automation, in which case the service provider offers the customer a package comprising both tools and services, with backup support from us.

A really well designed meta-product should be flexible and powerful enough to allow the creation, either by the vendor or by the customer or both, of the black boxes described above.

Stephen Heffner is the president of Pennington Systems (http://WWW.Pennington.com)