Twinkle, twinkle, little product

So we’re far away from the city; the night is dark; the moon is full; the light sufficient; headlights off; just us and the sky, a wide and twinkling sky; and our car moving us beneath the glorious heavens. The stars twinkle. We recall the old rhyme, as the sky takes our breath away.

A few nights later, some of the staff is working late to meet tomorrow’s deadline, so you’re doing your leadership thing while you lose yourself for a moment looking out your skyscraper window. The stars still twinkle. The moon doesn’t. The streetlights don’t. Only the stars, the few you can see standing in all that light pollution, twinkle.

Years ago, decades ago, the astronomy community realized that they had to move their telescopes and other scanners out beyond the atmosphere if they were going to get rid of the bugs we call twinkles. Once they got the Hubble up there, the stars no longer twinkled for astronomers. With the bugs gone, they gained clarity. They gained vision. They gained insight. They moved their value chain beyond one of its constraints, and went on to capture that value, deeper value.

Astronomers can hardly be blamed for those twinkles, those bugs. Those twinkles arose from a physical constraint, the sky. Managerial decisions wouldn’t have made those twinkles go away. Quality assurance wouldn’t make those twinkles go away. Better astronomers wouldn’t make those twinkles go away either. Twinkles persisted until recently.

But, I said product didn’t I? How do our products twinkle? How do our products twinkle despite management, programmers, quality assurance? And, I’m not talking about the bugs that could just as well turn up in a telescope rather than our code. I mean the twinkles, the bugs, we are blind to; the politics of product and the politics of elicitation; the politics of governance; the CEO; the execs; and the management of the software vendor organization; yes, right to your door, that of the product manager; and beyond that the politics out in the distance there, the politics of the economic buyers that constitute our customers; and our early adopter clients and their organizations management. Call them, the air of the development world.

In recent tweets, I’ve had to remind peeps that, in my world at least, that of companies that sell technology, rather than content, aka not a web 2.0 company, the economic buyer is only the first buyer, the person in the initial sale, and given the enterprise nature of the pursuit of our increasing returns, not a person involved in the subsequent sales, not a person that will even involve themselves in the UX. That economic buyer does, however, get sold some notions of business value, and lacking that might snap back and see to it that our application is removed from their company. That economic buyer is at the apex of the purchasing company’s politics spreadsheet. That economic buyer is the twinkle supplier.

Software development is repleat with myth. Requirements are never stable. But, that flies in the face of those of us who worked in functional domains. Our requirements rarely change. We’re mostly about reproduction, doing it again and again and again. And, meaning wise, our meanings rarely change, so don’t look at your elicitation sources as the sources of twinkle. And, absolutely–what that myth tell us is that requirements never stop twinkling? Like stars photographed from the ground, the twinkles stop, because we fixed them in silver. Requirements fix them in words. Developers never see the twinkles until a project turns into a program, or in a more Agilist world, the next iteration or refactoring.  Even then, developers are far away from the nuclear furnace.

The twinkle, twinkle, in an internal organization, requires us to look up. And, don’t talk to me about flat organizations. If an organization was really flat, my CEO would be shopping at Walmart and wearing those t-shirts they give us, so we have clothes to wear at work. There is always an up. And, in a vendor organization there is a down. Flip the representation over if you like. Source politics on one side and builder politics on the other. Twinkle, twinkle–southern hemisphere, northern hemisphere–matters not. That politics is hierarchical, deep, and fused. The end results are tradeoffs. We talk about tradeoffs as if they were necessary and the core of what we do. The tradeoffs keep changing. So the twinkle never ends, and the product fits loosely if at all. Does it serve the economic buyer’s expected value, or the need for users to get some aerobic exercise pushing a mouse across a screen while compensating for the mismatches between the software and their functional cultures.

The twinkle does have solutions–AOP for one. Ask a developer about it, or search this blog. It might be in my prior blogs that are now inaccessible, one of the wonders of SAAS. But, beyond the technical enablers, the booster rockets, we need to get rid of the twinkle, the politics that ruin our ability to deliver value fully. No endless chain of  iterations will eliminate the twinkle. Only we can get our software up above politics. Start by noticing it. Of course, we can dream of the day,….

Back to Blog

It’s been over a year now since I disappeared from my blog. I still have no ability to draw the bitmap graphics that I’ve used extensively in my blog, but a writing book challenged me to go completely lexical. Disappearing doesn’t mean that I forgot my backlog, or that new ideas haven’t showed up to extend the universe. But now, I’m back here.

Last month, out of frustration, I started another blog, Product Strategist 2. But today,  I posted a link back there. If you’ve already followed me out to that blog, we will be staying here. Check your subscriptions. Thanks.

About Control

Where did I put my controls? If you have authority and use it, rather than doing something a little more complicated and implicit like lead, you know your controls are explicitly up there in the hierarchy. If you practice shepard leadership, you know it’s out there in the implicitly plowed field of yours and your team. If you’re dealing with channels, you better understand gravity, control at a distance, because you are far away from the decision making of the actors.

This afternoon’s road rage trigger pulled into the fast lane as I was closing on an open slot adjacent to a semi a lane to the right, the shoulder adjacent the open lane and a separator wall to the left were it should be. Slow traffic in the fast lane is supposed to be illegal, so where is the policeman who is supposed to pull this guy over. Yeah, a moving control. Stuff we deal with everyday like banks that won’t loan. Is it any wonder, I’m left wondering where my controls are. No, I didn’t road rage. I made the six lane changes to pass the control and get on with it. Thanks to the road controller the world was a little more dangerous than a fast drive through the slot and beyond for those few moments. Then, the world was safe again for the fast traffic left to itself in the fast lane where it belongs in a lane discipline state like Texas, which likewise makes it easier for the police to know where to look when on the lookout for the harmless speeders.

So here we have various kinds of controls: barbed wire fences, paths up the cliff face, flat surfaces, ramps, hills, speed bumps, twists from inside to outside, and muddy plowed fields from those collegial conversations in the rain. So lets talk about controls, about mission, about vision, about all the things that lay out what must be and how it must be done. This isn’t about lists. It isn’t about maps either, not this time.

We may get lost in the math, so I’ll omit it, gloss over it, or hint at it. If you want to dive into it, we can talk later. Consider these ideas Lego blocks, or yet another wrench of one kind or another that you can use when you get tired of the straight lines of our linear assumptions.

Yes, this coulda, shoulda, woulda, mighta been a slide presentation, or a cartoon. It’s graphics rich. It’s long. And, given I drew this stuff months ago after a period of trying to crank out part 2 and 3 of the long tails, thick tails presentation, it concludes where I lost the time to stay focused to the rat race of keeping the food on the table, rent paid, and car running–my current controls.

So I’ll start out here with the typical linear view of the business proposition. Linear teases us with 8th grade geometry. Two points are a line. Two lines are point. Hints of recursion; of arcs being nodes; of von Neumann’s zero-sum game theory; of drafting boards, t-squares, triangles, compass, and rulers, of much, yes, even CGI at some level. Of some old line still used in a bar.

Mostly linear is a belief. Given that so much math has moved on from the linear and the orthogonal, linear survives just because “non-linear” is less familiar, more risky like discontinuous innovation, and harder to communicate to those less analytical, less abstract executors of our strategies. Linear is helped out by regression, a line defined by many points most of which are not on the line–controls at a distance. Still regression like much of math is still beholden to the Pythagorean notion of distance.

The Linear Assumption

We assume that if we postpone a decision, all is well, because things will just go on nice, straight, and level. We might be bothered by the idea that our industry, our category, our financial performance is just going to converge with that of our competition. We might want to turn.

The Curved Reality

The reality is more like we are curving, turning all the time, but we just project all those turns onto the path of our linear assumption. Going linearly straight would take so much effort, we’d be doing nothing else. Strategic alignment would kill us. Besides, we have an easy cheat. We can just project all that curving down to our linear assumption and get some sleep.

Log-Linear Transform

The mathematicians built these tools, not for the businessman, but for themselves. They work hard to make mathematics easy on themselves. I might have the name of this transform wrong. Being loose here makes both of our lives easier. But, rest assured, the transform exists, has a name, and yes, you learned it over and over again back in school.

Log-Linear Twice

So here we see that earlier two-dimensional curve being depicted as a three-dimensional curve. Raising the exponents leaves us with having to carry out two projections back to the linear assumption. Easy enough. Keep the story straight; simple; communicable, like a disease. It hides intentions if you need to keep something secret while appearing to be completely open. Yes, those fast followers follow with their own linear assumptions.

The 3-D Assumption

