Archive for October, 2016

Implicit Knowledge

October 24, 2016

One of the distinctions I’ve been making out on twitter is the difference between what I call fictional and non-fictional software. We get an idea. We have to ask the question does users actually do this today without our software. If the answer is “No,” we get to make up how it is to be done. The user tasks are a blank whiteboard. That’s fictional software. But most of the time, the answer is not “No.” In that case, the software is non-fictional, so we need to do an ethnography and find out exactly how the user does it, and what cognitive model of their thinking is while they do what they do. In non-fictional software, neither the developer or the UX designers are free to make things up.

Yesterday, I read “Usability Analysis of Visual Programming Environments: a ‘cognitive dimensions’ framework.” The author, a UX designer, makes some statements that clarified for me that UX design as practiced today, particularly by this designer, is fictional. Tasks exist before they are designed. Tasks exist before they are digitized by programmers. This isn’t new. Yahoo built a search engine without ever looking at existing search engines or asking library science practitioners how to do it. Yahoo made it up and then discovered many of the finding and practices of library science practitioners later. That is to say, they approached, progressed towards convergence with, the user’s real cognitive model of the underlying tasks. There is still a gap.

Agile cannot fix those gaps in non-fictional software. It can only approach and converge to the gap width between the user’s bent cognitive model they use as users, and the real cognitive model they learned eons ago in school. That learning was explicit with a sprinkling of implicit. The implicit does not get captured by asking questions, talking, observing, or iterating. With any luck, a trained observer, an ethnographer, and their observational frameworks can observe and capture that implicit knowledge.


A Rubik’s Cube can serve as an example. When solving a cube, we explore the problem space, a tree, with a depth first search. We can use simple heuristics to get close. But then, we stop making progress and start diverging away from the solution. We get lost. We are no longer solving. We are iterating. We are making noise in the stochastic sense. We stop twisting and turning. We look for a solution on the web. We find a book. That book contains “The hint,” the key. So after a long delay, we reset the cube, use the hint, and solve the cube.


We joined the epistemic culture  or what I was calling the functional culture of the cube. We are insiders. We solve the cube until we can do it without thinking, without the search struggles, and without remembering the hint. The explicit knowledge we found in that book was finally internalized and forgotten. The explicit knowledge was made implicit. If a developer asked how to solve the cube, the user doesn’t remember and cannot explicate their own experience. They cannot tell the developer. And, that would be a developer that wasn’t making it up, or fictionalizing the whole mess.

All domains contain and find ways to convey implicit knowledge. The Rubik’s cube example was weakly implicit since it has already been explicated in that book. The weakly implicit knowledge is a problem of insiders that have been exposed to the meme and outsiders who have not. Usually, those that got it teach those that don’t. Insiders teach outsiders. In other domains, implicit knowledge remains implicit but does get transferred between people without explication. Crafts knowledge is implicit. Doing it or practice transfers craft knowledge in particular, and implicit knowledge generally.

Let’s be clear here that generalist 101 class in the domain that you took back in college did not teach you the domain in the practitioner/expert sense. You/we don’t even know the correct questions to ask. I took accounting. I’m not an accountant. It was a checkbox, so I studied it as such. A few years after that class I encountered an accounting student and his tutor. The student was buying some junk food at the snack bar. The tutor asked him what accounts were affected by that transaction. That tutor was an insider. The student was working hard to get inside.

For anyone that will ever be a student of anything, there is no such thing as a checkbox subject. Slap yourself if you think so. Dig into it. Boredom is a choice, a bad one. You’re paying a lot of money, so make it relevant to think like an insider.

Recently, a machine beat a highly-ranked human in Go, a game not amenable to the generative space and heuristic-based pruning approach of the likes of Chess. The cute thing is that a machine learned how to be that human by finding the patterns. That machine was not taught an explicit Go knowledge. That machine now teaches Go players what it discovered implicitly and transfers knowledge via practice and play. The machine cannot explain how to play Go in any explicating manner.

