Researchers Should Lead the Product Development Process

For all of its espoused ideals, the larger User Experience movement has yet to achieve a fundamental shift in how our products and services are made. In practice, our work as researchers continues to focus on the commodity production of research output.

We follow a similar pattern as those before us: designers have advanced their operations, and have perfected design systems so that they can design more designs, faster; use them more flexibly. Researchers are advancing our research operations so that we can research more, research, faster; keep it on the shelf for longer.

It’s good work—of course we need to deliver effective insight for product development at the right time, and however is best. Injecting that insight into our existing ways of working is a meaningful change. But often a small step change; rarely a strategic shift.

To see our work reach its potential, to drive strategy and reframe experiential outcomes, we need to reshape the whole product org’s processes to depend on and anticipate the results of our work. We need to start from a wider frame than a functional fight-for-the-user perspective.

This real work, understanding the nature of product development as a process and guiding its flow, is falling through the cracks. Few, if any of us, with all of our specific responsibility, has the time to build a craft-like sensitivity to the broad activity of product development.

To drive real change, to dramatically impact our products for our users, we must start by pointing our well-developed skills of observation to the larger context of our work. To change the teams and larger organizations we are working within, we must first perceive them as they are instead of how we wish they would be, and act accordingly.

Jump to a section:

• Introspection
• A systemic view of product development
• Exposing the process
• Process leadership

Introspection

I ran a project with a smaller startup early in 2021. The clients were at a fork in the road: they engaged me with a brief to better understand two user groups of their industry-specific communications product.

We were to build a picture of how their needs differed and which would be more tractable to focus on, setting strategic direction for the next evolution of the product.

In the first phase of the engagement, I gathered context about their team, their existing product, and what they understood of their users’ context. I began to suspect that they didn’t really need a research project—they understood their distinct groups of users fairly well, including their workflows and drivers, and even some of what it might mean to build a product in each direction.

But they couldn’t yet see a picture of the larger whole: the implications of these directions or a productive view of actual next steps for their larger strategy. In a workshop we reached the conclusion that one of their targets was a non-starter in the long term: we shouldn’t spend our time “doing research” on the difference between two groups when only one was strategically viable.

My role shifted from the production of insights to helping the team shape an active path of building-for and learning-from their target users.

But why, then, did they think their next step was to ‘do research’? The process they were going to use was unproductive, and the decision to embark on a user study wasn’t generated by a well-understood view of their product landscape.

They could see that they were missing research as a function, with no researcher on the team, but didn’t have a great target for what they should actually be looking at. Lacking a helpful frame for introspection, they couldn’t see their own developed but fragmented view of the strategic context. Without a useful picture of strategic context, they had no real basis to determine the next-best move.

It seems trivial in hindsight—just step back and take stock of where we are and what we really know about that—but it represents a pattern I encounter repeatedly in-house and as a consultant. When confronted with confusion or uncertainty, teams don’t know when, or how, to envision their efforts from a larger, contextual frame.

In these scenarios, we resort to tools and methodologies that fabricate goals instead of generating them from context, or we parcel out new functional activity.

A systemic view of product development

We need to step out into a full-frame for product development: a look at the three-part system that drives how ideas or insights become products.

Looking at each component of the full system of product development, their strength and coherence, helps suggest where to build, where to understand more, and where to align. It’s not a functional perspective, driven by how we decompose the work itself, it is an attempt to help us focus on the important factors that dictate: the current state of the product as it exists right now, the real-world user context, and an all-too-frequently neglected look at the team itself.

Most product teams are organized around an older model that stems from the theoretical sweet spot for innovation: the trifecta of Product, Engineering, and Design. Here we’ll call that the “functional” perspective.

Each is crucial to developing and shipping real product. But it’s a frustrating model of work, creating tension as we try to weave new functions into the organization. “Who does research report to?” Or, “how do data scientists and product analysts fit in?” “Do we have to run this by legal?”

These structural problems are inevitable as existing functions solidify and new functions emerge to fill the gaps. More pernicious, though, is that the focus on a limited functional perspective offers no larger product context, and it obscures the real, procedural nature of product development.

When we want to understand, evaluate, and build a product, the context we need to attend to is real-and-concrete. There is (i) a specific organization with an actual product [idea] in a larger ecosystem; (ii) a defined set of people in a real-world context and community that the product is for; and (iii) a very real, human, and specific team who are working on the thing.

We can further see each of these systemic components (Product Ecosystem, Team Reality, User Context) as made up of three layers. These layers and their relationships provide distinctions that illuminate simple, useful questions to identify blind spots and mismatched expectations.

It takes time to tease out the distinctions in the practical setting of your specific organization, and it takes experience with the product development process to understand the implications of those blind spots. But the first and most important part is always working to see the larger, contextual picture that our work sits in, and what that suggests for the product team’s next best moves.

To start building this sensibility, take a look at the existing team or product you’re working with, and try to understand the layers in each of these 3 components, from the broadest layer context (1) down to its most narrow implications (3).

Product ecosystem

All of our work is bounded by the organization’s product strategy at large, what is already built, which information systems are in place, and the existing use or misuse of the product in the world. It’s easy to see the surface, and much more difficult to understand why certain patterns of action occur. And that lack of understanding can cause us stress, confusion, strife.

Our work is shaped and constrained from the strategic down toward the tactical and concrete, but action or imbalance here, or in a different component, can reverberate change from the smaller layer (what’s actually in the world and how is it working?) all the way back up to the larger context (how are we organized and what are we trying to do here?).

Use these questions to get a feel for the lurking drivers of product development based on the real and specific place where the product is being built.

PE1: Organization & Strategy

• How is the organization structured, with respect to product development?
• What is its espoused product strategy, and how do those goals relate to real-world competitive landscape?
• What are the major rituals or checkpoints that drive product/strategy decisions?

PE2: Physical, Digital, Social Infrastructure

• What architectural infrastructure and information systems make up the core product area at hand?
• What is the relationship between the product’s platforms, services, systems and this team’s ownership of their scope & dependencies?

PE3: Touchpoints & Existing Performance

• What is the product’s existing surface area? How is it exposed to the world?
• How are users interacting with it?
• What are the key signals, data, or channels in use to paint a picture of the product’s performance?

Team reality

On your own team or your client’s, it’s crucial to pull existing knowledge and context from the team as starting hypotheses, but also to answer for ourselves: what do they know, and what do they think they know? How well framed or integrated is this view of the world? What are the key concepts in their shared consciousness? And then, how are they currently dividing up work and operating on a day-to-day basis?

Misalignment and compartmentalized information will only add sand to the gears. With a clear and shared reality across these layers, teams can introspect and adapt, successfully and healthily.

To change how the team works, we need to change their shared understanding of the work and the story they tell themselves about their current activities.

TR1: Purpose & Capability

• How is the team staffed and how are its members assigned, and in what structures?
• What’s the point of the team existing—and how do its various members see that?
• What is the extent of the team’s codebase ownership for the work they’re taking on? Where do they depend on others?

TR2: Shared Understanding

• Where does the team feel it has autonomy? What are the major felt constraints?
• What artifacts, systems, or language does the team use to characterize the user and business-strategic contexts it’s working in?
• How do the team members describe the purpose of their current work and its larger implications?

TR3: Operations

• What is the team doing right now, and what are they doing next?
• Who all decided to do that, and how?
• What are the daily/weekly rituals and checkpoints that drive the work and process?

User context

In making sense of product development, we must be able to tease out the climate, the largest frame of context, versus its implications, the actual outpouring of behavior into the product. What sets climatic conditions for the user context is the community, family, or workplace that our users are a part of.

This larger context drives group and individual goals and motivations. It’s then these goals and motivations, often implicit and unexamined, that drive the specific behaviors that interact with our team’s work.

It’s crucial to know on which level the team is building its own knowledge and representation of user context. Teams are not set up for success when their team scope or the larger product strategy target discrete and low-level user behaviors, rather than responding to community-level conditions or classes of goals and motivations.

Likewise, concrete design implementation can’t be determined on community level, or from goals and motivations—they must respond to the actual kinds of behavior exhibited in practice.

Work with the team’s understanding of user context to determine what they know, at what level they’re asking questions, and how well that corresponds to what they’re trying to accomplish.

UC1: Community / Workplace Environment

• How well does the team understand the specific family / community / environment of work, its language and its norms?
• What roles and relationships are at play?
• Who is using the product, and in what ways?

UC2: Goals & Motivations

