Archive for June, 2010

Taxicab Geometry

June 18, 2010

A few weeks ago, I didn’t have my notebooks with me, so I started reading a book new to me, Taxicab Geometry. It was interesting, but I didn’t get very far into it. I tweeted about it. But, ended up getting frustrated by it.

During those tweets, I said it tied into product management, and that I’d blog about that. So this is that blog.

Non-Euclidean geometries take one or more rules or definitions and alters them. In Taxicab Geometry, consider yourself in some hypothetical, theoretical town that’s been laid out in a grid without any diagonal streets. Then, try to figure out the distance between two addresses are given that you can only go north, south, east, or west. In effect you have a digital geography.

In my earlier post, Building a Dog. Oh, Make that a Cat, I wrote about how to build an ontology measuring differences in bits, or measuring differences in terms of minimal marketable functionality. Both of these ways of laying out a geography tied into the notion of measuring the distance between a dog and a cat in an abstract sense. Calculating the distances would require a taxicab geometry.

In the dog and cat conceptual models, I claimed that there are sortables for concepts, but didn’t tell you what they were. So to find a more concrete example, I’ve looked into the word processing category to establish how MS Word and Notepad relate in taxonomic terms.

Taxonomies sort out realizations, things real or made as real as they can be. While ontologies sort out conceptualizations, things, or portions of things that have yet to be realized. Requirements capture conceptualizations or ontologies, while taxonomies classify delivered functionality. Taxonomies and ontologies coexist in an application. Taxonomies and ontologies are built up from classifying decisions, taxons and ontons for short. You end up with networks of these decisions, or decision trees, depending on the scope of the world you develop and compete within.

A Word Processor Taxonomy

A Word Processor Taxonomy for MS Word and Notepad

Our taxonomy of word processors, shows that the core functionality is the ability to edit text. Every word processor enables you to edit text, or it isn’t a word processor. A text box in any application provides rudimentary text editing functionality. This taxon sorts out the products competing in the word processing category from those outside the category.

We go on to further differentiate products, so additional taxons are needed to sort out the products within the word processing category. I wanted to sort out MS Word and Notepad, so the taxons were ordered to that end. The ability to search and replace, and move and copy functionality was all that was needed to complete the decision tree relative to Notepad.

Notepad does do page layouts, headers and footers, page numbers, stylesheets, or mail merge, but MS Word does. So each of these features becomes a taxon and helps us organize MS Word among its competitors. These taxons put distance between Notepad and MS Word.

This hierarchy demonstrates how software companies differentiate their products at the delivered functionality. But, software companies compete on ideas or concepts within conceptualizations, or at the ontology long before they compete on realizations. Technology adoption provides the nascent lifecycle for a conceptualization.

A word is turned to name the category, another to name the company, other words for new functionality. Our competitors come along and say yes, we are like them, but different. Our competitors define their ontologies differently. They add sortables. They define their lexicon slightly different as well. You end up locked in lexical warfare long before you sell your differentiated product. The differentiation changes and expands. The differentiation faces off not only in a one-to-one manner, but in a one-to-many manner as well as subtree and leaf fights, tree vs. tree.

Users construct their own conceptual models based on interactions with the realizations. They like this realization. A particular realization matches the conceptual model they had when they first started using the application better than another realization, another product. Better matches means incomplete matches, so these realizations have different costs relative to the use of the realizations. Eventually, if you application stays around long enough, an artifactual culture will spring up around you product’s ontology. Ontologies encode meaning. A product comes to mean something.

Even without considering our conceptual geographies we construct them. Taxicab geography is about distances within those geographies. So lets look at a map of an ontological geography and go for a drive calculating some distances as we go.

An Ontology on a Grid

An Ontology on a Grid

Here an ontology is represented by the black lines, branches, and squares. The root of the ontology is the black square at the top of the tree. Each sortable or onton is represented by the branching decision. The yellow and tan rectangles are measure of distance. Distance is measured up and down the tree (north/south) and across the siblings of each onton (east/west). Each black square is labeled by its distance from the root in black or gray. The light blue or orange numbers represent the distance associated with a measurement unit. The bottom number (left) in a measure represents the tree depth (north/south) distance. The top number (right) represents the sibling count. Both numbers are added together to arrive at the distance measure for a given concept, or black square.

The bottom right concept shows a distance of 8. It is on the forth row below the root, so its depth measures accumulated on the path from the root to itself is 4. In this representation, each of its ontons along the path assign it a sibling distance of 1, which in turn sums to 4 along the entire path. Both distances sum to 8.

