A recent discussion came up around a particular type of product model and I wanted to cover that a bit here since I’ve find a certain type of thinker — the literalist — will tend to have problems using imagination and abstraction with these product models. I’ve also found this translates to other models, such as those about testing.

First, it might help to show the model in question that I’m talking about. It’s a simple one:

I actually use this model myself in my post about reframing agile, where I feel the model is a bit better framed as:

Notice there’s already a subtle shift in the model.

The Literalist Objection

The literalists have a problem with this model. Why? Because they look it at as a literal representation and say it makes no sense. The sentiment is basically reduced to: “If your customer needed a car, then what good would a skateboard ever have done them? So this is a case of not understanding the customer’s needs well enough.”

Literalists thus entirely miss the point.

I say that because they are looking at the concept in what I might describe as a teleological way: as if there was some final state we are driving towards. Further, they are using a view of the future (the car) as if they would have that view in reality. But, in fact, the reality is that we don’t know the future. The model is showing one possible path to represent an idea and make a point but the key idea is really about the path itself, not the elements that are shown on the path.

Given all this, I’ve found this be an interesting model that shows me how much someone can and does use their imagination and how much they can abstract details to get to a wider point. Literalists, I find, tend to lack a lot of the imagination needed and lack the abstraction skills required. Referencing something I wrote awhile back, they lack the intuition for abstraction. When translated into testing, these are the types of testers that are often most challenged by exploratory testing.

So how would I tell a literalist they should think of a model like this?

The First Literalist Objection

Well, take that first part of the literalist statement: “If your customer needed a car, then what good would a skateboard ever have done them?”

Notice immediately how they don’t focus on the idea of the path, but rather the specific things shown on the path? The idea expressed in the model is better framed as something quite simple:

• In the first row, you end up with nothing you can use except at the very end.
• In the second row, you end up with something potentially usable at all steps.

The challenge for thinking here is that you can’t look at a skateboard and a car as the same thing. You have to look at them more broadly as a mechanism for locomotion. Further, you can’t assume the end goal (car) — in some sense a teleological approach — is what the user ultimately wants. It may be what they end up with, but it wasn’t necessarily the end goal.

The key point, however, is that the customer evolved with the business. What they consistently wanted was a method of locomotion. What that specific method was evolved as customer needs evolved and as the business itself evolved to provide it to them.

Thus the model is, like all models, an approximation; and, like all such approximations, it can requires context so that it doesn’t seem too distant from reality. For the literalists the model seems too distant from reality because they are lacking the ability to generalize a context.

So, I would say to such folks: this is where you have to make sure you don’t look at the model so literally as a “skateboard” and a “car” and rather just think of it is a minimum viable solution. The whole idea of minimum viable solutions is something I already talked about in Product Management and the Quality Focus. Essentially the idea here is that we create a minimum version of a product that satisfies the purpose of itself, making it worth existing in the first place. A minimum viable experience approach helps us to use a principle of least power. This principle says we should choose the least amount of power suitable for a given purpose.

Even if we did want to take the model a bit more literally, what if the model represented for customers at different stages of their life (i.e., ages)? Then the model would be showing how user needs evolve based on changing conditions. In that case, a putative product line for this company might be one of age-appropriate methods of locomotion. So the model can be translated to something literal for a given company and product line but it doesn’t have to be.

I would also say to the literalists that iif you look at the evolution of much software, it’s nowhere near what it started life as. Look at Facebook as a fairly good example. Some core aspects are still there from its early days, of course, but — as a platform — it’s vastly different in many more ways. Almost as different as skateboard and car — and yet still recognizable in terms of its lineage. Another great example would be, say, the Unreal Engine. The difference between its 1.0 and its current 5.0 incarnation is very much akin to a “skateboard” eventually becoming a “car.”

The Second Literalist Objection

Let’s take the second part of the literalist statement: “So this is a case of not understanding the customer’s needs well enough.”

This is not a case of having not understood what was valuable to some customers. After all: there is no real customer or product here! Remember: it’s a model. Even in that context, it’s still not a case of not having understood what was valuable. Rather it’s that what was valuable changed or evolved. That’s why I said our thinking here can’t be teleological in nature: there may not be a “final product” in mind at the beginning; there’s just what product matters right now.

The Power of Abstracted Thinking

Abstraction is part of the whole point with models like these; in fact, this is key to any such illustration so that we can generalize. These kinds of abstractions present a concrete visualization but also count on the viewer to understand that you do have to abstract a bit.

The software in its 1.0 incarnation (what was valuable then; a “skateboard”) evolves massively up to, say, its 5.0 incarnation (what became valuable later; a “car”). But don’t take the “skateboard” and the “car” literally. They are just abstractions to make a wider point.

Don’t be a literalist and miss the wider point!