• How does the team characterize its various personas’ goals, or specific segments’ Jobs to be Done?
• Do we know what success looks like, in its potential variety of forms?

UC3: Behavior

• What are people actually doing right now?
• What do we know about how they use the product?
• How do people with similar goals act, without this product?

Exposing the process: Concrete steps in sequence

The goal of stepping back and framing our work in its larger system is ultimately to alter and change the output of that system. And for a sane, systemic change, we must understand what currently exists, and then see where we can adapt, alter, and experiment on an acceptable-to-try scale.

The first high-leverage target for adaptation is our process: our process shapes the quality of our product outcomes.

And it’s easy to take functional activities as meaningful useful steps in that process. When you’ve heard that we’ll be “doing research,” “running a usability test,” “sketching a concept,” or “testing the design,” we’re focusing on the outputs, not the outcomes we need to understand.

These are phrases that signal a functionally-sequenced waterfall, rather than a process focused on the concrete implications of the specific work at hand. They are, however, targetable and identifiable chunks of work that a specific person or team can accomplish.

In our current way of working, each function knows how to do its own part of the process, which is often held together by agile methodology masquerading as procedural guidance.

We have two-week sprints, kanban charts, CI/CD, double-diamonds, concept tests, personas, and well-assigned story points, but lack a good set of procedural building blocks for product development. It doesn’t mean those things will drive the content of our work forward, or suggest how to proceed.

A good step in the product development process is useful and self-contained work in its own right, and even before it’s complete it will suggest a new state of understanding and potential follow-up activities.

With time and collective knowledge, we will be able to anticipate and sequence the building blocks of our product development activities before we even begin that phase of product development.

Simple examples:

• Draw a clear picture of the key user workflow as it happens right now.
• Reconcile a big-account customer request with existing user segmentations.
• Find early adopters with live data for an “alpha” with a backend built on manually-updated spreadsheets.
• Examine the project status and trajectory with a few members of Customer Support well before they will need to support the changes.
• Run a workshop to examine key assumptions about the work and build the team’s collective will.
• Beta test the latest release with close customer contact and special permission to correlate that behavior with existing analytics.

All of these steps require functional expertise. Few of them are suggested in the weekly-sprint functional mindset. As we re-orient our processes, we must start first from a useful and product step based on the larger frame and progress in product development and only then suggest the functional decomposition of work to achieve that step.

Most teams already have some of these product-development patterns in play, but don’t recognize them for what they are: foundational, repeatable building blocks to be used in the process of product development.

With time and attention, we’ll also come to see that the arc of product development itself has fairly clear phases. Clear enough so that we can anticipate in advance, almost choose from a menu, the most appropriate sequence of major steps for the team’s work, based on its strategic context.

Forging the path of process leadership

So who is keeping an eye on this larger whole that is unfolding, as it moves through the functional silos of our agile assembly lines?

It’s not in the role of any Designer, Engineer, or Researcher I know of—we all have our functional outputs to worry about. Product Managers are the closest bet, but few have the luxury to attend to the work at this higher level.

Our Directors, VPs, and C-suite may try, but they’re just as likely to push pet decisions or board’s mandates. And the scrum masters are more interested in tightening the straightjacket of one-or-two week sprints than in pushing the larger arc of product development forward.

Here, there is an opening for anyone to see the larger system to step up into process leadership. Every team needs to know what the most important next step is (which is so rarely ‘doing research.”) And it must come from real-world context: not only external user and market needs, but a collective understanding of the product surface area we’re working with, and the team’s own purpose, capability, and collective consciousness.

Without that context, the team is turning a wheel that’s disconnected from the rudder, mechanically applying “process” without understanding the larger course of the work.

We will need a tractable understanding of the challenges and activities that every other function faces if we intend to re-integrate our work and drive meaningful processes from the larger strategic context.

The researcher’s existing skill set makes us a prime candidate for stepping up to the task. Remember that in initial experiments, the work itself will look familiar. What is new, however, is how a given step of product development is determined, run, managed, and sequenced. Who owns it and works together on it? How do teams encapsulate, share, and improve units of good process?

Leverage follows: reshaping the building blocks of process—generated from a coherent frame and based on sound and visible evidence—is ultimately reshaping the organization. Here is where we find our levers for strategic change, and a less-traveled pathway to leadership for those who work to pursue it.