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

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

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

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

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?



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.



3 Responses to “The ordinals we call a clock”

  1. Kenny Bastani Says:

    Great post David. I agree with you, asynchronous is the way to go.

    One thought though, you only touched slightly on integration and product support. From my experience in enterprise, the biggest concern of the stakeholders is the customer. This is assuming we are building a product that is customer facing.

    What are your thoughts on business integration:

    Thoughts on 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?

    Also, what about security risks for centralizing a data layer from so many different systems?

    How would you apply the game theory to organize full cooperation for integrations?

    How do we model a support structure that provides useful analytics for measuring ease of use (a primary concern for customer facing technologies)?

    • davidwlocke Says:

      The game theory that would cover your needs is cooperative game theory. Look at the idea of “a core.” In competitive game theory, when a pure strategy cannot be found, a mixed strategy is used. A pure strategy resolves to the intersection of two lines, a point. That point results from the solution of a system of equalities. That point is the optimal solution. A mixed strategy will never exceed the value of the pure strategy, because it results from a system of inequalities. A mixed strategy is a collection of strategies expressed in a mixture specified by the odds associated with each strategy. The effect in a mixed strategy is to fill an area or space with noise that originates with those odds. Over a long period of time, the mixed strategy outcome approaches that of the pure strategy. Still, the mixed strategy will result in a lessor outcome than a pure strategy if that pure strategy were possible. The core of our cooperative game is space filling and considers the permutations of contributions of the various contributors. In the core, cooperative outcomes can exceed the individual outcomes. What is explored is the mix and frequency of expression for that mix. Core leads to Shapely Value.

      In a recent blog post, I drew a figure that showed a graphical solution to a normal form game with adjacent value chain contributors. The prime vendor’s optimal defines the optimals for the vendors participating in this vendor’s value chain. These value chain contributors have their own individual game, so their optimal will be different from their optimal generated by a single vendor.

      As for the rest of your questions, I have a blog post or two to write.

  2. rabbitupnorth Says:

    You express complex ideas in a framework that makes it comprehensible to the layman. Fascinating comments!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: