Designing for Organizational Memory

Enterprise product teams are trained to hunt for feature gaps. A customer struggles with configuration, so we add better setup tools. A ticket takes too long to close, so we add diagnostics. An implementation needs an expert in the room, so we write more documentation. None of that is wrong, exactly. It is just usually incomplete.

While I was leading research across a routing diagnostics effort and the early Implementation Copilot work, the same pattern kept surfacing in places that should have had nothing to do with each other. Implementations succeeded. Teams hit the business goals they set out to hit. And then, over a year or two, the systems got harder to understand, small changes started carrying disproportionate risk, debugging needed increasingly specialized people, confidence eroded, and support dependency went up.

Individually those looked like separate problems on separate roadmaps. Together they looked like one dynamic: customers were not struggling to configure their systems, they were struggling to hold onto their understanding of them over time.

Protecting the problem space

The hardest part of this project was not method. It was resisting the pull toward solutioning. Everyone wanted to talk about what the Copilot should do, and the question I needed answered first was whether the failure mode was real at all. That meant triangulating across solution consultants, engagement managers, implementation consultants, technical support, product, and customer-facing teams, all of whom described different symptoms and, once you lined them up, kept pointing at the same root cause. Implementation described inconsistency. Support described reconstructing intent. Solution consultants described assumptions that had drifted. Product described variability. Separately, disconnected. Together, a coherent model.

The hidden bill for flexibility

Enterprise software celebrates configurability, and for good reason, since it is what lets a platform fit organizations that work nothing alike. What we talk about less is that every configuration decision encodes an assumption, and those assumptions almost never get written down. Research kept turning up implementations that reflected an individual consultant's preferences, a decision that made sense in 2021, a temporary business requirement that outlived its reason, a tradeoff nobody documented. The configuration survived. The reasoning behind it did not. Two years later somebody is reverse-engineering a choice that was once perfectly obvious.

The other consistent finding was that people distinguished sharply between knowing how to do something and knowing whether they should. Documentation covers the first. Enterprise decisions need the second. Teams could tell you exactly how to configure a thing and still had no confidence about sequence, timing, dependencies, or what it would mean a year out. That moved the conversation away from knowledge transfer and toward decision quality, which changed what enablement even meant.

Why this ended up being an AI question

AI conversations tend to open with automation. What our research kept saying was that people wanted something more basic first. Not generation, not autonomy, not doing the work for them. They wanted to understand what happened, why it happened, what changed, and what might happen next. Automation only became appealing once that comprehension and the trust that comes with it were in place. Explainability, in other words, is not an AI feature you add later. It is the precondition for anyone adopting the thing at all.

Many problems that look technical are really informational. Many that look local are failures of continuity across people, teams, and time.

The output of that work was not a usability recommendation. It was a reframing that connected product capability, customer enablement, implementation outcomes, support burden, AI strategy, and retention risk into one story instead of six. The highest-leverage research I have done rarely answers an interface question. It helps an organization see a connection it could not see before.