Yes, we live in a 3-D world, so we assume that to be the nature of even the 1-D linear assumption. Alas, we would be wrong. Studies on human perception show humans to sense only 2.5 dimensions. But, mathematicians like dimensions to be integer constructs, so they round up that 2.5 to 3, and we just get on with it. The dimension of towards and away stops at our stomachs, so the known world hangs out behind us only as a concept, much like the past and the future.

Our 2.5-D World

Here the z-axis, that half a dimension runs from the upper left to the bottom right. Notice there is no arrow moving off into the upper left. The three divergent lines find their way out in this 2.5-D playground. Of course, corporations perceive in ways independent of human perception.

2.5-D Reality

The dimensions are counted out in this figure. Towards might be labelled away. It’s a frame of reference problem. The perceptual physiologist probably have some standards laid out for their discussions of the matter. Notice the red line disappearing into an electrical outlet of sorts, really a dimensional boundary. That line might actually be 4-D, but we are only reporting on a 2.5-D world, so statistical significance would make the line just plain disappear, because the data ran out, and a regression only sees as far as it’s most distant outliers on each axis of the reported dimensions. Magic if you will, or thick tails falling into the implicit.

I know. You know this stuff. But do you use it? Or, lose it? Do you make your roadmap a list, so you don’t have to do all that GPS and dead-reckoning math? Do we have inertial nav for our roadmaps yet?

Decisions with Equations

Now, I’ll admit that I drew the lines long before I figured I was going to talk about equations or polynomials. I don’t have Mathematica, so the equations are loose approximations. The equations of the lines runs from 1-D to 2-D to 3-D. That’s pretty much the point. The point was to open a gateway to other topics, codecs, protocols, which in turn lets us build other worlds, worlds that couldn’t be build otherwise. Some of us PMs push codecs and protocols, our technologies, out into the world embedded in products and services. That’s where value-chains, lasting wealth, and careers get built. You don’t have to do that if cash and jobs is as far as you want to go with your change the world pursuits.

Decisions

So why did I include the word decision in the titles of the last two graphs? Well, once you kick the entity painting the line in some direction and some magnitude, oops those sneaky vectors, you’ve made and implemented a decision. You can stop thinking at that point. But, you’re paid to think. you’re paid to fake out the soccer goalies paid by your competition. You’re paid to turn, rather than go straight. You’re paid to decide. Those decisions dance with the notion of controls. Those controls might be pool table bumpers, so you can stick with the linear assumption, or they might be curves of all ilks. The triangles mark the moment of decision on each of the lines.

Consider real options, the idea that you pencil in future decisions along your vectors of differentiation, so an assessment of the tracking portfolio of each of your strategies is calendared and made. Some at least minimally go/no go decision is made. The linear assumption is littered with decision points. The accounting measurement lattice works similarly. Both don’t force you to turn, but might necessitate a turn in response to changes in the underlying situation.

Notice that your equations can only be so complicated given your cost structure and policy structure at the time of decision. The curve, the turn might have to be simpler until you can hire and buy the needed capability.

Geometries

Back in the day, you drew a flowchart before you coded. You made a decision, you branched, and as far as you ever noticed, the world didn’t change because of the decisions made inside your program. You went left or right. You did this or not. You did this or that. Your decisions were binary tending upward to the case statement with the ensuing catch all called OTHERWISE. You didn’t really think in terms of dimensionality. You never got around to the n-dimensional thing I call the splat. You never asked yourself the mathematician’s question of how many dimensions were involved, you never rounded up to compensate for the programming language’s dependence on integer-based branching. What would a half-a-dimension branch be in C++ logic flow? Worse, since you were not Einstein, you didn’t ask about curvature. It just wasn’t done.

A book on cosmological topology changed all of that for me. It’s not right linear vs. left linear. It’s curvatures. It’s crumple zones. It’s densities. It’s all those roadmaps that didn’t prove their case and ended up as crumpled balls laying wherever your intended 3-point shot left them in the neighborhood of your trash can. It’s that straight line bent all to hell. It’s that straight line, reorganized into a collection of composite functions.

Topology is one of those topics that separates mathematicians and statisticians. I’m taking this from a statistician I met a while back that never cleared the hurdle of topology.

Topology was created by some folks that questioned Euclid’s fifth postulate, the parallel lines postulate. They thought this stuff up, so we don’t have to. Euclidean geometry honors parallel lines as a truth. Non-Euclidean geometries don’t. The earliest two, as far as I know, non-Euclidean geometries involved convex and concave worlds where the parallel postulate was violated. Equality became inequalities. The angles in a triangle used to add up to and equal 180 degrees. With inequalities, they were equal to something less or more than 180 degrees. The constraints changed and with those constraints, worlds changed. The above figure shows the relations between the underlying geometries and their curvatures.The constraints asserted differences in control. Are you inside the curve or outside the curve. All of this becomes a roller-coaster ride.

More on Geometries

A curve has an inside and an outside. That curve exhibits both geometries depending on the anchor of your view. The right and left branch of a decision becomes a choice between one curvature or another, so decisions chose geometries.

Geometries and Their Angles

So here we lay out the relationship between angle and geometry: Sum of angels of a triangle =180 degrees, Euclidean; Sum > 180 degrees, Spherical; Sum < 180 degrees Hyperbolic. Einstein’s space-time is hyperbolic. But, where are the controls? Right. Well, shapes control, lines control, points control. Put them where you need them.

Decisions as Bezier Curves

In graphics packages like MS Paint, or Adobe Illustrator, or say, just about all of them these days, Bezier curves are the first place you run into controls that define a line, a path, that are not on the line or path itself. My first run in with such things was NURBS curves. When I ran into them, I thought, hey, this is cool, because adding a control point didn’t change the curve. It just granted you the possibility of additional control deeper into the future, deeper into your strategy. I’ve since come to discover the same kind of control points in numbers themselves, polynomials, hell, everywhere. It is just the way mathematicians and even logicians do things. And, those of us distant from math and logic do it as well. Do you keep your apartment or ditch it when moving in with her/him?

Do we grant ourselves degrees of freedom or commit?

But, what of the previous figure? The endpoints of a Bezier curve are fixed on the spline. The four points and three straight lines constitute a spline. The spline defines the Bezier curve. There can be more lines and points to this spline. The four points are control points. You move the control points to change the curve, aka to control the curve. The deep coolness of these controls won’t be revealed until the last paragraph of this post.

Decisions and Control Points

Here we’ve made the control points as decisions explicit by annotating each decision with a triangle.

Decisions Constructed

If you’re a reader here, you know that I use a large triangle, non-iconic, to represent decision trees that result in realizations. My use of this symbology is something I call the Triangle Model. Decisions are realizations. Decisions are constructed, built and later made. In the figure above, the circles structure the curve, and the tan-colored triangles build further controls that control the implementation of the curve, aka the line. The triangles imply many decisions made by many people,  potentially many organizations either cooperatively, or in a zero-sum, linear programming face off. Each decision tree contributes a limiting surface to the overall definition of the curve.

Decisions and Geometry

Here I’ve added a few more details to the surface hugging curve. Before it makes sense, I have to step back and bring up a metaphor I first came across in a philosophy-based logic class. Truth is not the central issue in logic. Validity is. Validity asks the question, is the argument constructed correctly. Validity is a question focused on the plumbing, not the truth or falsehoods flowing through that plumbing. Validity is about the carrier of logic itself. Truth is about the content conveyed by that carrier. Logic as a whole is about a carrier and its carried, so logic is a media. Similarly, mathematics is likewise a media. This does not become apparent until you bump into parametric equations. Those equations can be thought of as tubes. The value at time t, is a place in the tube. The point can even spin if you’ve built quaternions into the equation.  Never mind what a quaternion is. It spins. That’s enough for now. So math is a media. So software is a media.

In the figure the pipe is larger than the point. The pipe is like a water slide. A point starts out on the centerline, then finds itself on the pipe wall. It moves from being symmetric to the pipe to being asymmetric. It is on one side of the pipe, one edge, then it rotates or switches to the far side of the pipe to take advantage of a curvature. The point makes a decision. It starts out in a Euclidean world, a flat world, then it finds itself in a spherical world, but preferring the hyperbolic, due to its corporate capabilities, it switches to the other curvature on the other side of the curve. Then, it moves to the symmetric position in the centerline of the exiting Euclidean pipe. Yes, your company is the point in the parametric equation.

Decisions and Geometry Abstractly

In this figure, I’ve firmed up the structure of the ride your company will take as the point in the parametric equation. That structure is a control. Companies ride such structures all the time. They don’t necessarily build those structure, but they do try to exert some control over their traversal of such structures.

Inside-Outside Geometry

Another view of that structure, but here we ask different questions. Can your company function on the outside of a curve, in the spherical? Can your company function of the inside of a curve, in the hyperbolic? Can your company traverse between the spherical and hyperbolic, and back? Can your company find a place in the linear, the Euclidean and maintain it deliberately? It’s not enough to stick with the linear assumption.

