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

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

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

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

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

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

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.



3 Responses to “Geography for Product Managers”

  1. Kenny Says:

    Excellent post David, thank you for taking the time to present these findings. The Shapely Value will be a very useful tool for me to communicate value contribution in the chain.

    A few questions:

    Let’s say that aspects were non-normal and that responsibilities varied among players across multiple projects. Also, let’s say that we wanted to determine the aggregate total contribution over an N number of projects where the system’s value output is generated in different channels.

    In example: Player 1’s skill set is dynamic to play any role (developer, project manager, product manager, tester). Player 2’s skill set is specialized as a project manager only. Both players are working cooperatively on the same projects.

    Player 1 contributes value for different vectors of skills required for the project. Player 2’s direction and magnitude are mostly constant in the project manager skill vector. Player 2’s magnitude increases as Player 1 increases magnitude of other vectors to meet deadlines and shifting priorities of the multiple projects.

    How could you change your strategy over the course of the projects as the Shapely Value responds to resource constraints and priorities? How could you determine when to add and remove players with different skill sets to keep the Shapely Value in the center? How do you modify the Shapely Value to account for a project’s total value to the company? It almost seems like each project could be a player and each resource could also be a sub-component player of each project.

  2. rabbitupnorth Says:

    This was so well written that I could actually follow it, for the most part, even as a relatively unsophisticated reader. It may be theoretical abstraction in some senses, but it seems to be rooted in the same reality I can relate to. Well spoken. It gives food for thought, which is, I am sure, one of its objectives.well done, David.

  3. Product Strategist Says:

    […] Bastani’s comment to my earlier post needed a follow-up post to answer the issues raised. We tweeted it out instead. […]

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: