## Ordinals for Product Managers

As product managers, we deal in ordinals all the time. Well, we call them preferences. “Hey, Joe, is F more important to you than J?” “No, H is more important than F. I don’t care about J.” So we are left with H≥F≥J, or it might be better to just drop J in this case. Hopefully, Joe and the other people you deal with have consistent preferences. Joe doesn’t change his mind every other day does he?

Ordinal numbers express order, as first, second, third, ….
When game theory was created, the numbers in those normal form games were called utils, and utils express values as ordinals. You can’t do much with ordinals. You can’t add them, or back then you couldn’t. I’ve come across more recent mentions in the game theory literature that assert that ordinals can be added, but I’m hearing the screams in my head, as the supports for game theory are kicked out from under it. Same thing happened to calculus as it evolved its geometry roots to its contemporary formal, abstract basis. Calculus didn’t die from this.

Later, game theorists found that not having to deal with negative numbers was easier, so they would add the same constant to each ordinal. That doesn’t change the order of the numbers, so this is OK. Adding a constant made the numbers cardinal. Cardinal numbers are about how many. Confusing, but the cardinal numbers are still ordered.

I encountered the cardinality of utilities in Game Theory and Strategy by Philip D. Straffin. This book is the second best book on game theory. Read The Complete Strategist by J.D. Williams, the first.

Illustrating the differences between ordinal and cardinal numbers.

The Calculus Surprise
We’ve all seen the limit stuff in our calculus classes. But, in my reading of Carl B. Boyer’s The History of Calculus, there is much more going on. Calculus was a product that went through successive discontinuous innovations. It starts back at the ancient math and demonstrates how Kuhn’s incommensurates played out in mathematics. Incommensurate concepts create gaps that result in subcultures and paradigmatic changes, or opportunities to create new markets.

A function converging to a limit as the number of intervals increases.

The partitionings in the figure gave rise to two sequences. The number of partitions is directly related to accuracy and computation time of the associated limit. The limit is said to be the sum of a collection of sequences. The surprise was when the Boyer said that the sequences were ordinals. Ordinals refer back to the underpinnings of game theory.

Line as a Collection of Segments of Convergent Sequences
I read that a line could be defined as a collection of segments of convergent sequences in Nonstandard Methods in Stochastic Analysis and Mathematical Physics by Sergio Albeverio, et.al. It struck me as a neat way to visualize the sales process. Each sales rep is working a handful of convergences towards the revenue line. Each sales rep has their own process and tempo, rate, or clock–or partitionings of their convergences. There are many sales reps, so there are many partitionings that contribute segments to the revenue line.

The whole firm could be visualized as a line as well. Being convergences implies that all of the partitionings are ordinals.

The line of convergence could be a straight line in the sense of strategic alignment. But, the line is not restrained to being a straight line. If you want to turn the line, you pick a particular segment of a convergence that is going your way.

A Curve Built as a Collection of Convergent Sequences

It turns out that the curve in the figure above is also ordinal as it orders the contributions of the convergent sequence segments. The partitionings need not be the same for each convergence.

For a product manager, each segment contributing curve represents a single preference. The resulting curve satisfies all the preferences. It may not be real world to think that satisfying all stakeholders is possible, but that is the goal.

Factor Analysis
When I got involved in the Anthropology for Product Managers tweet chat, I started reading sociology and anthropology books. I came across a mention of scree graph, which turned out to be the end result of a factor analysis. A factor analysis is a multivariate statistical method that determines the multiple regression lines and the weights of each. Each regression line represents a single factor. That factor can be a roll up of a hierarchically organized collection of subfactors. The first three factors typically represent 85 percent of the variance in the underlying data.

A factor analysis graph is discrete. It looks like a long tail, Pareto or power law distribution. Plotting a frequency of use for an application’s functionality would give a similar graph. Likewise the frequency of use of each minimal marketable function, aka a network of features delivered as a whole, would give a similar graph. And, likewise for task performance, an ordered collection of feature interactions.

