## Building a Dog. Oh, Make that a Cat

So you thought you were in the dog business? Surprise, the boss came in this morning and tells you that we are now in the cat business. Hell, the dog’s only half finished. Dog 1.2 is in the works right now.

Adding cat to the code is just a third of the problem. We can add some classes, refactor towards an architecture for pets in general, we can revise our marcom to do the cat stuff in parallel to the dog stuff, but we have vast issues having lost our focus to become a pet store knowing that tomorrow, you’ll be asked to do Gerbals, another segment. All the projections for dogs, and the roadmap for dogs is hosed.

Sure pivot, but dogs have been profitable and proven. The answer is no! Seems like the answer is always no.

But, if you are going to say no, you need the facts to say no for you. You need to measure the costs involved in this deviation from the roadmap, or call it strategy. Even if management wants strategy, the Agile community disavows strategy. Call it whatever you like.

If there is a goal, even if that goal is just to make a living, or to party hard along the way, a goal is a line.

A Goal is a Line.

As a line, that goal would just be a dream, or intent. To make that goal into a motivator for action, that line would be a vector.

Goal as a Vector

If that dog you are building were a vector, then that cat your boss wants to build would be another vector.

Dogs and Cats as Vectors

So how do we 1) point these vectors, and 2) measure the ever growing distance between cats and dogs.

Information Theory

In information theory, that Claude Shannon stuff, the world is comprised of bits. A bit is also the outcome of a single difference. We ask a question to distinguish between things, and the end result is a bit of information. The question we are asking is the “Do, or Do not” question.

Taking this back to geometry, a bit is a unit measure.

Bit as a unit of measure resulting from a decision

So right away we can see that our dog and that cat are at least one bit away from each other. We might add Hamsters next week, and other pets in the coming months since we moved from the dog business to the pet business, but maybe we haven’t realized that yet. So what’s happening to our bits?

More Alternatives, More Bits

We asked a question with more than a pair of alternative answers, so we need more bits to encode the answer, or to locate the alternative.

Once we ask a question, we invariably ask another question. When we where in the dog business, we asked what kind of dogs. We are busy right now expanding the kinds of dogs we can serve and derive revenue from. Asking what kind of dog moves us to another level of detail. It moves us from general to specific. It moves us from one level in a hierarchy to another.

A hierarchy results when asking a subsequent question.

Notice that we now have to encode or measure the depth of our hierarchy, so our unit measure is now two dimensional, but it need not be a square. It could be time and money, but I’m getting ahead of myself. Also notice that we are no longer in the dog business, but rather in the dogs business. The dog company would turn into the dogs division, and the poodle company would report to the dogs.

That we added a dimension to our unit measure. We also added a dimension to our hierarchy. If I was to ask what kind of cat? I would be laying out another independent choice set for measurement. The measurement of the kinds of dogs and the kinds of cats, would be different measures.

Another Dimension

Notice that the dogs and cats alternative sets are separated by the unit measure of the parent dimension, rather than unit measure. Notice also that we stretched the unit measure of the parent decision.

Once you have a two-dimensional unit measure, you can move on to a Cartesian coordinate system, which puts you back in analytic geometry, algebra, and trigonometry. No, I’m not taking the dogs and cats there. But, we do end up with a way to 1) point the vectors, and 2) measure the distance between the vectors at a point in time.

The trick was measuring something abstract like an idea. Any idea is measurable to the degree that it has been delineated by questions about it. Any definition answers a set of questions. Continuous or sustaining innovations add choices to an existing alternative set. Discontinuous innovations provide a new set of parents to existing and new concepts.

Notice, I’m talking about concepts. That means we are working in the philosophical discipline of ontology. The questions are sortables. We do this, because we work with ideas and the realization of those ideas. A product can be considered a realization. Once realized, a product can be classified by a taxonomy. Ontologies are conceptual, taxonomies are physical or at least realized manifestations.

The Triangle Model
Requirements are decisions. In my earlier post, Understanding I talked about how deciding was knowing. During requirements elicitation we are making decisions about the “What,” that will be implemented or realized. They might not look like decisions, because they are encoded into sentences. A dog barks, yes or no? Yes, we will include barking in the abstraction of a dog that we implement, or maybe we will delay the barking until a later release.