One of my lifetime interest/learner topics was requirements elicitation. Several years ago, I came across a 1996 paper on requirements elicitation. Biases were found. The elicitor assumed the resulting system would be consistent with the current enterprise architecture, and let that architecture guide the questions put to users and customers, their bosses. That biased set of requirements caused waterfall development to fail. But, Agile does not even try to fix this. There will always be that gap between the user’s cognitive model and the cognitive model embedded implicitly in the software. UX designers like the author of the above paper impose UX without regard to the user’s cognitive model as well. I have found other UX designers preaching otherwise.

So the author of the above paper takes a program that already embeds the developer’s assumptions that already diverges and fictionalizes the user’s non-fictional tasks and further fictionalizes those tasks at the UX level. Sad, but that’s contemporary practice.

So what does this mess look like?


Here, we are looking at non-fictional software. The best outcome would end up back at the user’s conceptual model, so there was no gap. I’ve called that gap negative use costs, a term used in the early definition of the total cost of ownership (TCO). Nobody managed negative use costs, so there were no numbers, so in turn Gartner removed from the TCO. Earlier, I had called it training, since the user that knew how to do their job has to do it the way the developer and UX designer defined it. When you insert a manager of any kind in the process, you get more gap. The yellow arrows reflect an aggregation of a population of users. Users typically don’t focus on the carrier layer, so those training costs exist even if there were no negative use costs in the carried content.

As for the paper that triggered this post, “cognitive” is a poor word choice. The framework does not encode the user’s cognitive map. The framework is used to facilitate designer to manager discussions about a very specific problem space, users writing macros. Call it programming and programming languages if you don’t want your users to do it. Still useful info, but the author’s shell is about who gets to be in charge. The product manager is in charge. Well, you’ll resolve that conflict in your organization. You might want to find a UX designer that doesn’t impose their assumptions and divergences on the application.


The Tracy-Windom Distribution and the Technology Adoption Lifecycle Phases.

October 11, 2016

In my recent bookstore romps, the local B&N had a copy of Mircea Pitici’s The Best Writing on Mathematics 2015. I’ve read each year’s book since I discovered them in the public library system in San Antonio years ago. I read what I can. I don’t force myself to read every article. But, what I read I contextualize in terms of what does it mean to me, a product strategist. I’m a long way from finished with the 2016 book. I’m thinking I need to buy them going back as far as I can and read every article. Right now that’s impossible.

I thought I was finally finished with kurtosis, but no I wasn’t thanks to the 2015 book. So what brought kurtosis back to the forefront? Natalie Wolchover’s “At the Far Ends of a Universal Law,” did. The math in that article is about the analytic view of phase transitions or coupled differential equations described by something called the Tracy-Widom distribution. That distribution is asymmetric meaning it has skewness, which in turn means it exhibits kurtosis.

In “Mysterious Statistical Law May Finally Have an Explanation” in the October 2014 edition of Wired magazine, the Tracy-Wisdom distribution is explained. It is linked to distributions of eigenvalues, and phase transitions. The phase transition aspect of the Tracy-Widom distribution caught my attention because Geoffrey Moore’s technology adoption lifecycle is a collection of phase transitions.  The article contained a graph of the Tracy-Widom distribution, which I modified somewhat here.


I annotated the inflection points (IP) because they represent the couplings between the differential equations that comprise the Tracy-Widom distribution. I used thick black and blue lines to represent those differential equations. The Tracy-Wisdom distribution is a third-order differential equation, which is comprised of two second-order differential equations (S-curves), which in turn are comprised of two differential equations each (J-curves).

The cool thing is that we move from a stochastic model to an analytic model.