Factor Analysis and Decision Support Networks

The factor analysis is shown on the left. The resulting factors is shown in brown. A decision support network (DSS) is shown on the right. The DSS is shown relative to the first factor. The DSS feeds all factors even as I’ve hinted at separate DSSes. The actual data, sensors, and regressions would be different for each factor. In a normal form game, each number in a cell would have its own independent DSS.

Factor analysis would be an unbiased way to find product management metrics. When we discuss this topics and pick metrics, we are actually biasing the metrics. Metrics should be relevant to your specific organization. Generic metrics will neither fit your organization, nor measure your performance. When doing a factor analysis collect a wider range of data than you think you will need.

Barry Bohem’s Software Economics, got thinner in later revisions, but much was studied before it came down to better programmers made for better programming.

Going back to the factor analysis figure, notice that y-axis partitions are relative to the percentage of variance covered by successive factors. The x-axis partitions order successive factors. The partitions for both axes are ordinal, but ordinal only on the axes. You can’t be ordinal in two dimensions, or I have yet to encounter such a thing. Still, there is such a thing as “her second first” given she just broke two world records. The partitions need not be some unit size.

A Little Game Theory to Boot
Normal form games play in the partitions space and DSS space. Strategies have a frequency of use. In fact, mixed strategies assign frequencies to the strategies used. Frequencies imply power law distributions. Given that normal form games are highly discrete to the point of each cell having its own DSS, they can be discrete like factor analysis.

Abstractly a normal form game with a saddle point will divide strategies into different classes: the saddle point, the row and column involved with the saddle point, and the rest of the cells. From a BI/CI perspective, these classes are budget allocations. Will you be watching your adjacent competitor closely, other competitors less so, and non competitors hardly at all? Are you willing to close your eyes and be disrupted? Do you have a budget to spend on data?

Game Theory, Decision Support Networks and Factor Analysis

Once you have allocated your sensor/data (blue triangles) budgets, you get to build your fusion (orange triangles) nodes, your analytical processes. Build these analytical processes with an eye towards continuous surveillance, again a budget issue. How frequently do you review your choice of strategy? How frequently do you actually change your strategy?

Ultimately, data feeds your factor analysis. Ordinal partitions determined by the factors. Those ordinal partitions tie to stakeholder preferences.

While we have talked about convergences, doing factor analysis to cover 100 percent of the variance is prohibitive. Think in terms of convergences to an epsilon of something between 85 and 100 percent.

Preferences as Partitions
Now we will go back to the game theory notion of preferences. Every stakeholder from the board to the janitor to the economic-buyer customer and the user in the customer’s organization has preferences. Rationality depends on consistent preferences. The ordinal nature of preferences get messy quick if preferences conflict.

As a product manager, dealing with conflicting preferences is a must be addressed issue. Eliminating these conflicts will depend on persuasion and proactivity. Getting this done will just make your life easier.

Below is an example of a collection of preferences.

An Example of Preferences from the CEO to the End-User

CUST32 might give rise to a conflict between the CEO and CFO relative to preference G.

Once we have the partition network defined, we can move back to the partition/interval representation.

Preferences As Partitions

As a product manager, when you read a job ad, you are seeing a few of the organization’s preferences. As you interview, you will meet a few stakeholders and they will reveal their preferences to you by the questions they ask. As you are on boarded, you will be exposed to more stakeholders and their preferences.

Once on your own, you express your own preferences by the amount of time you spend with various stakeholders and how well you understand their preferences, aka how well you know them. They express their preferences, likewise, by whom they spend time with and relate to.

The product manager will search the organization for preferences. You can search in a breadth-first manner, or a depth first manner. You can search randomly. As you find preferences you fill in the partitions on your line, the revenue line, the launch line, your career line.

Preferences Search

Here the triangle represents the space searched. The preference line is updated as new preferences are found, or changes to preferences are communicated.

You can partition the search space and search them independently.

Simultaneous Search

Once you have your preference partitions laid out, you can draw your own line as a collection of segments of your convergent sequences.

