From Customer Jobs to Code

How UX Research Can Become the Organizing Discipline for AI-Assisted Product Development

Years before AI could write working software from a prompt, I was wrestling with a different problem: how could a company full of talented people, building useful features, still produce an experience that didn't make sense to its customers?

I spent eight years at DocuSign, where I led a UX research team working with colleagues across product, design, and engineering on the evolution of a successful product, eSignature, into a broader software platform—what eventually became known as Intelligent Agreement Management.

One of the problems we encountered was familiar to anyone who has worked in a large product organization. Individual teams could be doing excellent work. Features were designed, tested, and shipped. Roadmaps advanced. By many conventional measures, things were going well.

But customers don't experience a product one team at a time. They're trying to accomplish something, often across multiple people, departments, and software systems. When we looked at their work from beginning to end, the experience could appear considerably less coherent than the individual features suggested.

We were, in effect, shipping our org chart.

This wasn't a failure of talent or effort. It was a problem of perspective. Each team could see the part of the customer experience it was responsible for, but the larger process was difficult to hold in view.

Today, I'm encountering a different version of that problem.

After years of working primarily in UX research, I've returned to building software more directly, using generative AI to move between product ideas, interface design, prototypes, and functioning applications. The experience has been remarkable. Work that once required coordination among several specialists is increasingly within reach of a single person or small team.

But the ease of building doesn't make the underlying product decisions any easier.

An AI coding agent can implement a feature, suggest an architecture, generate tests, and help resolve technical problems. What it cannot reliably establish from a prompt alone is whether the feature represents something worthwhile to the people who will eventually use it.

Whose work are we improving? What are they actually trying to accomplish? Who else participates in that work? What would a meaningfully better outcome look like?

These are familiar research questions. But AI changes what we might be able to do with the answers.

What if UX research didn't simply inform software development, but became part of the context from which software is developed?

Imagine a durable, evidence-backed representation of the work customers are trying to accomplish: the jobs people perform, the steps involved, the difficulties they encounter, the outcomes they value, and the product capabilities intended to help them. All connected in a data model that people could explore through process maps and other views, and that software systems could use as structured context.

Instead of living primarily in reports, presentations, and the memories of people who attended research readouts, this knowledge could become a shared resource for making product decisions. Researchers and product builders could use it to explore opportunities, challenge assumptions made during the build process, make strategic design choices, and evaluate what gets built. What if AI development agents could work with the same context when translating an opportunity into software?

Experience building with teams has taught me that such a model would need to retain references to its supporting evidence, distinguish observations from interpretations, make uncertainty visible, and remain open to revision as teams learn more.

This is the possibility I'm now exploring, and it connects directly to work that began long before generative AI entered my research practice.

At DocuSign, my colleagues and I developed ways to represent customers' end-to-end work so that teams responsible for different parts of a platform could reason together about the same customer processes. Eric Olive and I shared this approach in our June 2026 UXDX online presentation, Tackling the Feature Factory: Scaling UX Research for Platform-Level Impact. The challenge was coordinating understanding across a large organization.

Today, I'm interested in whether those kinds of representations could do something more: connect customer understanding directly to the work of product strategy, design, implementation, and evaluation.

The opportunity isn't simply to give AI better research findings. It's to reconsider how product development itself is organized.

The necessary work doesn't disappear when teams get smaller or AI takes on more of the implementation. Someone still needs to discover what matters, interpret evidence, make tradeoffs, build solutions, and evaluate their consequences. But those responsibilities no longer need to follow the same distribution among job titles and departments.

Interestingly, that same distinction between the work being performed and the people assigned to perform it was central to an earlier research challenge.

Our approach drew on Jobs to Be Done (JTBD), a body of thinking that shifts attention from who customers are to what they're trying to accomplish. Rather than treating job titles as reliable descriptions of people's work, we developed a shared model of job performers—archetypes defined by the functions people carry out within a larger process.

This collaborative work was presented by my colleagues Megan Mathews and Mariné Palamutyan at UXDX New York in May 2023, in their talk Applying the JTBD Framework to Build User Personas that Stick.

A single person might perform several of these jobs in a small organization, while a large enterprise might distribute them among specialized teams. The jobs remain recognizable even when the organizational structure changes.

That distinction helped us investigate customers' work across organizations of very different sizes and structures. And it offers a useful starting point for thinking about how research, product strategy, and software development might come together in an AI-assisted world.