The gray concept on the left, has a distance of 5. It’s distance from its immediate parent is one, with a sibling measure of zero. I was trying to stick with the gray grid as a means of measurement, but that didn’t work. I’ll redraw this figure with a strict unit measure. A zero sibling measure means that it is more specific than the immediate parent, the more general concept.

A zero sibling measure turns up in other ontons in this figure. They screamed at me that the representation wasn’t working. So I redrew the figure.

Ontology on a Grid with Unit Measure

Ontology on a Grid with Unit Measure

This figure differs from the previous figure in that a standard unit of measure is used everywhere, except where a single general concept is further defined by a single specific concept, the gray box of distance 5 (black). Further, the way the branching is represented gives a unique sibling distance to each sibling.

I also measured distances in different ways. The Stack (red) distance does not count siblings. The Sortables/Ontons (green) distance counts only the sortables/ontons (green outlines around relevant boxes) omitting the leaf. The Leaf (blue) counts includes siblings. Each of these different distances represent different geometries, typical of non-Euclidean geometries.

The book went into how circles would be represented. One of the exercises has you dividing up an city into school attendance zones. This was interesting, because it shows you how to allocate space in a category, aka market, or roles to competitors, complementors, and even open innovation. Moore pointed out in his technology adoption lifecycle books that a near monopolist is safe until they capture more than 74% of the market, which hints towards the 26% of the space that cannot be had. If you can’t have the space, you can still determine outcomes in that space.

I’ll get back to that book. The ontologies in the examples here would also be subject to the user’s cognitive limits, so the logarithmic schemes laid out in Cognitive models on the Efficiency Frontier, Innovation Visualization, and More on Innovation Visualization would apply, and would depend on how one counts, and the user’s knowledge of the underlying ontology.

Comments?

Gary Hamel’s Pyramid and the Triangle Model

June 11, 2010

In the Hypertextual blog post Gary Hamel’s pyramid of human capabilities, the author discusses how Hamel applied Maslow’s Hierarchy of Needs to organizational needs and aspirations. Hamel’s Pyramid structures those needs and aspirations into layers, as follows:

  1. Obedience
  2. Diligence
  3. Intellect
  4. Initiative
  5. Human creativity
  6. Passion and zeal

It struck me that I could use Hamel’s Pyramid to extend the Triangle Model in a new way. In previous extension, I used the Triangle Model to move from the interface, to tool tasks, to user tasks, to work design, to work, to workflows, to choreography, to orchestration, to further meta-management issues. I’ve used Maslow’s Hierarchy as vendor-client organizational interface. I’ve thought about applications as games and how game design could inform application development given the nature of feedback, discovery, collaboration, and entry into flow in the use of B2B software.

I’ve discussed some aspects of the Triangle Model in Building a Dog. Oh, Make that a Cat!.

Here I started with a development triangle, which resulted in a realization at the interface or Features, the first thick black band from the top. The resulting triangle represents the decisions that shipped with the release of the latest version of an application.

I show a user, who is working through their own domain-specific requirements, design, and implementation decisions. When an application is used, the effort and decisions project through the features provided by the application. This projection is a decision tree, or triangle with its own realization, the second black band from the top, the user’s work product.

The user’s realization is just a part of some larger work being done across the organization, so there is another triangle that projects through the user’s realization, and results in its own realization, the third thick black band from the top, the organization’s work product.

Beyond organizational work is extra-organizational work or value chain interactions that involve choreography, orchestration, and such. The black band at the bottom of the figure, shows this triangle’s realization.

Hamel's Pyramid Beyond the Triangle Model

Hamel's Pyramid Beyond the Triangle Model

The layers of Hamel’s Pyramid begin below development’s realization, aka Features.

The tool task layer is closely tied to features. This is a very obedient layer. The features may give you two or three ways to do something, but you don’t get to be creative or complex. Submitting a form or saving a file are typical tool tasks, tasks you are forced to do, because you are using a computer, or a specific platform, aka whole product components. Sales reps see CRM systems as enforcers of blind obedient doing. They hate it. It wasn’t designed to be otherwise.

User tasks are done by sequencing tool tasks and other tasks together. When writing a letter after formatting and creating of all the mandatory components of that letter, the composition of the message is the real job to be done, or user task. Formatting and mandatory components are tool tasks. The greeting is a mandatory component which originates from an intersecting domain, an intersecting technology, called writing a letter. That letter has its own requirements, design, and APIs, if you will.

