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.
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.
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.
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.
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.