Context
In one engagement, a set of intertwined decisions were converging at once.
Leadership had decided — largely for contractual and financial reasons — to migrate from Smartsheet to Airtable. At the same time, expectations around governance were evolving, two different team operating models needed to be supported, and management wanted better visibility into how time and effort were being spent across the organization.
The team, meanwhile, was unfamiliar with Airtable, wary of time tracking, and unsure how these changes would actually affect their day-to-day work.
On paper, these were requirements questions.
In practice, they were trust and clarity problems.
What I noticed (and leaned into early)
Discussion alone wasn’t surfacing the real concerns.
People were reacting to ideas of a system — not the system itself. Questions about data ownership, workflow friction, and oversight stayed abstract, and assumptions on both sides went largely untested.
So instead of refining requirements, I built something to react to.
I mocked up the core data structures, created a few Airtable interfaces, and showed — concretely — how data would be captured, how it would flow, and how different operating models could coexist inside the same tool.
None of it was meant to be final.
It was meant to be seen.
The pattern
Once teams could interact with something tangible, the conversation changed.
Each group could respond from lived experience instead of speculation:
- where the workflow felt heavy
- where visibility crossed into discomfort
- where assumptions about governance didn’t hold up in practice
We were also able to “pre-try” parts of the operating model — gauging reactions early and adjusting before anything hardened into policy or tooling. Several assumptions that would have survived a requirements document didn’t survive contact with a working prototype.
Those issues 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 answer every question, but they surface the right ones sooner — when change is still cheap and trust is still flexible.
The main limitation wasn’t technical.
It was attention.
Getting people to slow down enough to engage with prototypes — especially when they already felt change fatigue — required intention and facilitation. But when they did engage, the payoff was real.
In hindsight, we could have built even more of these early explorations, not fewer.
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 shipping faster. They’re about making consequences visible — so decisions can be made with eyes open instead of crossed fingers.
Seeing before building doesn’t eliminate uncertainty.
It gives uncertainty a shape people can work with.