Every user-facing decision we make is a prediction. Given the information we have at hand, we launch products, fix bugs, repackage pricing, build new workflows, and fix underlying architecture to support new scale.
Whenever we make those decisions, there is some implicit, and hopefully explicit, view of how the world is that drives that decision. Visual models are our best means of exposing that understanding.
Visual Models
Each product or strategy scope we're working on has some associated ecosystem activity or customer work or user behavior. A telling piece of information, for any team, is whether they've gone so far as to articulate that picture visually: to make it tangible, discussable, and updateable.
A picture of the world in a well-modeled format turns wily stories into share-able, understandable, and challenge-able visual artifacts. It may take many forms: maps, models, frameworks, lifecycles, journeys, workflows, or blueprints.
These are totems of shared understanding that our teams can work with, annotate, and zoom into and out of to articulate and orient the crux of their discussions.
As much as I love Wardley Maps for strategy and think Opportunity-Solution Trees are great for driving continuous discovery on in-place product, I'm finding that which specific one, for a given scope, is less important than whether any critical thinking tool exists.
The models are receptacles for critical thinking and conversation. Their absence may signal a lack of clarity, alignment, or healthy ritual of constructive discussion.
Map and Model Dangers
However, we can't necessarily say the opposite: if a model exists, that does not mean the team is aligned and thinking critically.
There's a classic danger, of course, in mistaking the map for the territory. A model or a framework might become so well-defined that the team mistakes it for truth, rather than the tool for grappling with what we imagine the truth to be. (The model represents reality and its assertions must be corroborated with real experience; real experience must be fed back into the model.)
Even so, it's easy to remain on guard here. Korzybski told us almost 100 years ago that "a map is not the territory" and Box followed on, decades later with, "all models are wrong" (but some are useful.)
It gets pernicious when our map or model begins to become canonical. When we start to dress it up, bless it, and it into a holy artifact. Instead of a map/territory confusion, individuals lose agency over the model. Without a sense of permission or even expectation to engage and alter the artifact — and thus the group's expressed understanding of the world — thinking calcified, along with the artifact itself.
For project-specific models, we may get a point where they're preserved and set on the shelf, after being updated to reflect a post-launch reality. But in the course of working with a problem, that model must be alive, alterable, and in many ways disposable, so it evolves and adapts just as the thinking should.
Finding Balance
All of these visual models exist in service of critical thinking and shared alignment.
To be productive, they need some authority, evidence, and rigor built in. A little bit of reverence for the artifact is all right.
But we can't hold them sacred or inviolate. The model should be accessible to anyone who should work from it, "grab-able," and edit-able. Any member of the team should be able to mark it up and modify it in light of new evidence or conclusions, edit it, and compare it to the original in service of new assertions.
For our thinking tools, we need to navigate a balance between sacred and sacrificial. I'm still playing and practicing with each project. I've learned to get wary each time I fiddle with colors, fonts, or presentational aspects — things that don't help us think or work any better. (Does it matter what color your hammer is?)
In approaching that balance, I'm leaning ever more toward the disposable over the canonical.
This is Loops and Cycles, a weekly mailing list exploring the processes that produce good products (and organizations). Share it with your team, send it to a friend, or send me your thoughts and questions.