It turns out that throughout the software development process we are making decisions, technical decisions that driven by business decisions. And, it’s not just software, it is any product, even if that product is a sharpened pencil, the same goes decisions were made. And, where decisions were made bits arise. We organize bits, and as we do so, many of those bits are aliases for physical or virtual entities, so we break into the physical or virtual worlds with technologies, products, services, experiences, and even organizations.

These decisions are the same ones we were talking about back when we tried to point and measure our vectors.

The world is full of realizations and the decision trees that brought the world into existence. Many of those decisions are implicit. Many of them will not be explicated, or even hypothesized for years to come. Many of those decisions become skills that we practice until they don’t seem like decisions to us. And, while Jackson Pollack denied intention, he omitted that media presented constraints, and that those constraints were overcome by implicit decisions. The dogs and cats are getting away here.

Back in AI class a collection of decisions encoded as logic propositions organized themselves into decision trees, so even if you don’t walk though the decisions serially or in the correct order, you end up with a decision tree. In mathematics a proof begins at an arbitrary spot in the space laid out by earlier theorems and such, and end at a goal, thus adding to the decision tree that is mathematics. Again, the dogs bark.

A decision tree can be represented by a triangle. A realization effort does ask questions and explore areas beyond the ultimate solution. In retrospect, that solution trims the tree, so ignoring the divergences of the generative exploration of the problem or solution space, we end up with a triangle, hence the Triangle Model. Hints of it show up in So you don’t have a Market? Great!, as does more information on vectors of differentiation, and S-curves.

In my use, the Triangle Model can model the waterfall, or Agile. I’ve extended it through the Hype Cycle and touchpoint considerations well beyond the interface.

Before moving forward, I need to provide a key to the graphic representations used going forward.

Unit of Work (Triangle Model) Icon Key

Subsequent diagrams will be built as a series of these icons. Each rectangle represents the effort towards the release of a single minimal marketable functionality unit. Each rectangle is a release, and here a release is composed of three iterations. I realize that each iteration would be a deliverable, each of which should be represented as a triangle unto itself, so maybe iterations here is overkill, but iterations as well as releases can be used a units of information.

The effort is also represented as a decision space composed of the undelivered divergent or exploratory phase (green) effort, the undelivered convergent phase (black) effort, and the delivered effort, the triangle (orange) effort.

Progress towards the goal is shown, as time (blue.) This progress can be considered a vector towards the goal, or as the roadmap.

In the subsequent diagrams I added a vector (red) to denote effort away from the original goal. And, I showed the volume of decisions in each release related to the effort away from the original goal (yellow).

Decision Volume Triangle Model Key 2

Lets think of a release as a unit of measure. Likewise, an iteration is a unit of measure. And, a roadmap is a series of releases.

Successive releases away from the roadmap

Our roadmap is represented by the black vector. Our actual efforts are shown by the blue and red vectors as we diverted from realizing the dog, and turned instead to realizing the cat.

In our triangles, the yellow area represents the effort that was off the roadmap.

Time and Code Volume Vectors

That effort costs more than time and money spent developing the cat. It it also costs you in terms of lost dog effort. To get back to the roadmap, to get back to the dog, it will take you more time and more money.

The Time and Money that the Dog Lost to the Cat

Meanwhile, your pet business explodes due to a loss of focus, your operational costs go up, and the dog owners feel neglected, or maybe their more than unhappy about your going to the cats.

It’s important to say no. But, it is more important to let the numbers speak for you. That big black vector tells you that you are 2 releases behind where you would have been had you focused on shipping the dog. You’ll also be 5 releases behind by the time you ship that dog. And, you still have to deal with the hamster.

### 3 Responses to “Building a Dog. Oh, Make that a Cat”

1. Tondin Banks Says:

This is extremely deep. Thanks for taking the time and putting forth the effort to put this together. I’ll need to read through it a couple more times to fully digest everything, but I think this’ll help the situation I’m in.

Thanks again!

2. Requirements as Circles « Product Strategist Says:

[...] described built a geometry around bits in previous posts. See “Building a Dog. Oh, Make that a Cat”, “Now that you have that Cat”, and “Taxicab [...]

3. Product Strategist Says:

[...] Building a Dog. Oh, Make that a Cat [...]