Decisions and Surfaces

Here we highlight the structure, the surface, or in business terms the situations upon which strategy is built. Those capabilities mentioned earlier were abilities to execute at specific moments and during specific time intervals. Those capabilities were put there by strategy in anticipation of structuring situations.

On Surface

The technology adoption lifecycle is one of those structures that technologies, products, categories, companies, industries, whole verticals, and whole economies traverse. That single linear assumption doesn’t get far in the varying densities of populations, events, and intervals comprising the lifecycle. A traversal would occur through the distribution, a distributed control, and given the Poisson distributions comprising Moore’s bowling ally, many distributed control populations. That traversal would not be a surface ride. That traversal would engage differential games of rates interdependent with other navigational aspects of getting the technology, product, sidebands, company, channels, ecologies, sales, revenues, and profits done.

The Borel set enables the calculation of probabilities for mathematicians. The Borel set informs businessmen that the population if fixed. That fixedness should inform the myths of growth, and the ignored reality of decline and it’s incipient myth of “Who us? Decline, never!” Ask Kodak and stop talking about disruption. It was Christensen’s good management doing what they do. It wasn’t some attacker having labelled itself as disruptive in it’s pleas for VC funding.

On the TALC Surface

The technology adoption lifecycle (TALC) surface describes the totality of your category, not your company. You could scale the normal to represent your company. Still, macroeconomic considerations are better shown at category scale.

In this figure we assume the company has made it the point where they have consumed 50 percent of their full lifecycle, available market without missing a quarter and without incurring the wrath of Wall Street. They reach their aftermarket and are subsequently lifted into the realm of the Fortune 500 companies with their much larger market size via the dreaded M&A. Still, they face discontinuity, and of course the M&A typically fails, so much for the red line, so much for the linear assumption, and usually so much for growth.

On the TALC Surface Again

Here we see the point of the aftermarket, the point of an M&A, the point of the huge public company, and the point of the startup. The telcos will make ten times more money from the Internet than the startups did. The telcos could not have brought internet technologies into adoption. Web content startups are not fostering adoption–adoption of those underlying technologies has been done for a while now.

Polynomial as Control

Here we go back to the math to generalize the polynomial as a sequence of controls made explicit by the assertion of a waiting, but implicit, control. This hints back to the NURBS curve control points and how mathematics does this all the time. We solved polynomials without ever using them. No wonder mathematics wasn’t fun. It would have been fun to take on our advanced biology teacher during the test reviews with a ton of math. That’s probably why it wasn’t taught.

A Point

So what’s with this point? We all have point like this. Ask our significant other.

Measurement Lattice

We’ll be getting the point of that point soon enough. That point is consistent with other points in a cloud of data, big data if you like. But, all those points are waiting around for a line to show up. “Yeah, no line gets past me. I’m an outlier, a tough guy. Hype that big data all you like. There is nothing out there beyond me.” Beyond the collected data is the implicit, which will remain implicit. The data collection explicated an expanse of space.

Measurement Lattice-Data-Regression Extent

The regression traverses the extent of the collected data, but goes no further. The regression provides a structure for parametric traversal.

Measurement Lattice-Data-Regression and Dimension Extent

The dimensional extent of the collected data controls the dimensional extent of the regression and regression-based forecasts. In the figure, the 3-D dimensional projections from the regression are invalid. Degree elevation won’t work here.

Controls Again

The control zoo once again. What species of control do you want to exert. As I’ve read more mathematics I’ve become interested in more mathematics. Warning! Danger!

Decisions and Surfaces

Like the TALC, macroeconomics is another controlling surface. Your curve will have to work around macroeconomic surfaces.

Decisions and Market Allocation

Market allocation significantly limits where your lines can go. Market allocation is a control. The market allocation circle is based on the normal distribution of the technology adoption lifecycle. Moore defined a formula for determining maximum market share based on the ordinal entry of a competitor into a category. Later entry would find not only smaller revenues, but also a shorter interval of participation in the category. If you arrive later without a new technology underlying your efforts, aka without having the capacity to create a category, you’ll be leaving sooner.  The circle provides controls.

Stakeholder Preferences

Here stakeholder preferences are incorporated as controls in the earlier figure of the role of macroeconomics as a controlling surface.

So you’ve seen some of the structures that control the line we once considered to be just a linear assumption. As out last view of curves for a while, I’ll talk about the subdivision of a Bezier curve as a parametric equation. Look in Google to find several animations of Bezier curves. I found them very interesting. So on to why.

Bezier-Curve Subdivision

In the above figure, the base spline is shown in black. The first subdivision is drawn in red. In the animations the red points subdividing the black lines start at the one endpoint of the line and move to the other. All of the red points move across the line they are on. The second subdivision is drawn in green. The green points subdivide the red lines and move across the red lines. The third subdivision is provided by the black point subdividing the green line. The resulting curve ends up being descriptive of a three-tier hierarchy, or a corporation. Adding another point to the base spline would insert another subdivision, and another layer in the hierarchy.

Try moving your controls around.

Leave some comments. Thanks.

My Long Tails

Chris Anderson popularized his version of the long tail in his book “The Long Tail.” I read the book and went on to use it to model software. Richard R. Reisman applied it to create a pricing model. I just came across Reisman’s work today, so it will take some time to think about, play with it, integrate it, and get back to you.

The last weekend in October found me attending Seattle Product Camp 11. I didn’t drive. The road trip is still a dream. I haven’t flown in something like eight years, that flight eight years ago didn’t involve layovers or luggage. The experience of flying has changed over the years, depreciated, but gotten cheaper in a few dimensions and more expensive in others. Flying is a good time to be on a diet, or a fast. A $10⁺ patty melt is a pocket melt. Still, I enjoyed Seattle and #PCS11. It was the first time I got to experience Seattle in overcast rainy weather, an improvement over LA’s bland constant sunshine, or the teasing Texas drought that hints, but never delivers.

Back to those long tails. I proposed a presentation for #PCS11, Long Tails and Thick Tails for Product Managers. The thick tail part of the presentation was intended to link my presentation at #PCS09, Game Theory for Product Managers, an advanced topic, since I didn’t want to get into the details of minimax, and the neatest thing was Poisson games, or games with an unknown population of players–the typical technology adoption problem. Poisson games linked to ideas that we were talking about at the time on the Anthropology for Product Managers tweetchat, Functional Cultures. The #PCS09 presentation led to my proposing of another presentation for #OC10, So you don’t have a market? Great!, a presentation about organizing markets with Poisson distributions and Markov chains, something that Moore hinted at with his bowling ally idea in Crossing the Chasm. One of people attending the #PCS09 presentation said of six-degrees of separation that it implied a thick tail. That statement laid there begging to be dug into. So my presentation in Seattle was intended to reply to that, and to make me sit down and collect my ideas about long tails and thick tails. They went far beyond software as long tails before it was over. It’s still not over. Just another question to stew on.

Alas, I didn’t actually get my proposal submitted for voting. The topic blew up. The sessions got shorter. The summary was illusive. Had it been finished it would have been three times too long. I’m still putting the presentation together even now. I’ll post it as a SlideShare when I’m done.

Getting back home,  Ruud Hein over at SearchEnginePeople asked me to write another guest post. So I wrote up the long tail part of my #PCS11 presentation. The presentation was intended to show how a long tail can be applied to model many different processes we bump into in product management and product marketing management. One of those models integrates product management and product marketing, a topic hinted at in this post on functional cultures.

So consider

Long Tails Beyond SEO

to be part one of a two if not three-part series that would have been my #pcs11 presentation.

My previous guest post on Rudd’s Search Engine People blog was on how I write my Strategy as Tires tweets. The title in the post was Ruud’s. I do my wall flowering thing at conferences.

Ruud, Thanks for the opportunity to guest post on your Search Engine People blog.

Comments!

Science as Ito Process

In a cryptic tweet , “Ito stochastic process n>=0, science. Knowledge=explicated +forgotten,” I was replying to Trevor Rotzien’s tweet of “Science isn’t static statements of universal laws nor a set of arbitrary rules. It’s an evolving body of knowledge.” In that response, I was defining science as a random, statistical process, or more simply a process that exhibits certain characteristics. Then, I tied that definition to that of knowledge. Being a tweet, I left something out of my definition of knowledge. I’ll put it back in.
Knowledge is a cyclical process of doing something artificial intelligence people call explicating knowledge, turning implicit/tacit knowledge into explicit form or explicit knowledge. The moves in Argentine Tango can be described explicitly, but practice puts that explicit description into your muscle memory where it is no longer explicit. It is implicit. We practice to re-implicate or make implicit that explicit knowledge. Science discovers through wide, vast, and history spanning explication. Discovery is explication.

