Context
In one engagement, several intertwined decisions converged at the same time.
Leadership had decided—largely for contractual and financial reasons—to migrate from Smartsheet to Airtable. Alongside that decision, expectations around governance were evolving, two different team operating models needed to be supported, and management wanted clearer visibility into how time and effort were being spent across the organization.
The team experienced this very differently. They were unfamiliar with Airtable, uncomfortable with the idea of time tracking, and unsure how these changes would actually affect their day-to-day work. What looked, on paper, like a set of requirements questions was, in practice, a mix of trust, clarity, and lived-experience concerns.
What I noticed (and leaned into early)
Discussion alone wasn’t surfacing the real issues.
People were reacting to the idea of a system rather than to the system itself. Conversations about data ownership, workflow friction, and oversight stayed abstract. Assumptions—on both the leadership and team sides—were rarely tested, and uncertainty tended to harden into quiet resistance rather than productive debate.
Instead of continuing to refine requirements in the abstract, I chose to build something concrete that people could respond to.
I mocked up the core data structures, created a handful of Airtable interfaces, and demonstrated—visibly—how data would be captured, how it would move, and how different operating models could coexist within the same tool. None of this was intended to be final. The point wasn’t to decide. It was to make the implications visible.
The pattern
Once teams could interact with something tangible, the conversation shifted.
Feedback became grounded in lived experience rather than speculation. People could feel where the workflow became heavy, where visibility crossed into discomfort, and where governance assumptions broke down when applied to real work. Concerns that had been difficult to articulate in conversation became obvious once they were experienced firsthand.
The prototypes also allowed us to “pre-try” parts of the operating model. We could observe reactions early, adjust expectations, and revise approaches before anything hardened into policy or tooling. Several assumptions that would have survived a written requirements process didn’t survive contact with a working model.
Those insights would have been difficult—if not impossible—to uncover through discussion alone.
What became clearer over time
Seeing doesn’t just accelerate alignment; it changes judgment.
Early artifacts don’t resolve every question, but they surface the right ones sooner—while change is still inexpensive and trust is still adaptable. The value wasn’t in polish or completeness, but in giving uncertainty a concrete form that people could engage with honestly.
The main limitation wasn’t technical. It was attention.
Getting people to slow down enough to engage with prototypes—especially in an environment already experiencing change fatigue—required intention and facilitation. But when that engagement happened, the payoff was unmistakable. In hindsight, the lesson wasn’t restraint. It was that we probably should have done even more of these early explorations.
Why it matters
Teams don’t resist change because they dislike tools or process. They resist change they can’t yet see themselves inside of.
Prototypes, interfaces, and early models aren’t about moving faster toward a solution. They’re about making consequences visible, so decisions can be made with eyes open rather than crossed fingers.
Seeing before building doesn’t eliminate uncertainty.
It gives uncertainty a shape people can work with.