I removed the core vs tail color coding in the WIRED diagram. In my earlier discussions of kurtosis, the core and tails were defined by the fourth moment, aka the inflection points coupling the first order differential equations. The error persists in this figure because the inflection points were hard to determine by sight. Notice also that the WIRED diagram hints at skewness, but does not indicate how the distribution is leaning. For more on leaning and theta, see Convergence and Divergence—Adoption, De- adoption, Readoption, and More On Skew and Kurtosis. They are taking the Tracy-Widom distribution as a given here, rather than a transformation of the normal. Much about kurtosis is not resolved and settled in the mathematics community at this time.

The dashed vertical line separating the two sides of the distribution intersects the curve at the maxima of the distribution. The maxima would be a mode, rather than a mean. When a normal is skewed, the mean of that normal does not move. The line from the mean on the distribution’s baseline to the maxima slopes meeting the baseline at some θ. Ultimately, the second-order differential equations drive that θ. Given I have no idea where the mean is, I omitted the θ from this diagram.

In the 2015 book, the left side of the distribution is steeper, almost vertical, which generates a curve closer to the base axis, a curve with a tighter curvature, aka a larger value for Κ1 (smaller radius); and the right side is flatter, which generates a looser curvature, aka a smaller value for Κ2 (larger radius)—note that curvature Κ = 1/r.


So both figures can’t be correct. How did that happen? But, for my purposes, this latter one is more interesting because it shows a greater lag when transitioning between phases in the technology adoption lifecycle and in firms themselves, particularly in firms unaware that they are undergoing a phase transition. In Moore’s bowling alley, where the Poisson games occur. The phase transitions are more symmetric and faster. In the transition between the vertical and the IT horizontal, the phase transition can be slower, less symmetric. In the transition between early and late main street, the phase transition is fast. Most firms miss their quarterly guidance here, so they undergo a black swan, which is surprising since a firm should know when they are approaching having sold 50% of their addressable market. A firm should also know when they are approaching having sold 74% of their addressable market, so they wouldn’t hear from the Justice department or the EU. Of course, most firms never get near that 74% number.


Here I aligned a Tracy-Windom distribution with each technology adoption lifecycle phase boundary. I have no idea about the slopes of the s-curves, the second order differential equations. Your company would have its own slopes. Your processes would give rise to those slopes, so collect your data and find out. Knowing your rates would be useful if you were continuously doing discontinuous innovation.

I’ve labeled the phases and events somewhat differently from Moore. TE is the technical enthusiast layer. They don’t disappear at any point in the lifecycle. They are always there. Well, they do lose focus in the software as media model in the vertical phase of the adoption lifecycle.  Likewise in all late phases. BA is the bowling ally. Keeping your six early-adopter (EA) channels of the bowling alley full is key to continuously doing discontinuous innovation. V is the verticals. There would be one vertical for each early adopter. The early adopter is an executive in a vertical market. IT H is the IT horizontal market. Early main street (EM) is another term for the IT horizontal. If we were talking about a technology other than computing, there would still be a horizontal organization servicing  all departments of an enterprise.An enterprise participates in serval horizontal markets. Late main street (LM) also known as the “Consumer Market” where we are today, a market that orthodox business practice evolved to fit, a market where innovation is continuous, managerial, and worse “disruptive in the Christensen way (cash/competition).” The technical enthusiast and bowling alley is wonderfully discontinuous and disruptive positively in the Foster way (economic wealth/beyond the category). L is laggard or device phase. P is phobic or cloud phase. I the phobic phase computing disappears. The technical enthusiasts will have their own Tracy-Windom distributions. Moore’s chasm being one. Another happens when the focus changes from the carried to the carrier  in the vertical phase. And, yet another happens when aggregating the bowling alley applications into a carrier-focused, geek/IT facing product sold in the tornado. Cloud rewrites another. An M&A would cause another as well. That product would sell in the second (merger) tornado (not shown in the figure).

The first second-order differential equation accounts for what it takes to prepare to make the phase transition. The second second-order differential equation accounts for operationalized work during the phase. The diagram is not always accurate in this regard.

More than enough. Enjoy.

Geez another edit, but over packed.

Customer Lifecycle and the Value Gap

