Epistemic Changes.

I’ve been looking at requirements engineering lately. Requirements engineering has a lifecycle just like the technology adoption lifecycle. That is convenient because it gives us multiple tails, which in turn lets us leverage simultaneous development of the epistemic change. It gives us numerous topics to learn and a way to staff the effort so we can be ready to capture the lessons taught by the early adopter’s organization in our bowling alley.

When we learn statistics, we learn that there are two tails. We see this in our 2-dimensional figures of the normal distribution. Those figures compress an n-dimensional distribution down to two dimensions. Those figures hide n-2 dimensions from our visualization. We only see two tails. But, in a YouTube tutorial on linear regression, we were replacing the linear functions from a prior regression analysis with new functions. Why?

The lesson was designed to teach us something. That something was something we probably not something we needed to learn. It was just another demonstration of where we end up when we throw away outliers. We end up confusing tails as well.

Keeping those tails distinct is something we can achieve in our tails. Our software applications present a user with a chain of user interface controls. Those chains can be seen as Markov chains. Each control or user interface element translates into a state in at least one Markov chain. Each control or element has a use frequency. Those use frequencies order the chain into a tail from the highest frequency to the lowest. Think of each control as a can of soup that has a UPC code printed on it. Each use adds another can of soup to our basket that we put through the cash register.

When we build our software, we order our controls. That, in turn, orders our tails. There are numerous controls that give rise to numerous tails. There are no surprise tails. There are no surprise outliers. We won’t be wondering about factors unless we are dealing with a bug. That bug would alter the frequencies in its relevant tail.

You are starting to see that product managers must teach the application to the developers. Marketing teaches the users. Users teach the developers. It sounds like a mess but discontinuous innovation, innovation that starts with a new theory, a new ontology seeding a new collection of dimensions, simplifies and aligns the teaching and learning. The customers, users, clerks, and managers have much to learn. They are doing something new. The old practices only worked once the prior, now current, theory was put into practice. We are putting the new theory into practice. We must learn those practices. Our software will implement the automation now possible around those emerging practices. Much will change.

A discontinuous innovation delivers economic wealth because it is different, emergent, and justifiable. It delivers a different constraint envelope within which the new practices get done. The application constructs an emergent culture around itself. That culture directs the future direction of the application, the prospects and future customers, and future practices. Nothing is static yet. Being a commodity is years away, profitable years.

Right now, the application embodying that new theory is for experts. Those experts work for the B2B early adopter in a vertical organization. They don’t need task sublimation yet. The practices are emergent.