(2022-10-06) Cutler TBM 45/52 Taming Model Malpractice
John Cutler: TBM 45/52: Taming Model Malpractice. I'm back home after a team offsite, and my head is swimming in models.
It got me thinking about the models we use and how we use them
Obligatory George Box quote: All models are wrong, but some are useful.
We have to consider the "job" of the model. (JTBD)
A model designed to help a marketer allocate their budget optimally will probably do a less-good job helping a designer inform the design of a feature
The rightness and wrongness of a model are in service to the "job" of the model. A highly simplified and "wrong" model might be perfect for making high-level (and recoverable) product investment decisions in a hurry.
But the same model will fall flat at non-recoverable "one-way door" decisions with many dependencies.
There are two opposing antipatterns I've noticed in companies when it comes to model-use:
Using too many models
Using too few models (for too many jobs)
The second we hear things like "we try to use the same words for everything," "that doesn't help me," and "well, that's the official way, but we kind of ignore it."
Too many models ensure the models are doing specific jobs at the expense of broad understanding. Too few models ensure people use the same language at the expense of doing jobs well
Using too few models (for too many jobs) involves an interesting twist. The local models still crop up. Why? To do the local job, you'll need local models AND a mapping to the global models
Take the global customer personas mentioned above. Each team had a shadow set of personas they used locally. It was the only way to get any work done.
Put another way: "let's keep it simple" only creates the appearance of simplicity at the global level. People will constantly adapt to their local job (if they are allowed to and can get away with it).
I would add a third antipattern: not being specific about the model's job, even if the goal is general applicability.
But there are two reliable ways to counteract these antipatterns:
The first is a hierarchy of complementary models
The second is what I would call the platform approach.
Both approaches look for a win/win instead of a tradeoff.
I think the biggest AntiPattern is doing a weak job at applying the model. (cf Org Writing Practices)
Edited: | Tweet this! | Search Twitter for discussion