To make sense of an organization, we need to know the work that it’s carrying out. This work surface area and its adjacent boundaries are the largest frames for determining where and how research will provide value to different product teams.
There is one aspect of particular importance to us here: the evolutionary stage of a product team's work. Is this team working on something novel and experimental, something extremely well-known and expected, or some kind of functionality in between?
For any product team, at each stage, there are predictable patterns of work and kinds of activities that the team will need to take on in the course of product development.
With evolutionary profiling, we can anticipate teams' needs and the kinds of research that might best serve them before they're aware of it themselves. We can shift our work from reactive provider to proactive partner.
Learn to see from the perspective of evolution
In organizations where user and UX research are deployed, the kind of work we’re interested in is carried out in the scope of teams, task forces, functional groups, and initiatives. It may be packaged as a project or live in a workstream.
That work has a core focus that centers on some kind of activity, practice, data, or knowledge. And the heart of that work area can be represented on a lifecycle of evolution, a decades-long journey of innovation from cobbled-together ideas to well-understood and required components of the larger ecosystem.
Take the mobile phone, for example:
In 1983 was an emerging technology slowly moving towards productization. ~40 years later the mobile phone itself is a commodity: if someone does not have a mobile phone it's shocking, or a willful (mindful?) rejection of the norm. What’s most valuable now isn’t the phone itself: it’s what we can build with it and atop it.
Everything evolves along this course, and recognizing these stages as they live in the scope of our product teams is the first key to proactively deploying research. There are four stages, which we pull from Wardley mapping.
- Genesis: new and uncharted tech and activities. In the larger market today, think about brain-computer interfaces (e.g., Neuralink) and quantum computing.
- Custom: known value for the tech and activities, without a dominant model or clear understanding of ROI. In the larger market today, think about AI-powered workplace tools, blockchain identity solutions, or deeply personalized medicine.
- Product: tech and activities have a known value, clear acceptance, and move into feature competition. In the larger market today, think project management tools, collaboration platforms, smart home devices, and electric vehicles.
- Commodity: the technology and activities here are well-understood components at scale. They create new sources of value and become more "invisible" as other new components are built on top of them. In the larger market today, think about E-commerce, compute infrastructure, platform-as-a-service, and electricity generation and distribution.
Evolution as a spectrum
The surprising reality for us is that almost everything we see can be identified along this spectrum of evolution. I mean elevators, EVs, adaptive architecture, meat substitutes, vaccines, AI, the NFL, airplane travel, sewage systems, carbon capture technology, fusion energy, fast food, and Spotify.
Here's a trivial example of an organizational-level evaluation. Given the simple descriptions above and some of the information baked into our spectrum, it's not hard to roughly place our guess along the spectrum.
What's elegant is that this information is a tangible hypothesis. We can share it, discuss, and assuming a common understanding of the evolutionary characteristics at each stage, we can debate alternate ideas by simply showing them elsewhere along the spectrum.
Once we understand the stage of a given technology, we can pattern-match and predict things about it, based on our prior experience. This is where it gets interesting for us.
In our scope, as researchers looking across a product organization, we start to find recurring patterns about what a team will need to learn and which models can best serve them, based on where their work falls on the spectrum of evolution.
Four evolutionary stages
How we determine something's place on the spectrum is simple, but it takes practice and attention.
There's a Wardley mapping cheatsheet for this purpose that collapses most of the background of evolution into characteristics and properties of each stage. And don't be daunted: we'll work from a slimmer set of definitions for each stage, below.
Given these stages — most of which are represented by teams within a product organization of moderate size — we can start with rough rules of thumb to think about how research can partner with those teams, anticipating the kinds of needs they have.
This guidance is built from my own experience working with product teams and research leaders: take it as our starting shorthand, and learn more about how to treat each stage below.
The four stages and their implications for research
Imagine that we're working in the above Collaboration Workflow Software Co. that is itself anchored in the product stage. We placed it there because the user needs, the market perception, and the core understanding of what it delivers are in line with product stage characteristics.
However, if we break the organization down into its teams and work areas, we find that they do not all correspond to the product stage. In this hypothetical set of 6 teams at CWS Co., we see a wider distribution across the stages:
Teams in each phase share characteristics and needs. We can suddenly footprint a kind of demand profile for research based on the teams that are there.
We're keeping this example small, but the power of this approach increases exponentially as the number of teams per org or product portfolio group grows and the ratio of researchers:teams decreases.
I. Research implications for Genesis stage work
Genesis means teams are working with new concepts and novel practices built atop other, high-order capabilities in an undefined market.
Teams doing work on genesis activities are difficult to staff. Traditional models break down — we can’t predict where the team will go or what kind of things they need to learn.
Here our CEO has decided that this collaboration suite should allow for 3D workflow visualization and review in the metaverse, and has created a small Metaverse Workflow Review team to investigate the possibilities.
→ "Avoid and advise." Due to the inherent uncertainty of work in this stage, it's often not wise to attempt to staff a Genesis team with any committed resources. Monitor and advise: research can help course correct and interpret prior knowledge, and it's helpful to track progress so we can anticipate when more pointed needs come up. It's not clear that a fully embedded researcher can or will find ways to deliver value: this is a difficult situation for the researcher and difficult for the team.
II. Research implications for Custom stage work
Custom means teams are working with hypotheses or emerging practices.
Teams doing work on Custom technologies need rapid experimentation and learning capabilities. Their understanding and direction shift quickly. The team learns about their work by how customers use it, and that high-speed learning is punctuated by deeper questions on user needs, activities, and context as edges arise.
Much of the learning is held as internal shared understanding; formalizing user journeys, models, and frameworks beyond mid-fidelity is dangerous, as they're always subject to change.
Our AI workflow copilot team sees and expects the value of AI — but doesn't yet understand where it will fit into supporting existing workflows. Depending on how we profile it, some aspects of our Visual Collaboration team's work may also be considered exploratory and Custom.
→ "Embed and explore." These are the teams best served by lean methods and an active research embed who can share the thread of internal understanding that evolves within the team collective. Because the team still may shift rapidly, it's hard to predict what they will need to learn; however, we know they will need a connection to user context, field immersion if possible, and they'll face off-hand questions, a few of which will rapidly snowball into context-spike investigations.
Ideally, we staff the teams that are mission-critical with an embedded researcher and recognize they may have some slack at one point, and may have too much on their plate at another, as the team moves through its product process. Broaden their scope or give guidance and tools to cope accordingly.
III. Research for Product stage work
Product stage teams are operationalizing their scope of work with cycles of analysis, building, and customer feedback.
The teams have a clear sense of their core customer, potential segments, and the value model of what they're working with. They need customer exposure to understand performance in context, and competitive insight at regular points in time to anticipate how the market is shifting.
Feature-level work creates inevitable scale-debt, which hints at a renewed need for core-flow usability testing. With large-feature work, new concepts, or high-volume customer support requests, questions will arise that require focused studies and integrated syntheses of prior models and understanding.
Our Visual Collaboration team is exploring new directions in a known model (canvas-based collaboration), so they sit somewhere between Custom-buit and Product stages. The Workflow Management team's tools are the product's bread-and-butter: admins work to set up corporate workflows between various groups of internal and external users.
→ "Partner and operationalize." These teams are best served by partnership and coaching. When a team is good at recognizing its risks and assumptions, it's healthy for them to own the customer contact cadence. The work here is on the whole more quantitative, more operational, and more evaluative than that of teams in Custom.
Even so, large-feature areas are likely to benefit from focused studies on existing user behavior and product-adjacent workflow context. There is also the question of maintenance: these teams focus on the new until underlying constraints or customer support pressure shift them into maintenance mode. The process of creating features on a timeline creates inevitable experience rot — consider how to ensure that critical flows across all teams in this stage can have some kind of cadenced evaluation of their usability performance.
Ideally, we staff the team with a researcher who works as a partner and coach to teams of this stage in a similar product line or portfolio grouping.
IV. Research for Commodity stage work
Commodity stage work is well-measured, metric-driven, and methodical. It's often below the surface, from an end-user perspective.
Teams doing work on commodity technologies are managing stable and well-understood components at scale, which other teams build on top of. Meaningful changes here are slow, measured, deployed systematically and on-schedule: migrations over releases.
In our case, Document Storage is a commodity but also user-visible. It's unlikely they'll need an embedded or partnered researcher, but ought to have a point of contact and a means of connecting to insights generated by the earlier-stage teams building on top of their work.
On the other hand, Platform and Infrastructure serve purely internal users. In this case, they are a commodity team working slowly and stably. (In some cases, these teams will work closer to the Product stage and have programs and methods for internal user (developer) exposure, research, and feedback.)
→ "Like and subscribe." Commodity teams are lower in the stack of user visibility, and most of the contextual insight they require is for supporting internal teams. Expect opportunities to support them with internal research coaching. Every now and then a commodity team (like Document Storage) will propose a change that crashes upwards into the user experience, proliferating through the earlier stage teams that build on top of their work. It's helpful to anticipate these conversations and be able to offer an end-user workflow perspective as it fits with internal technical requirements.
Support these teams informally, stay attentive, and check in quarterly at the least: goodwill with commodity glue teams is an important organizational currency.
Evolutionary profiling: a path forward
This is a crucial skill to cultivate when leading research in the organization. If we, research experts, aren't aware of what kind of learning activities will best suit a given team, how can we expect them to do so?
After learning the characteristics of the stages, we get much faster at profiling where given teams sit along the evolutionary lifecycle. With a small group discussing and making initial judgments, we can evaluate the work and how it’s understood in the market, and position each team along the evolutionary lifecycle.
As we develop an understanding here, of the recognizable characteristics of key stages and the implications for deploying research, our view of the organization shifts from reactive to strategic and predictive.
The upshot of evolutionary profiling, in the basic form laid out here, is this: we add value in anticipating our partners' needs before they do so themselves, and we have the contextual grounding we need to explore the fit between our team's current capabilities and the organization's current research needs, instead of starting from a blank slate.
Do you have examples or counterexamples of product teams and their research needs at different stages? Let me know and let's chat.
This essay is part of my larger exploration into the evolution of research and its integration with product practices in the organization.
For behind-the-scenes updates, contextual commentary, and personal prognostication, try my newsletter.
All of Simon Wardley mapping is developed as open-source material under the CC-BY-SA license: the ideas here are offered likewise.