It is in the user tasks that Hamel’s Pyramid moves beyond obedience and on the rest of Hamel’s layers, although not necessarily each layer, nor necessarily achieving passion and zeal. Beyond Hamel’s Pyramid, is the user’s realization.

I did not put Hamel’s Pyramid layers into each triangle, but each one might invoke all that emotion, all that humanness if we just let it. Yellow boxes adjacent the relevant triangles indicate where Hamel’s Pyramid layers would be appropriate. This enriches our user interface, our GUI, but it also extends deeply into other layers of use, and improves the user experience across many scales.

With such an expansive view, there is always another feature, another role, another emotional component to code. Beyond that, there are many more opportunities to expand the offer, to foster and position third-party complementor ecologies, to seed open innovation without partnership agreements and such that count on some technology getting to the market as your own application arrives as well, and to define competition much more richly.

The Hype Cycle lays out an expansive view. The triangle model can extend across the Hype Cycle. Hamel’s Pyramid extends across the Hype Cycle as well.

Comments?

Now that you have that Cat

June 2, 2010

In Building a Dog. Oh, Make that a Cat we discussed how to measure development impacts relative to demands that would take us off our roadmap. We needed to say no. We needed to construct the numbers that would say no for us.

Your manager made you build the cat anyway. Now what?

Well you have to sell that cat, but worse, you are only set up to sell to dog people. The cat project actually cut into the dog you have to sell to dog people. Selling the cat means selling to cat people. Sure there are a few dog people that have a cat, there are a few dog people that have a hamster, or a full blown zoo on their hands, so cross-selling the cat to your install base is possible. Cross selling will generate revenues sooner, than your efforts to sell to cat people. The cat certainly was a matter of leveraging your company’s economy of scale. But, cat people never heard of you.

The cat market exists, so the usual marketing approach will work, but it will take time. You have to cross the Chasm. Moore’s chasm is really about waiting around until your marketing gains traction. Press releases and advertising generate a market slowly. The cross selling to your installed base of dog owners will help in the short term.

Selling to an install-base, to existing customer, is supposed to happen at a cost of sale 60-90% less expensive than selling to new customers. This is the reason for retention marketing, but to make it work, you have to sell in a manner that realizes these results. This complicates you sales compensation, sales force structure, and marketing. You actually end up marketing and selling to your install base differently than to your prospects. If you don’t differentiate, you won’t capture your increasing return.

I used the Triangle model to show how marketing and sales realizations are built from the application they are dependent on. We’ll start with the cat. I omitted the campaign to cross sell to dog owners from this first diagram.

Selling Cat New Customers

Selling Cat New Customers

The development effort ended up being divided between effort on the dog application, and effort on the cat application. Starting with the cat application (yellow-orange) at the base of the development triangle, marketing (light brown) is shown as a triangle projecting through the application as it realizes a touchpoint collection that will be exposed to the market. Similarly, a sales (blue) training program is likewise projected through the application as it realizes it’s touchpoint collection elements.

Then, I’ve drawn a plane (dark red/brown) connecting the marketing touchpoints with the sales touchpoints to represent the product’s interface with the market. Then, I’ve drawn the market as a volume projecting from the market interface plane. The customers (yellow) are shown at some distance from the market interface. In between the customers and the market interface, the chasm (clear) appears.

Selling the Dog

Selling the Dog

The dog diagram is significantly more complicated, because the undelivered functionality gives rise to undelivered marketing and sales training components. So the marketing and sales training projections are shown as being divided in two parts: marketing delivered (light brown) and undelivered (gray), and sales training delivered (dark blue) and undelivered (light blue). Likewise, the installed-base customers are divided into those that were not impacted by the undelivered functionality (red) and those that were (blue). The prospects are likewise impacted by the undelivered functionality (clear), because some prospects, Unaddressible Customers, are not in the market without that functionality.

While not quantifiable in the sense of bits, a product manager can determine the cost of the cat marketing effort, the degree of cross-selling possible, the dog customers that could not be gained due to the loss of functionality, lost marketing and sales training effort, the effectiveness of sales to retained customers, the loss of retained customers due to the absence of promised functionality, and the effects of growing the dog business a slower than intended. Plenty of number can be had on the operational end of the cat and dog fight.

If you want a cat, put it on the roadmap. Then, enable the organization to succeed at both the cat and the dog by growing a cat organization, so the dog doesn’t pay. Then, once the cat organization is staffed build and release cat version 0.1. Don’t switch animals in the middle of a roadmap. And, once you have more than one product, the technology layer will need its own independence, rather than having its development tied to either the dog or the cat. You are building a pet store after all.

Comments?