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

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.