You will never complete a preference search. It will spread out over time. It will require proactivity. It need not be ordinal (top down). Searching for preferences is the ceaseless activity of a product manager. Other people satisfy those preferences. Their preferences motivate them. Knowing those people helps you lead them as they satisfy the preferences you’ve discovered.

### 5 Responses to “Ordinals for Product Managers”

1. Sean Murphy Says:

Can you elaborate on “Kuhn’s incommensurates” ?

• davidwlocke Says:

Thomas Kuhn’s “Structure of Scientific Revolutions” talks about discontinuous innovations. Relative physics was discontinuous to Classical physics. Calculus was once based on infinitesimals, which originated with geometric intuition, but with the advent of Cantor’s set theory, Calculus is now based on limits, a formal, non-intuitive conception. Incommesurate ideas are ones that cannot be explained from the same basis. Even object-oriented programming was incommesurate with functional or structured programming before it was weakened into an extension of functional programming via gets and puts.

The real problem with incommesurate ideas is that they are embodied in adopting populations as paradigms, or subcultures within some larger culture. In Physics, a culture, you have classical physicists comprising one subculture, and quantum physicists comprising another subculture. These subcultures are mutually exclusive, built around idomatic expression and exclusive meanings, and they have different risk tolerances relative to the ideas dividing their populations.

What this implies is that when we collect requirements from the collection of cultures that turn up in the market segment we serve, is that we are averaging across mutually exclusive meanings. The cultures involved could be using the same words and meaning different things. An accountant will tell you that capital is cash. Some economist will tell you that capital is a collection of laws. Obviously, they are not speaking from the same perspective. A product manager hires a technical writer and tells the writer to convert the test spec into a manual. The writer writes a task-based manual based on actual performance of the underlying software. The product manager wanted a feature-based manual irrespective of performance–a denotational. Again, a misunderstanding sourced from a culture the product manager didn’t understand, or bother with.

Incommensurates are even harder to find, because organizations are not built around them. A functional unit is the silo. But, within a given silo is a collection of generational paradigms. The manager selects the paradigm they operationalize. The other workers must work in that paradigm, but they were trained closer to the leading edge, the state of the art. Eventually, one of those workers will become the boss and change the paradigm moving the department closer to the once state of the art. But, who among these people do you collect requirements from? Again, you average.

In terms of ordinals, thing about them as non-functional requirements for the software, or business. The CEO says, “I want to generate \$.5M in revenue from our installed base with the next release.” The VP of Sales says, “I want to generate \$1M in new customer revenues with the next release.” These goals actually conflict, but the VP of Sales is not more important than the CEO. The VP of Dev says, ” I don’t have the budget to hire new team members.” The customer’s say that they want various tweaks, and bug fixes.” The VP of Marketing says, “You are not our highest priority in the next quarter and that your budget is \$xxx,” too low to meet the VP of Sales goals. The CFO says, “the next release will be in 90 days.” You are not going to please everyone. Call it a problem with preferences. Call it a lack of alignment. Call it a matter of paradigms. You will have to influence these stakeholders if you are going to win. The business requirements always constrain the functionality delivered.

Incommensurates do help a product manger if they are facing a tough constraint that won’t be broken soon enough, because the gap implies that there are other directions to approach the constraint from. Finding a different point of view means that you might be able to beat the constraint for the next release.

2. Factor Analysis, Long Tails, and Stacks « Strategy As Tires Says:

[…] Analysis and Scree Diagrams In my last blog post Ordinals for Product Managers I described a scree diagram as the product of factor analysis. A factor analysis is a form of […]

3. Requirements as Circles « Product Strategist Says:

[…] changes would result in some rescaling of the measurement axes of the individual stakeholders. See “Ordinals for Product Managers” for more information on stakeholder preferences, ordinals, and […]

4. Constraints « Product Strategist Says:

[…] Ordinals for Product Managers, I talked about stakeholder preferences. Those stakeholder preferences were expressed as […]