I got an unusually rich inbox of replies and messages to my short email essay in last week‘s newsletter.
For those of you who missed
it, I have a slightly compressed version on LinkedIn and a slightly expanded version on the blog.
Basically what I said is this：
Specialists keep the present running. Generalists keep the future visible.
I was making the case for the importance of collaboration amongst specialists and generalists, arguing that the successful and resilient organization is the one that respects the value of collaboration between those who execute within known systems (operationally oriented, disciplined program management, standard alignment around KPIs focused on near term business objectives, etc.) and those who can
navigate uncertainty, sense emerging possibilities, and help the adjacent possible come into view before it becomes obvious or urgent.
Here are just a couple of the general categories of responses I received (I'm summarizing the specific response, and bucketing a bit for space):
“Sounds like you‘re describing design thinking..help me understand the difference, if any?”
Hella good question! Got a few similar to that point, it seems. Let‘s get after this!
Design thinking solves defined problems.
To hail that old chestnut, the 60 Minutes IDEO design thinking moment, where design thinking gets its origin myth by asking: “How
might we improve the shopping cart?”
By contrast, speculative prototyping productively reframes unstable situations — moments when the future is still undecided.
Speculative prototyping might
wonder: “What kind of world produces ‘online shopping’ as a ritual at all — and what replaces it when it no longer makes sense?”
To put it another way, talking about shopping carts in a speculative context is like talking about parallel parking in a world of self-driving cars. The skill called “driving” still exists — but it’s no longer where the
future is being decided. You need to nudge your nose around the corner a bit further and imagine what might the world (or possible worlds) look like where these so-called “shopping carts” are an anachronism, or when the entire idea of shopping as a ritual is transformed, or how commerce itself is reimagined or replaced or supplemented by other forms of value exchange.
These are “wheels on luggage” moments: the ones where a design thinking approach optimizes an existing system (luggage, shopping carts, coffee drinking, or any of the other porcelain-like examples trotted out about the value of design thinking), while speculative prototyping reveals the much more exciting possibility that the entire system is up for reimagination. And my whole point is that you might find your “wheels on luggage” opportunity if only you could stopped
starring so hard at ye olde tyme Samsonite hand-carried luggage, and if you could imagine that “design” might possibly be more than a way of workshopping next seasons luggage colors.
Look, it‘s a good question to ask and it makes sense to wonder so try this — think of it this way:
Design thinking solves defined problems.
Speculative prototyping reframes to reveal undefined problems, nebulous entanglements, sets of conditions, curious rituals, and unexplainable/inexplicable circumstances.
Your specialists will continue to hammer away at shopping cart efficiencies. Good stuff!
Your generalists will be busy imagining worlds, one or several of which might be those in which these
“shopping cart” contrivances are an anachronism. Things grandpa used to have around, like nor more than a single pair of (Florsheim, natch) shoes, one rotary phone in the kitchen, and a Sears catalog ordred from once a year.
Can you imagine your generalists in productive collaboration with your specialists?
Together they will create multitudes of variations and prototypes of the future of travel, trade, commerce, breakfast (for example), not just optimization and restyling; not just a more crunchy variant of Grape Nuts™ Cereal, nor luggage that comes in party colors. They‘ll wonder about putting wheels on that luggage, as disruptive as that might seem to the existing value chain or ecosystem.
Speculative prototyping asks (with fascination, curiosity, wonderment — and maybe a bit of mischievous delight): “Oooh! What if better shopping carts is totally the wrong brief!?”
Design
thinking optimizes.
Speculative prototyping reveals.
Different tools.
Different purpose.
Different outcomes.
Good question. That was fun, for real. Thanks!
Next?
“So, like..if you were to bring this mindset into my org/team, what does it actually look like? Are we talking workshops, research, building prototypes?”
Bunch of people wondered this in one form or another (also in the LinkedIn comments) and I'm more than happy for the chance to explain the shape of this kind of function because it‘s what I would like to build..so I‘ve been pondering it quite a bit.
Because speculative
prototyping isn’t a set of activities you can copy-paste into an organization. It’s not “run a workshop, make a prototype, call it done.” Those things are just the surface.
And it‘s definitely not that you do this once and call it done.
Sure, workshops and prototypes. These are just two of the KPIs you might use to measure the value of this kind of team. This then becomes not just isolated research/exploration — but doubles as a learning and development operation through which peole and teams flow through. It‘s like R&D but from possible futures. But, these are just the visible parts.
This kind of work lives in the between spaces — between disciplines, between strategy and execution, between what an organization knows how to do and what it hasn’t yet learned to notice. That makes it tempting to treat it like a toolkit or a side assignment. In practice, it only works when it’s led by someone who has spent years moving across domains, building real things, and learning how institutions behave under uncertainty. Range + Experience.
I came to understand this distinction more clearly a few years ago when I was asked to consider leading a team of deeply creative people inside a much larger, operationally driven organization — legendary really. They were talented, thoughtful, and imaginative — but they had been shaped by years of delivery-first expectations.
I found myself proposing a reorientation of the team’s purpose and KPIs — a shift in what counted as success and meaningful contribution to the enterprise, which meant a shift in how the work was understood and valued. That reorientation felt too radical for the moment — or maybe I was too radical for the moment? Eventually, it became clear to both sides that leading a
delivery-focused function wasn’t the right fit for me, nor were those the right conditions for the kind of work I do best (despite actually having done industrial product design & delivery, but of a different sort, scale, and context.)
What stayed with me was less the mismatch itself, but how easily organizations confuse these two modes of work — how
they rarely make space for the work that operates before clarity arrives.
So, this may condense what I‘m trying to say:
Range
changes what you notice.
Experience changes what you trust.
The heck am I talking about?
Let me try that more clearly:
“1. Range changes what you notice.”
If you’ve worked across different domains, say, engineering, design, business, art, research, community building, facilitation, book making, industrial design, product design, advanced and consumer hardware design, commercial software development,
anthropology, academia, logistics, sales, brand building — you literally see more. (I certainly feel like I do!)
One is bound to have the sensitivities and instinctive radar array to pick up weak signals, odd patterns, half-formed behaviors, see threads of opportunity or curious patterns and sense/find overlaps/connections/synergies that someone
trained narrowly is likely to filter out as irrelevant before they even think on it.
Range expands your perceptual field. It determines what even registers as interesting or possible.
And then:
“2. Experience changes what you trust.”
So, having lived through real projects,
failures, launches, markets, difficult teams/team-mates/structures/clients/participants/institutions, and constraints — well, this will sure as the sun rises develop your internal compass. You learn which instincts are worth following, which signals are noise, when to push, when to wait, and when not to overreact. Experience shapes judgment. It determines what you’re willing to act on.
So those workshops and prototypes and such all become less about outputs and more about creating shared orientation through circulation of activities/results/outcomes, engagement, read-outs, hands-on activity.
(cf The Tim Ingold quote at the top of the newsletter.)
(Parenthetically, and just to say that to my reckoning, a “Code Red” memo like you hear about nowadays might feel decisive, sure — but doesn‘t it smell a bit like a lagging indicator? A signal that an organization is reacting rather than orienting? That the work of noticing, interpreting, and adjusting didn’t happen early enough to avoid emergency mode?
Speculative prototyping exists to prevent exactly this moment: to keep futures discussable before they become crises.
Emergency memos aren’t failures of execution. They’re failures of
anticipation.
When the team that does this is working well and achieving its objectives, people stop asking what kind of activity it is. They start realizing that the organization is thinking differently — earlier, with more confidence, and with a wider sense of what’s actually possible.
Anyway. Thanks for the notes/emails/replies. Really appreciating the feedback and having the chance to clarify and expand on these ideas.
That was a lot of text. Definitely not a ‘snackable’ newsletter this time! Thanks for sticking with it, and happy to hear your
thoughts!
