Someone who ran operations at Disney described something I haven’t stopped thinking about. Before his team could touch any guest experience (redesign it, improve it, scale it) they had to walk it. Not analyze data about it. Not build a persona. Walk it. Through the guest’s eyes, carrying their expectations, emotional state, and constraints.
Most organizations, however, don’t do this, although they believe they do. The frameworks built to institutionalize the walk have instead produced something inconsistent with their stated purpose: practitioners who can produce every artifact of the walk without ever having taken it. The journey map exists. The personas are named. The discovery sprint ran on schedule. But the customer’s actual map was never reconstructed, and the product that followed reflects the team’s assumptions more than the customer’s reality. That anomaly (rigorous process, disconnected output) is not a failure of individual practitioners. It is a structural problem that AI has made far more expensive to ignore. The organizations paying that cost are accelerating into it, not away from it.
The pattern that holds across every cycle
Every major transformation of the last twenty years produced the same split.
During the DevOps cycle, Ansible won over Chef and Puppet, not because it was technically superior (it wasn’t), but because it walked the actual sysadmin’s map. No agent to install. Syntax readable without training. It met practitioners where they were rather than asking them to adopt a new mental model. Chef and Puppet asked you to walk their map. Ansible walked yours.
During the cloud cycle, Snowflake walked the analyst’s map rather than the DBA’s. Analysts needed to run large queries when they needed them, not based on provisioned compute someone else controlled. The technical architecture was a service design insight before it was an engineering decision.
The organizations that used each new capability to get closer to the customer’s reality got better outcomes. The ones that used it to move faster inside their own assumptions produced more polished versions of the wrong thing. Methodology was never the problem. Willingness to walk it first was.
The institutional failure nobody wants to name
Design thinking, persona development, journey mapping, innovation offices: all built to institutionalize the walk. All produced practitioners who knew the artifact without carrying the instinct.
A persona is a map of a map. The moment you give the customer a name (Sarah, 34, urban professional, values convenience) you’ve stopped walking their experience and started walking your model of it. Sarah does what the team needs her to do. A real customer doesn’t.
Worse: these frameworks created a specialist class responsible for walking it on behalf of everyone else. The moment you outsource the walk, the rest of the organization stops doing it. The design team becomes the bottleneck. Then the workaround. Then the political fight about whether design has a seat at the table. Then the reorg that was supposed to fix it.
The instinct never transferred because the process was always owned by specialists. The people who had to build were given the artifact of someone else’s walk and told to execute from it. That’s not walking it. That’s inheriting a map and hoping it matches the territory.
No guarantees. No substitutes.
None of this is a promise. Organizations that treat the walk as a guarantee will be disappointed in the same way as organizations that never walked it, just with better documentation of why they were wrong.
What distinguishes the organizations that navigate these cycles well isn’t that they walked it and succeeded. It’s that they walked it, failed in places, and had the institutional maturity to adjust without abandoning the discipline. The ones that lack that maturity do one of two things: they use a disciplined failure as justification for abandoning the discipline entirely. Or they mistake process compliance for instinct, and keep producing artifacts of the walk without the walk itself.
The second failure is running at scale right now. These are organizations with everything in place: massive platform distribution, the ability to push software to tens of millions of users overnight, mature PM orgs, years of discovery frameworks, full roadmaps. Feature velocity up. Adoption flat or declining. Headcount cut. Not because the talent failed, but because the output didn’t justify the investment. That’s not an execution problem. That’s an organization walking its own map with precision while the customer’s map moved.
Microsoft is the most visible instance of this. Copilot has extraordinary distribution, enterprise sales weight, and years of product investment behind it. It’s not the experience people reach for. That’s not a talent failure. That’s a map failure.
But the same pattern runs at every scale: the mid-size SaaS company shipping twelve features a quarter and watching NPS flatline, the startup generating prototypes before the customer conversation has happened. Same structural failure. Different leverage.
Walking it first is what separates outcomes now. So is the organizational maturity to push back when rapid prototyping promises a shortcut. Rapid prototyping isn’t a new idea. Figma existed. InVision existed. AI just made it slicker and more convincing, which makes the discipline harder to hold, not less necessary.
What AI just broke
Scale creates the illusion that data is a substitute for the map. It isn’t. It’s a lagging signal of whether you were right six months ago.
AI is producing the same illusion at software speed.
A developer can spin up a working prototype in 45 minutes. A PM can generate five concept variations before lunch. A working demo exists before the empathy has been earned. Because the prototype is convincing, the social response it triggers is “does this work” rather than “does this match the customer’s actual reality.”
The prototype answers the first question so completely that the second never gets asked. Discovery, customer interviews, map reconstruction: all require sitting with ambiguity. The prototype eliminates the ambiguity. That feels like progress. When the prototype exists, running parallel discovery reads as wasteful. Organizational gravity pulls everyone toward iterating on the prototype rather than questioning its premise.
Faster cycles of the same mistake. Higher production quality. Deeper organizational commitment to being wrong.
There’s a second failure running underneath the first one.
The convincing prototype creates permission to skip what comes between the walk and the build: the PRDs, the exception flows, the error states, the edge cases that don’t appear on the happy path. These aren’t documentation overhead. They’re decision-forcing mechanisms. They make teams commit to the states that don’t exist yet, before they’re load-bearing inside a system.
When the prototype is good enough to pass a demo review and a stakeholder review, skipping that work reads as efficiency. It isn’t. It defers every uncommitted decision into the implementation, invisible until they surface in production. The known consequences are predictable: unhandled exceptions, accessibility failures, security gaps found late. The less visible ones are harder to name because they haven’t happened at scale yet. Imprecision gets embedded before it has a name. The system gets built on top of it.
The prototype shows what the product could be. It doesn’t force the decisions the product actually requires.
What just changed
Here is what nobody who lived through the previous cycles expected to say: the tradeoff is gone.
For twenty years, walking it first carried a timeline penalty. The team that skipped discovery was already in market while you were still synthesizing research. Sometimes they were wrong and it didn’t matter because they were first.
The practitioner who walks the customer’s map first now builds at the same speed as the one who skips it. For the first time in the history of product development, rigor and speed are not in tension.
The innovation office couldn’t transfer the instinct because it added process in a world where process was already losing to speed. That constraint is gone. Same tools. None of the penalty. The only remaining variable is whether you have the instinct.
The honest close
The patterns from this cycle are still forming. New failure modes will get named as they accumulate. New practices will emerge from the teams navigating this well. We will know more.
What won’t change: walking it first is not a methodology that gets superseded by the next cycle. It is the discipline underneath every framework: the thing that determines whether the process produces the instinct or just the artifact. Every cycle in the last twenty years rewarded the organizations that held that discipline under pressure and punished the ones that outsourced it to a specialist class or mistook the artifact for the act. That holds whether the tool is Ansible, Figma, or a model that generates working code in forty-five minutes.
The question in front of every CTO, every PM, every practitioner building something right now: are you building faster, or are you building right faster?
The tools to do both at once have never existed before. The instinct has to come from you.