Knowledge has its highest value not in its explicit forms, but in its implicit forms. Craft production is implicit production. Even explicit production has us using tools that embed explicit into an implicit media. A hammer is all the decisions made to stuff comprising the hammer and the hammer producing process.

Ore is dug up. Ore is transported. Ore is fired. Ore is oxygenated to make steel. Steel is poured, …. The Ore truck has an accident, so this whole hammer production process engages randomness. So the hammer production process is a random or stochastic process.

Stochastic processes come in two flavors these days. A few years ago before generalizing one flavor they came in two different flavors. The flavors have to do with how much memory is involved in dealing with the probabilities of the transitions from one state to another in the stochastic process. We had Gaussian/Bayesian and Markovian stochastic processes. Gaussian/Bayesian stochastic processes take into consideration the entire scope of the history of the known, small world to determine which state transition to make. Gaussian/Bayesian stochastic processes use all the, or the complete memory, n=infinity. Gaussian/Bayesian stochastic processes live under normal distributions. Markovian stochastic processes make state transition decisions without any memory, n=0. Markovian processes live under Poisson distributions.

Lately, Markovian stochastic processes have been generalized as an instance of a class that we call Ito processes, aka stochastic process with less than complete memory, or 0<=n

Machine learning shows us that Markovian/Ito processes are processes that discover new rules. Gaussian/Bayesian processes are processes that enforce rules, but do not discover new rules for yet to be explicated phenomena. So science is a process of discovering new rules, aka Markovian/Ito. Science education, aka the generalist culture of science express themselves as othodoxies in the general form of Gaussian/Bayesian–all knowledge propositions.

Normal (Gaussian/Bayesian) distributions are the limiting distribution or shape for Poisson distributions. This implies that as a collection of Poisson distributions attempt to cover the same data as Normal distribution the shapes or distributions converge. Poisson distributions converge faster than Normal distributions. Discoveries become orthodoxy. Poisson distributions are tall and narrow. Normal distributions are lower and wide.  Correlation and statistical significance require normal distributions of sufficient height and separation.Poisson distributions lead to Poisson games that I presented in a session two years ago at PcampSEA 09, “Game Theory for Product Managers.”

Functional cultures, like expert-based science transition from the generalist culture under the normal distribution to an expert culture under the Poisson distribution. The process of technology adoption moves from expert to generalist, from Poisson of the newly discovered to the normal and the disruptive fight with the incumbent orthodoxy. This is the process of learning. There are mirroring processes of de-adoption and forgetting.

Forgetting is a process of moving from the infinity of state transition histories of the normal distribution towards the no/(zero)-memory state transitions of the Poisson distribution. We forget by successively omitting the most distant state from the decision about the next transition. We will have forgotten once the zero state transition is eliminated.

Discovery is a queued process as well. We distill random variation down to a steady state. That steady state is Gaussian/Bayesian. Forgetting is likewise a queued process that starts with the steady state and admits random variation until only random remains. Poisson distributions describe queues, so Poisson>Gaussian/Bayesian>Poisson is the way of knowledge. It is likewise, Science.

So that’s what that tweet meant.

Since product managers move product to move a technology across the technology adoption lifecycle, we deal with these distributions and others as we get the job done.

Sorry about not having graphics for this post.

Comments? Thanks!

PCS11, More on collaborative games