October 2, 2016

John Culter, @johncutlefish,  tweeted a link to Customer Retention Hacking: How to get Users to Commit. Reading the article I was struck reading this quote

You don’t interact with your significant other the same way on your first date as you do on your 50th or 200th date. Similarly, giving a customer a great experience on day one isn’t going to be the same as on day 50.

with how the long tails of an application’s clicks could be organized to make it work with the customer lifecycle.

We start with the 1st day, the onboarding. Different things happen from there. Learning happens differently in each user. Expertise develops over time. Roles diverge over time.

Value projection has its timeline as well. John tweeted a link to The Success Gap: A HUGE Opportunity You Haven’t Considered.

So we’ll review the long-tail of application’s clickstream. Let’s say that every control in your application emits an HTTP request to an HTML page for that control, so that every click get counted, sorted, and summed up by a directory structure. This will tell you what the users are doing. If you can isolate this down to a particular user, you might want to get permission or default permission in an EULA. This will timestamp the application’s clickstream. What’s important for the purposes of this post is the timestamp. You could see what the users does with your application each day via server log analytics. You could see what the user doesn’t do efficiently, or what the user doesn’t know how to do. That knowing or not will be role specific. You need to know the user’s role, and when the user changes roles. Is your user doing self-support? You can see it. Likewise, you can see where a bug happens, because the histograms will change drastically.


The histograms on the left aggregate several of the histograms on the right. We save a named file via the menu. We save a named file via shortcut. Those would each have their own histogram. They would be added together in “save a named file.” These aggregations would be defined by the directory structure containing the file for each control. We can save the control clicks by use case. The structure can get messy. With continuous delivery, we would save the server log and put a new server log out there. Play with it. Aggregate down the timeline.

Every click of a control is a micro conversion. Click and you see the next set of controls. Another click could tell you what use case the user is attempting to perform.

Value is projected outward from the application. Further various value propositions are projected from the application. Some use does not move the system towards a value proposition. We can sort that out. The value not yet delivered would constitute the Success Gap.


In this figure, I started with the triangle model where an application is a decision tree. The base of the triangle (right side) is the user interface (UI). Ideally, the UI would be organized by the one task, one dialog, or in contemporary terms one use case, one dialog. We do not deliver value. We deliver enablers that enable the user to deliver value through the use of those enablers. The user has an orientation towards the application. A good measure of location would be what training would be required to efficiently use the application. That training can be pushed into the buying cycle, rather than waiting until after the application is installed. Post install training would show up between the user and the UI. There would be various, numerous users each with different competencies and competency.

The triangle model here is correlated with the roadmap and the releases. Released functionality should always deliver value and reduce the value gap. When this is the case, the user is induced to continue subscriptions. Software as Numbers discussed this need to induce in the client-consultancy, custom-build engagement, the type of engagement where discontinuous technologies find client productizations and vertical markets for that product. The focus in such engagements would be carried content in the software as media model.

Notice I’m counting bits here. Used bits and Delivered bits can give you an idea of leverage. Each release delivers some bits to the ultimate value proposition. The value delivered may the users or that of an economic buyer. The economic buyer’s value generally reaches deeper into the future.

In an agile development environment, the iterations would be tactical; the value delivery, strategic. Why the labels? Consider the machine intelligence environment for a moment. Strategic is not a continuation of the tactical. In phase change environments, you have to stop collecting data and begin a new collection. How wide is your tactical learning needs? How wide is your strategic learning needs?

So we have seen how to collect the data about the customer lifecycle, the daily use under different situations. We’ve looked at the success gap. Both of these ideas tie to a timeline. You can measure against the time to return, or the time to value delivery. The retained customer would have to learn again with each release. Permission campaigns can move that learning earlier. Content marketing likewise. The economic buyer might have to be taught the value proposition, and in value-based marketing, sold on the price and configuration. Microservices can partition, so the amount of UI is variable, so the UI purchased is the minimal UI for the expected value projection.