Product Camp Seattle 11 (#PCS11)

Two years ago I planned to run up to Seattle from LA for PCamp Seattle 09. I put up a survey to find out what presentations I should propose. That survey gave little guidance to the preparations. Then, life happened, and I ended up in Texas, so being a Rand McNally trip plan dreamer, I put a trip plan together that would take me across some states I’ve not been to before like Wyoming and Montana. That PCamp was held in early October. I was a warned of snow. See the first trip plan. I drove the Junction to Ballinger route the last time I left California. I’m not going that way again. This year, I’ll take the Austin to Brownwood route, my usual route to Santa Fe when I lived in Austin. I’m uncertain as to Lubbock to Muleshoe or Dalhart. I might try to hit the drive-in movie in Abilene this time if it isn’t closed for the season. The Capulin volcano and Raton pass always beckon.  And, I’m definitely stopping in Boulder on the way up. Who knows, I may dance a few tangos in Denver.

Anyway, more life happened, so I ended up routing through California and going back to California for a while, instead of returning to Texas. I’ve still not made it to Wyoming and Montana. I ended up back in Texas.

I missed PCamp Seattle 10. But, I’ll make it back this year. I’m definitely going to make it to PCS11. I’m still wondering about what to present.

The presentation I didn’t give at OC PCamp 10 was too long in terms of delivery time, and it wasn’t particularly interactive, “So you don’t have a market, Great!”.

I’ll write a Product Strategist post to introduce whatever I decide to talk about at PCS11.

Collaborative Games

Kenny Bastani’s comment to my earlier post needed a follow-up post to answer the issues raised. We tweeted it out instead. The question did take me to some interesting questions.

I started out with a list, but that struck me as too simple. Then, it was a normal-form game. Then, back to a collaborative game. Each line in the Shapely Value polygon is recursive, yet another Shapely Value polygon.

In the midst of the search for an answer for Kenny, the Fujuyama nuclear plant caused Toyota to halt production, because of supply chain interruptions. JIT logistics is the kind of efficiency that you get from the equilibriums of pure strategies derived from the normal form of a competitive game. You get to those equilibriums by eliminating alternatives that are dominated, or dominating depending on the role of those alternatives. We seek an optimal solution, a single source. But, here is a risk that wasn’t accounted for in the game, so the game must stop for a while. Call this risk a black swan, or a thick tailed distribution.

A mixed strategy solution to a normal form game would approach the outcomes of a pure strategy, but not exceed it. A mixed strategy would generate a solution in terms of area, where the pure strategy gives us a point solution. The point solution gave Toyota the JIT logistics. The point solution eliminated the opportunity to leverage the alternatives that dominated and dominating removed from the solution set. Shapely Values generate solutions in term of area just like a mixed strategy, but more so.

I’ll leave my discussion with Kenny in my timeline. He posed interesting question that took him one place and myself to another. I took Kenny to be asking about orchestration, something very important to product managers. Orchestration is the place where inter-organizational work happens, so it is the deepest depth at which an application can provide value. I’ve talked about process orchestration and choreography in posts on the Triangle Model, which I don’t particularly write about in this blog, because it was a core theme in earlier blogs for many years. I have mentioned the Triangle Model in the following posts:

• Building a Dog. Oh, Make that a Cat
• Now that you have that Cat
• Gary Hamel’s Pyramid and the Triangle Model

The recursive nature of Kenny’s Shapely Values would be fractal if the recursions were the same shape as the parent or subsequent children, but that isn’t necessarily the case. The recursions hint towards grammar.

To get to process orchestration and choreography, you work out from the interface into what would be a core of a Shapely Value. For my purposes, since the Triangle Model is a decision tree, that core would delineate the decisions necessary to create that value in depth, a depth starting at the view or interface and working outward in layers: features; tool (artificial) tasks; user tasks; work design (intra-organizational); work (intra-organizational)–collaborative, if you will, or sequentially pipelined; inter-organizational work design; and inter-organizational work.

When dealing with layers, minimal marketable functionality (MMF) would deliver value to a defined depth across only a few layers. Deeper value takes customer organizations some time to reach, so delaying later, more distant layers makes for a profitable roadmap. Delivering a single layer at a time minimizes expectations. However, tool tasks (carrier) enable user tasks (carried), so a single MMF would have to deliver at least those two layers. Notice also that Gartner’s Hype Cycle is about value in depth.

Carrier and carried denote the components of any media, or my software as media framework. All software is media, not just those that are obviously media.

I’ve been through a huge change during my absence. Many new questions and insights arose in that time. Ask a question. Post a comment. I’ll answer. We’ll learn together. Thanks!

Geography for Product Managers

This post was written in response to this comment on The ordinals we call a clock.

Geography has been my theme for a while now. Functional cultures present us with geographies. Ideas present us with geographies. IT departments present us with geographies. Interfaces present us with geographies. Interactions between minimal marketable functions present us with geographies, likewise, product roadmaps. So what is a geography? My take is that a geography is anything that can be better expressed in a GIS system, rather than a list. Is time an issue? Are the relevant issues spatially organized? Then, you have a geography.

When I was working as an ITIL change manager, we were adding the change management component of ITIL to an existing ITIL implementation. I was supposed to track down managers willing to be responsible for improving their change management processes. I was supposed to find the potential conflicts between changes scheduled to be made to code, hardware, and other infrastructural elements across a huge IT shop in any particular time interval. It took me one day to decide that this was a GIS problem. We were trying to get this done via a relational database system and Excel. Oh, hell. Worse, I said that we needed a GIS system on my second day on the job. They were installing an upgrade or a completely new relational system at the time, so ….

Just keep your mouth shut until you’ve wired the joint.

In their system, you had wires, tons of wires, routers, switches, network stuff. That is was physically located in particular places tied to physical geography quite well. Servers exist in physical space. So drawing the map of their physical system wouldn’t be that difficult. So before we make a leap let’s explore this geography and what it means in terms of game theory.

I took my son on a spring break trip down Route 66. Route 66 emerged from the efforts of various chambers of commerce along the route and the states involved. The road was a bottom  up, business proposition from day one. It is obviously geographic. Services were stretched out along this road. The road is celebrated today as history and a user experience–the stories of the road.

Several value chains stretched down this road simultaneously. In one sense, the cafe in this town competed with the cafe in the next town. But, in the larger sense, the road, competed with other roads, so all the competitors on the road collaborated in the competition between their road and the other roads.

So lets look at the road as a value chain and move it into a Shapely Value representation.

Route 66 - Discrete

Here we take a length of the road and partition it into sections based on the contribution made by each town along the road. That town has a geographic reach. Using the frequency of use idea would let us build other measures of the value contributed by each town along the road.

Route 66 - To Numbers

Next, we measure the length and normalized that length. When you  normalize a collection of numbers, the largest number becomes 1.0, and the other numbers, except for zero, become some fraction of that number vs. the largest number. Normalized values express probabilities. Notice that the existence of the road is taken as a given. If a section of road where to become impassible, the value of much of the road would disappear soon enough. Likewise, if your trunk connection to the internet went down, the value of your enterprise network disappear while you were screaming into the phone. Ah, but for redundancy.

If all of this were in a GIS system, we could consider gas station pumps, beds, lunch counter seats, booths, tables, tourist attractions, movie houses. We would be playing many games.

So our next rep is the Shapely Value of our road.

Shapely Value

This representation was built from the totals from the previous figure. This representation is optimal, as such it assumes maximum collaboration. The Shapely Value is a number equal to the area of the gray area, the core, in the figure. The white area represents space that cannot be reached due to inefficiencies and the lack of the necessary capabilities.

The Shapely Value is typically introduced as a 3-party game, which leads to a triangle. It is also three dimensional, which puts it at the limit of our ability to visualize. Shapely Values use perfect polygons, aka polygons where each side is the same length. This just makes the math easy, but the math is not based on shape. Matrices or tables are used to compute the value of each coalition.

Shapely Value - Suboptimal

In this figure, the town associated with the value 8 is having some problems and is not contributing to the value chain to an optimal degree. The town associated with the value 18 has not been impacted, but all the other towns in the value chain are seeing their earnings decline.

That’s just one value chain. Instead of cities, think about your network infrastructure. So now we’ll move on to a server, a server hosting a database. That server is in town, a city unto itself. It connects to another server hosting a data warehouse. There are connections upon connections, layers upon layers, maps upon maps. You can imagine it yourself. Just try mapping out your Twitter experience, or your blog host and RSS feed reader experience. Diligence will get this map done. You will end up with game upon game, onions of games. GIS is the tool that can take you there. Relational can define a single layer, but the toilet map, otherwise known as the sewage system doesn’t relate well with the electrical system.

There I was working hard to do a GIS analysis with an RDBMS, but I was wondering why ITIL system vendors hadn’t gone GIS. It’s probably cultural. If your IT organization hasn’t gone GIS yet, why would an IT management system be the first to do so. Ultimately in the abstract, it all boils down to features and how they relate to each other. All those features end up on a vector. Bivectors relate vectors, but work makes those features work.

In an application, its features comprise a coalition. Each feature contributes to the value a customer derives from an application to different degrees. Since I prefer to deliver features as networks of related functionality, or minimal marketable functionality (MMF), because it enables me to deliver some value to the customer, the economic buyer, earlier, allows users to learn the application over time, and allows a vendor to schedule their revenues and cash flows more consistently, I’ll focus on the MMF as the unit of coalition.

In the comment, Kenny Bastani, asked about a list of “features” that tend to be layers of crosscutting concerns or aspects, thus leading to Aspect-Oriented Programming (AOP). His considerations were

• Integration of CRM, data warehouse extracts, aligning vendors for product integration, designing a support strategy for all third party systems and data integrated into the product?
• Security risks for centralizing a data layer from so many different systems?

To get our hands around this, we can consider each aspect to be a vector. When I talked about bivectors in the previous posts, I summed them up into a single technology vector, a single product vector, and a single business components vector. Vectors sum up easily enough. But, let’s take a more expansive look at the base vectors that were summed up.

Summed vectors

Back when we sold technology, instead of a webpage, the product was built on top of a technology. Customers bought the product, but installed and configured that technology before the product would work. Much of that technology was already present in the product. The product wouldn’t install otherwise. With webpages, we use a server, a browser, tons of technologies, but we don’t sell any technology. Our products are not fostering adoption of some technology. The underlying technology has already been adopted and for the most part is situated in Moore’s late mainstream market, much of it approaching the horizontal asymptote at the top of their S-curves. These technologies that we use, but don’t sell per se, are our whole product components. The cloud likewise, our whole product components. In this figure the whole products are shown as one summative vector, instead of as a collection of individual vectors representing each component. Notice that the granularity and summative vectors or not is up to you.

I’ve shown two technology vectors to illustrate that a vendor that actually sells a technology will always need a second, subsequent, discontinuous technology available to switch to when the initial or prior one commoditizes. In my Slideshare presentation, I summed these vectors and their S-curves, starting with slide 53. But, in the Framing Post For Aug 12 Innochat: The Effects of Booms and Busts on Innovation, I came to realize that not only are these technologies discontinuous, the market is likewise discontinuous. Why this surprised me is just that I knew this for discontinuous technologies, you can’t sell the next one to your current market, but I had not extrapolated that to the vector and s-curve visualizations.

For both the product and business components in the offer, I used a shorthand, the eigenvector to build those vectors. Why shorthand, well, I’m not showing that each minimal marketable function (MMF) or business capability (BC) need not be aligned. Showing them aligned was just quicker to draw. The current representation isn’t like an eigenvector, in that eigenvectors are used as unit vectors. I do think of MMFs that way, because MMFs originated with feature-driven design (FDD), an agile approach, which means that a single MMF is delivered in a single release. That release is a timeboxed across all releases. Think one per quarter and tie it to the quarterly revenue goals of the subsequent quarter. The BCs are another matter. By capabilities I mean not just processes, abilities, people, but also policy. Policies arise or are explicated from implicit expectations in a mostly reactive, event-driven manner.

A company can be represented by its cost structure and policy structure as vector

Aspects as Vectors

This figure takes us back to the comment. Each of those aspects in the comment can be represented by a summative vector, or that vectors collection of base vectors. When all the vectors for an aspect share an origin, via translation, just because we want to do that, we end up looking at what linguists would call a morpheme, or a probability cloud defined by those aspect vectors. When laid end to end, we end up a road. The road shows us that we can get to a Shapely Value with any collection of vectors.

All of this goes to show us that we have our vectors of differentiation. Those vectors compete and collaborate. Those vectors have an internal price/cost and an externalizable performance, a performance relative to a market, large or small. Those vectors have populations involved with them, and from the Slideshare presentation that implies Poisson distributions, Markov processes, grammar, machine learning associated with them. Those vectors have triangle models associated with them and several other representations I have yet to discuss. Math is a massively distributed, collaborating population of various types like people, ideas, theorems, calculations all rolled up into a massive geography that no one is entirely familiar with.

So goes any IT system as well. Please, do your ITIL people a favor. Get a GIS system. They need it.

The math under the Shapely Value is easy. Google it until you find an accelerator that makes it easy for you. The point behind the Shapely Value is that the system has more value in it than that obtainable by its parts alone. This should make it clear that value is not at the interface, it is in the interactions deeper into the space of work where your feature feeds someone else’s, where emergence and radiosity tip their hand.

Comments?

The ordinals we call a clock

I remember Campy saying that reengineering wasn’t about object oriented. This was back in the day when object oriented was new, as was reengineering. It struck me as hilarious that a business person would say that. Campy wasn’t a programmer. As for me, I lived through things before the computed GOTO, the computed GOTO, structured programming, recursive COBOL, and information modules that blew up the compiler in one version of IBM P/L I, and didn’t in another–thankfully. I lived through professors that we not yet caught up in object oriented. The one thing you can say is that structure made programming easier, and object oriented made it easier yet, so I wondered why reengineering wasn’t about object oriented.

When I was reading Moore’s technology adoption lifecycle (TALC) books, I ran across his claim that the lifecycle is not a clock. Sure it is. This before that. That before that other. That other before this here, …. It told you what to expect the next time your business was in for a big change. So the TALC has been a clock, an asynchronous clock as long as I can remember.

An asynchronous clock is a weird clock. Try talking about time in an email thread, or even a twitter thread. Most of us, I’m sure have had to deal with our machine’s clock ignoring the network server’s clock. Yes, a mess, but a clock nonetheless.

A person with one watch knows what time it is. A person with two watches never knows. Worse the person with one watch is turned into a person with two watches whenever they have to meet someone with their own watch. We live on islands of time. It takes a whole lot of trouble to keep everything synchronized even if don’t leave our timezone.

So here I was reading a lightweight math dictionary, Eula Monroe’s Math Dictionary, and somehow the term “clock” was included. How many other math dictionaries have I read that never included “clock?” I didn’t really read the definition. It was simple enough. The definition laid in wait until I got to “Clockwise.” A clock is an ordered number line. It didn’t mention the base thing, base 12.

Ordered! That means ordinals, which I blogged about back in Ordinals for Product Managers. These ordinals were the expression of your stakeholder’s preferences. Ordinals express the relationship between things in terms of one being first, second, third, and so forth. Ordinals lie at the core of game theory. Ordinals act as constraints in linear programming problems. This preference must be met before this one. Pretty much, we need this amount of revenue to assure this amount of cash flow, and maybe some profit to boot.

In an offering, we mix minimal marketable functionality from the product with business offer elements from various organizational units in the hopes that value emerges and gets paid for. That offering can be visualized as a bivector. I mentioned bivectors at the end my last blog post, Constraints. But, I jumped the gun, because I showed you two bivectors, instead of just one.

Two Separate Bivectors

Here I’ve blow up the two, overlapping bivectors from the previous post and shown them as two separate bivectors. We do generate our offer components separately. In the late mainstream market, where the web is today, product managers need to think about the biz components. Every statement asserted in a policy is a biz feature. Invoicing, billing, shipping, reporting, licensing, all of that stuff is a biz feature of an offer it it interacts with the customer or the user. Likewise, customer support and technical support add their features to the biz offer vector. Some of these features migrate to software. In preparation for entry into the late mainstream market from the early mainstream market, if your company is doing this, migrate some of those biz features to the web and get the customer used to using them.

But, what about the ordinals we call a clock? That some goal/preference is first, doesn’t mean it gets done first. It’s more likely that it will get done last, but it will be comprised of and be an reflection of our success in achieving all those other goals/preferences.

Clock and Goals

In this figure the primary goal, expressed in terms of quarterly revenues and profits, doesn’t happen until after the close of the next full quarter after the release. It is the end of the clock when we move counterclockwise, but we have to achieve the underlying technology before we can productize it and turn that product into sales. Unroll the clock. Unroll your calendar as well, and put those preferences on the calendar. The calendar is ordered as much as a clock is ordered.

In game theory, the normal form game, the table form, represents a simultaneous game. No clock is involved. You play the infinite game to play again. You can find your saddle point, or your strategy mixture that optimizing your outcomes regardless of what your opponent does. Time is not leveraged. You build the capabilities to achieve your strategy, hence your outcomes, then you leave it be until some change forces you to change your strategy. Change happens, so change happens. You don’t get to let it be.

Game theorists tell you that if you wait to see what your opponent does, you can move from a normal-form game to an extensive form game where the players take turns. The temporal network can become messy.

Like our offer bivectors, the vectors are built independently. In the clock as ordinals representation these capabilities are independent games summing up much like a Gantt-chart roll up.

Ordinals move. You talked to the stakeholders last week. You know what they wanted. You can’t deliver all of it. So who will loosen their preferences? Why would they loosen their preferences? Once loosened, are they deliverable? It’s not enough to listen. You have to push back. You have to educate, to persuade, and to ensure that once the roll-up goal is achieved no matter how far way you are from that.

This leads somewhere.

When I graphed my first normal form game to find the saddle point, I hadn’t read the theorem that insists that your game has the same value as your opponent’s game. I just read that the row player’s value of game is the peak at the bottom of the graph.

That First Game Graphed

I’ll own up right now. This graph is not correct! The following is correct. The red point is the value of the game generated by minimax and maximin. It is the value of the game for both players. Much is lost if all you want to do is find the optimal.

Corrected Graph

The incorrect graph does show something I found interesting. If we were talking about the physical constraints in our offer, the technology, it shows up a temporal map of the our technology palette. It’s one of those maps that researchers have in their heads expressing the temporal layout of their field. It tells us when a given problem will be overcome. It shows us the pathways. It doesn’t, but I made the leap. So jump, this creek isn’t that wide.

The reason it doesn’t is because we built our BI and fusion networks looking at something else.

This map is still important. So lets just use what it tells us. What would our pathway be if we were to compete at the black dot?

Pathways

The red position resulted from your existing or planned capabilities: A, B, and an unnamed one. The unnamed one doesn’t lead further into the future unless you broaden the scope of your offer. Progress in improving capability A stopped a while back, but you still have people working on it. B is still being worked on as well. A and B exist as real options. Further investment in A and B will move your company forward.

If you continue improving A, you will reach C. C would be a totally new space for your company, so you would have to spend money and time to achieve your performance beyond the point were A meets C. C, if you have defined it well and can communicate it clearly, is a good candidate for open development. You don’t need to own C. You just need it to exist. The further C is from your core competencies the less willing you should be to create C yourself.

Likewise, improving B will get you to the point where you need D. C will get you to D as well. Again, another potential open development project.

The way open is talked about today it ties into the idea of open standards, and partnering. Neither are necessary for open development. Culture fit isn’t necessary either. Nor, your active management of the open enterprise. If you don’t have the time or resources, find someone else that can do it. They are not doing it for you. They are doing it for themselves. It’s critical not to waste your managerial focus, or to denigrate their management. They know how to manage their business. You are not a client or customer. You just had an idea. What you need is to get that idea on the market, so that it arrives when you do, so you can leverage it. That’s all you need, and that’s all you can expect.

I ran across this particular view of open development at an Orange County PDMA meeting. An executive from the Newport corporation presented their approach to open development. A few meetings later, a panel presented the usual “cultural” fit view. In Moore’s “Living on the Fault Line,” Moore discussed what to outsource, what to keep, and what to wonder about. The core reason to outsource was not cost, but to preserve managerial focus. Unfortunately, managerial focus is implicit, thus unmanaged. I asked panel members if they knew how much they individually added to the cost of their outsourcing. Their response was that they had budgets, but that didn’t answer the question. Most employees of corporations, including CEOs, don’t clock ideation, or thinking unlike consultants and people in say the advertising business, who sell ideas.

If we could see the boundary as a boundary land, rather than a boundary line, we’d know it was thick. We’d know that in that thickness is options, opportunities, room to maneuver. We’d know that there is a clock. We could look at the S-curves of each of those vectors and decide that we’ll route through the traffic to gain speed without being faster. We’d route A>B>C>D, and if B didn’t show up we’d skip it and move on to D with a route of A>D. The route would depend on our estimation of which constraints would yield first. Given enough money, as in we work for “The” market leader, we could undertake both pathways. We could jump the intersection CD and work out from there with a new organization that works outward towards both the red dot and the black dot.

We would figure out where zero hour was on our clock and move clockwise and counterclockwise to ensure that we hit our financial goals, keep the financial markets happy, and split our stock.

Our clocks need not be linear anymore than our product roadmaps need to linear. So let’s be a little more asynchronous, a little more respectful of the managerial skill of those in our value chains, a little more non-linear.

Comments?

Constraints

Well, I’m thirsty, so before I start in on constraints, I go over to the sink and fill my glass with some water. Crash! That glass of water just hit the floor. Now I have water and broken glass everywhere, and I’ll be thirsty for a little longer.

In the above incident we encountered a constraint in the form of a glass. It held water, organized, packaged it, and could have delivered it to my lips. The water in that glass had value. Neither the water nor the broken glass on the floor have any value at all.

A technology breaks a constraint to enable new doings, or weakens a constraint to enable doings that are faster, cheaper, better. The former translates into a benefit, the latter into fleeting advantages. That technology comes to the market in the form of at least one product. All products, services, experiences, events, channels, etc are manifestations of collections of constraints.

When you make a decision, you are constraining that which you are not enabling. The binary decision is a partition, a line, separating two half-planes, each half-plane being an alternative awaiting choice. Statements can be restated as a question, aka a decision, so statements are constraints. Requirements constrain. Functional requirements constrain the what. Non-functional requirements constrain the how by demanding how well the how is done.

Kuhn’s “normal science” characterizes constraints. There was a time when the Earth was flat. This due to constraints. There was a time when we feared breaking the sound barrier, again a constraint. Overcoming these constraints took the bravery of a lot of people who conducted experiments to characterize the constraints under specific contexts. Eventually, a context was discovered, characterized, and found to be one way to slip past a constraint. Sounds like the Enron accountants. Such contexts attract more experiments. The crack in the constraint lowered the risk, so it became the producer for the experimenter consumers. The crack became a niche environment. That crack eventually became the dream of the Concorde.  The crack eventually became the sonic boom which in turn became a constraint on the dream of the Concorde.

The sonic boom was the constraint to be faced after breaking the earlier constraint–pure Goldratt and his Theory of Constraints. The sound barrier is a physical constraint. The Enron situation and the sonic boom were decision-based constraints. Breaking a physical constraint can create wealth. Breaking a decision-based constraint captures cash. Changing a decision can be hard due to policy structure, cost structure, and people issues. But, nobody is stopping you from changing your decision except yourself. If a physical constraint was easy to break, it’s been done by now. The asymmetry dividing these classes of constraints should be a clear indication of the asymmetries in outcomes.

Easy means closer to entropy, closer to that broken glass strewn out on the wet floor, closer to zero in terms of value, closer to the minimum. Harder means distant from entropy, closer to the glass filled with water, closer to the maximum value that can be obtained in the situation, the context.

In Odifreddi’s “The Mathematical Century,” we find David Hilbert laying out a list of mathematical challenges. This list is essentially a list of constraints on the progress of mathematics. Hilbert’s list served to propel research agendas. Hilbert isn’t the only person that can see the constraints ahead. Product Managers need to see those constraints. Customers may not see them, but those constraints will drive strategy, or you might call it vision. Vision is a non-forecastable jump from the current capabilities of a business to those capabilities needed to generate new growth, aka wealth. Such vision drives strategy design, implementation, and operationalization.

Mathematicians use regression to create equations. Those equations are characterizations of some phenomena. The data collection efforts represent an experiment.  Researchers conduct these experiments differently, so  when they go to combine data from different experiments, they have to do some statistics that lets them know if it the data is compatible. By the time a constraint is fully characterized, you end up with a collection of equations over different intervals. Those equations might span different dimensions. It’s much more messy than the stuff in our game theory textbooks. We’ll just call those equations constraints and keep moving.

When you create a product, many different constraints are involved. A product can be characterized as a collection of linear equations. A while back out on twitter there was some discussion of the hole that a product fills. That hole could be characterized by a collection of linear equations.

The Hole the Product Fills I

In Ordinals for Product Managers, I talked about stakeholder preferences. Those stakeholder preferences were expressed as inequalities, which in turn become additional equations in the collection of linear equations. The linear equations representing stakeholder preferences appear in blue in the following figure. They further constrain the solution. They further define the hole the product must fill.

The Hole the Product Fills II

Since preferences are decision-based constraints, they can be changed. A product manager can influence these constraints. Business model issues are a class of decision-based constraints.

That post was about game theory. It also mentioned curves as collections of segments of convergent lines. We will discuss both of these topics further in this post.

A curve as a collection of segments of convergent lines used the Cantor set definition of convergence. A number can only occur in a set once. Using the Cantor set definition, a line is said to converge to a limit if it repeats the last value in the set. The first occurrence of that value is the limit. When a function moves in a given direction as it approaches a limit, the function ends at the limit, and no projection can be made outward in the direction of the approach to that limit beyond the limit. We’ll run into this disappearing act again. We ran into it earlier when we talked about those collections of experiments, their datasets, and their resulting regressions over various intervals.

Cantor sets can also be used to represent projections of curves.

Cantor Set As a Projection of a Curve

When a line is nonlinear, much will be hidden. Beyond this, linear is preferred, because the math is easier. When you productize mathematics like von Neumann did, the math better be easy.

The red arrows demonstrate how the projection on the Cantor set looks like an attractor. This attractor is what a fast follower sees, provided they don’t physically have your code. This attractor is what a decision-support network’s fusion process sees.

Software developers hide decisions all the time. They hide them in their version control system. When it’s time to ship you put aside the stuff you are working on right now, ship, and then return to another round of search divergence and decision-driven convergence.

Beyond what is hidden in version control systems, a fast follower will only see the Cantor set that they can build from their point of view.

Those systems of linear equations can be tough to solve, so von Neumann developed linear programming. It was tougher back in his day with slower computers. Solutions can still take a long time. Game theory ended up using linear algebra and linear programming, or in summary, constraints. So lets look at game from the perspective of constraints.

Game Theory as Constraints

Every line in this figure is a constraint. A game is constrained by its scope. A game is not constrained by time. Game theory is really about making a long duration strategic choice as to how the game will always be played. You play to play again. The infinite game is assumed.

A game is also constrained by the need for easy math. In normal form, a game is presented as a matrix of ordinals. You can add to an ordinal, but there is little beyond that that can be done. These ordinals can be negative, but by adding a sufficient, positive offset, you can convert negative values to positive ones. Call this task sublimating the product. It’s something that must be done when selling to the pragmatists in the late market.

The two lines that intersect are likewise constraints. They summarize the real (approximate) and assumed operationalized capabilities of the companies facing off in competition. The effort to generate this summary involves data collection efforts and later doing a regression analysis on that data. The intersection of those constraints is the solution to the game, the value of the game. Notice that the value of the game is the same for both players. The intersection is likewise a saddle point, or the equilibrium.

Saddle Points

This figure shows a saddle point in the graphic representation, the normal form representation, and in terms of say a mountain pass. Saddle points or equilibriums can be found using the minimax or the maximin methods. If no saddle points exist, you move on to mixed strategies. Minimax translates to “the lowest highest point.” Maximin translates to “the highest lowest point.” Those expressions describe the same point. In the normal form representation, minimax has you finding the maximum of 4 and 0. Maximin has you finding the minimum of 7 and 4. In either case, the answer is 4. That they are the same goes back to the von Neumann’s Minimax Theorem (1928).

A company is supposed to occupy the highest position on the value chain. If every company on the value chain does this, they can only do so, because they have different capabilities and different cost structures. They are managed to different ends.

Value Chain in a Graphical Game Theory Representation

The value chain is comprised of your suppliers and customers. Notice that the strategies used  by the company obtaining the highest value in the value chain, drives the entire value chain.

When a game is played at a level above the optimal or below the minimal, nothing is gained. Given the infinite game assumption, strategy is established and remains constant across the infinite game. This is just one of those unrealistic assumptions. Agile enterprise advocates probably over do the change mantra a bit, but all companies must change all the time, so strategy is a changing, living thing.

The companies in your value chain may also be in the value chains of other companies, so their level of play may exceed that necessary for your strategy. That they are playing at a higher level suggests the need to reposition your company, so it is once again the highest value player. You might need to buy your value chain member.

Value Chain with M&A

Such an M&A would reorganize the constraints of the game. Your competitor would have an overcapacity, as indicated by the dark gray, and you would have to evolve your capabilities, as indicated by the light gray. Of course, M&A are hard and rarely succeed, but notice, what you didn’t do was compete against your own supply chain. You did not duplicate their capability. If we were talking software here, we didn’t fast follow, we didn’t borg them into your infrastructure, so nobody had to buy their product anymore. Had we done that, we would get closer to the game theoretic ideal of capturing only small or no gains in the infinite game. Duplicating functionality commoditizes! Don’t bother. Please think of something original and go through the technology adoption lifecycle–create wealth, instead of poverty.

Basis of Competition

This figure extends from the Game Theory as Constraints figure. In the immediately preceding figure I hinted at how a company’s capabilities would change. Here I extract a bar chart representation of the capabilities. The bar chart is labeled Basis of Competition. Notice that the strategy enabling capabilities are shown as triangles on the graphical representation of the game. Those capabilities must be implemented once the decision to commit to a strategy has been made. That is the second execution in the strategy is execution statement I hear quite a lot. The first execution is the design of the strategy decision, the SWOT and all that. The third execution would be the operationalization, which occurs once the implementation project has created the processes that ops will eventually run. I always feel like asking “Which execution? The one on Tuesday for the mass murderer?”

Notice that the basis of competition bar chart should debunk the game theoretic assumption that your competition is just like you. No, we just face each other from our trenches on our side of the DMZ.

Time to Strategy via Triangle Model I

Once you see strategy as a set of capabilities, then you understand that those capabilities must be realized. Gartner came up with the Time To Return (TTR) after they defined the Total Cost of Ownership (TCO). Yes, a strategy has a TCO and TTR. I’ve referred to the TTR for strategy as the Time to Strategy (TTS).

The red lines in the figure are the game theoretically defined deliverables. The thick green lines are the realized deliverables. Here we’ve assumed that they are the same. But in an earlier post, I talked about how we don’t realize every feature to the same extent. That implies that there would be a gap between the red lines and the thick green lines. That gap would represent suboptimal performance. Process improvement and best practices were intended to close these gaps, but where these programs pushed performance beyond the minimax optimal, they introduce waste. Balance is required. Know how far you must go, and go no further.

Time to Strategy via Triangle Model II

Here the concentric circles represent the speed of the teams implementing the capabilities. Successive releases of those capabilities were required.

Time to Strategy via Triangle Model III

Here we have simplified the diagram.

Time to Strategy via Triangle Model IIII

Here we show the game theoretic ideal as futures and the realized implementation towards those futures as actuals. The business side of a software vendor has the same kinds of project management issues that a product would have. Realize that your competitors will likewise have capability gaps.

In a software startup, we realize our technology, our product(s), our business, and our markets simultaneously. One idea that expresses this well is that of a bivector, a mathematical object, comprised of two vectors. The vectors in a bivector are operated on simultaneously by bivector operators. Pick any two of a startup’s realizations, omitting market, and assign each to one of the vectors comprising the bivector. An offering is a bivector comprised of both product and business components. Those vectors would be eigenvectors, so the length of each vector would represent a collection of business capabilities, or product features.

Two bivectors

Market would be a vector from biz to product and vice verso. The technical evangelist/technical enthusiast market, would be a similar vector from biz to tech.

Many parallels exist between these two separate aspects of a software startup. As a product manager, don’t rest with thinking that product features is it. At specific phases in the technology adoption lifecycle the business components of the offer will expand or shrink.

Comments?

Feature Terrains, Networks of Frequencies

I’m reviewing mathematics. Actually, I hardly have time to review, because I’m finding so many new to me insights in my general reading of mathematics. This reading has me parked at bookstores and the public library. Some of these books go fast, some slow, some so thick with mud that I’d rather be doing something else. When I’m in that no more math frame of mind, I’ll do anything else, but typically end up looking for another book.

At the public library non-fiction juvenile books are filed in with the adult books, so there are a lot of fun titles that turn out to be really quick reads. Elsie C. Ellison’s “Fun with Lines and Curves,” is one of those. I looked at it quickly one day, boring. On another day, I looked at it and though, hey neat. And, here I am blogging about it, because it answered one of those nagging, persistent questions I had about how I’d get from a user interface to the long tail. But, combine that with some of Norman Wildberger’s linear algebra YouTubes and I had an avalanche of ideas. Norman’s videos finally got the eigenvalue concept on firm ground, and introduced the bivector. I still remember the tweet about brand being an eigenvector. Yes.

I’m not going to go over all that today. I’ll show you Ellison’s visualization, hook it to a user interface, add some use frequencies to it, and abstract it out to the long tail.

Ellison is a teacher who wanted to make mathematics fun. Draw two lines that intersect. They need not be perpendicular. Then mark off some positions on those lines. They need not be unit measures, nor do both lines (axes) have to use the same unit measure. The number of positions do need to be the same on each of the axes. Then, on one axis, number your positions from the intersection to infinity in normal order, and the other axis in reverse order. Once the axes are ready, draw a line from a numbered position on one axis to the position on the other axis having the same number.

So for those of you who haven’t taken out a piece of paper and a pencil, here’s the figure.

Our Example

Notice how the straight lines laid out a curve.

The nice thing about this diagram is that it represents a network (Metcalf’s Law). If we use a table, we know that we throw away half the entries above of below the (1,1), (2,2), …, (n,n) (x=y) line. The surprise is that in this figure, you can’t network with yourself, and you can’t network with people you already networked with. No just talking to co-workers from your functional unit. Eventually, you’ll meet the CEO. And, yeah, you PMs only get to talk to the key customer once, rather than over and over in a attempt to like not meet the rest of your customers, the ones not so keen on your prioritization schemes.

I drew the above figure last. Here is the first one I drew. I was a little stiff.

Network Representation

Stiff as in a little to Cartesian.

So we have a network, and everyone can reach everyone else. It reminded me of hypertext theory with it’s links (associations) and nodes, and graph theory where links can be node and nodes can be links, much like vectors being arrow to some and points to others. Don’t worry, hypertext theory is still theory, and a link just displays another page, runs some javascript, or whatever, but never yet reaches the places that hypertext theory would take it, and us with it. We’ve stalled out a bit. Just pull up on the noise of the aircraft to maintain its forward airspeed into that barn ahead.

Network of Nodes and Links

The red circles at the intersections, the nodes. The black lines are the links.

Using fractional notation in this diagram was just plain wrong! The numbers are just addresses, so use some other syntax. Do not treat them as fractions. Why the warning? I spent too much time doing that and not getting anywhere. One half showed up all over the place, so I didn’t end up with a number line. Why would I do that? Well, math is like that. Why worry about the 16B^th hexadecimal digit of pi? Or, why was it that I did so much type conversion back in the day. Things matter when you climb into them that would never matter if you just walked around the exterior. I was trying to linearize the eventual probabilities I’ll associate with each intersection (node) later.

When we talk about features, or minimal marketable features we are talking about networks of such features. Rarely will a feature stand by itself. A feature like a dialog or a web page will need to be opened or displayed, used, and then closed or exited from. Using features can also mean engaging in a feedback loop. So lets look at one such network. We will open a file in MS Paint. I didn’t go into detail selecting the file that we’ll open.I am opening the file from within Paint. The file could be opened from the file browser in Windows, but that would be framework functionality, which appears at the hits end of the long tail.

Opening a File in MS Paint

Now, I’ll take this network and place it in Ellison’s network graph.

UI Components in a Task Network

Here each line is associated with a particular UI component. Line 1 is associated with the main window; line 10, the Paint menu control, which opens the Paint menu associated with line 2. The options on the Paint menu are associated with lines 5-9. The Open command is associated with line 6. Not all the menu commands have been included in this figure. The recent files list was likewise omitted. The file menu is represented by line 3. The open file shortcut keys are associated with line 4.

The open dialog is only represented by a single line. All by itself, it would involve a huge graph.

As for the main window, I originally showed it empty and again with the file opened in it. I would have to extend line 1 to show both. The past would end up in the background. This was more straightforward. It’s fit for a particular use, and not for some other use.

Next, I add the frequency of use histograms for each node in the task. Coming up with the frequency numbers might involve looking at your server logs, or capturing the use data by some other means. It doesn’t require a lab with video cameras. You also have to decide on scope. Will you count the frequencies for all whole product contributors, or only those that originate in your own code? I’ll leave that up to you. Let’s just go with the idea that the histograms here are illustrative.

UI Components in Our Task Network With Use Frequencies

Once you have your use frequencies, you can order the histograms by height which sequences them into a distribution. That distribution will be a long tail, or a thick tail distribution, which we discussed last week in Search Scarcity.

Long Tail

The long tail for this minimal marketable function is shown as a discrete and a continuous distribution. When additional minimal marketable functions are added, the histograms will separate down the long tail. Some features like the keyboard shortcuts might never be used. That histogram will be far down the long tail. Hopefully, you won’t have features that are never used.

APIs have similar use frequencies associated with its function calls.

Looking back at the task network, the red lines represent a single use case. Live data would constitute a use scenario. A user story might be built from a network or tool task like the open task. Nobody, except the police, buys an application to open a file. Well, maybe a geek. I’m sick of downloading files from professors and ending up with .ps files or others that I can’t open. But, the my point stands. Nobody uses independent disk pools, a feature provided by the IBM i-series operating system. They do geo-mirroring, which in turn forces them to use independent disk pools. Tool tasks are the task we do, because we are using a computer. Most web apps have sublimated file system tasks. Users are happy.

Going back to hypertext/graph theory, the red lines hooking the features together represent a task. We could say that the red lines sequence some symbols, the features, and the whole thing represents a grammar going back to compiler class. We could go further and layer another network on top of the one in our figure, so that the task, a tool task, is a node in that network. Then we could link those tool tasks into a user task.

We could go further and create more layers each working further an further from the interface, from the features. This visualization would give us a better view of the value that our features support and that our customers realize.

Yes, a kids book was full of surprises. It had some great features, and was put to use well beyond its design, but mathematics is good for that.

I even had to reconsider bivectors, but now it has blown me away and given me some new ways to see the issue of cost and policy structure. That down the road a bit. Next, constraints, something that came up in early January. I’m so far behind.

Anyway, go down to your public library and peruse the math section on the kids shelves if they are separate. Pick a few books out, and yes, you know that stuff, but you’re in it for the serendipity, the epiphany, the shock of the boring, the surprise, the leverage, the fun, the point of view of a kid. You see a number is a measure. Life is thick. Numbers are thin. Kids see different, aka paradigmatic culture right there at our knees. You didn’t know they had a kids book on growing up to be a product manager did you?

Comments? Thanks!