Mapping the Unbundling [LC09]

I was recently on the 150th episode of the Awkward Silences podcast alongside Judd Antin and the ever-thoughtful Christiana Lackner. It's framed around the "future of UX research" which has been getting a lot of traction, lately.

Very important, if you want to figure out the future of anything, is starting with a form of the fundamental question: what is happening right now?

This kind of thinking — understand what's happening now, interpret and extrapolate the signals, anticipate or create the future — is a basic archetype of increasingly well-developed future-oriented practices. And it's hot right now. Sam Ladner spoke at UXRconf 24 last week about strategic foresight. Phil Balagtas just finished his book Making Futures Work, and it's up for presale on Amazon. The redoubtable Muir Wood & Co. is exploring new industry-level futures capability.

My current method for anticipating and acting on strategic change — unsurprising if you're following along — is Wardley Mapping. Today I'll try to show you with a map, instead of tell you, the change that's beginning to happen in the field of user research as it co-evolves along with product team practices. (I won't explain the mechanics of the map, so please check the primer for a refresher.)

Mapping the Unbundling

The map below is the core of my argument in the entire 2,215-word long-form essay Unbundling User Research, reduced to one picture.

The evolution of certain technologies and practices (video calls, scheduling tools, customer contact databases, Research Operations), the resource pressures that limit formal user research, and the increasing pace of product development are all tangible factors at play in the unbundling.

Start by looking at the black lines only: these answer what is the dominant mode right now? Then look at what the evolution enables, in red: what future practices and potential value are unfolding?

I simplify quite a bit here by characterizing the technology enabling this shift as the evolution of specialized recruiting into always-on user access. I'll call out a few things I think this map shows well:

1. Predictable resistance to change: An expected signal that indicates the evolution is actually happening: inertia. This is a predictable pattern of resistance occurring due to past success and the value of the prior operating model. You will hear this resistance (“researchers need to own the research! democratization waters down the insights!”) and keep hearing it for another 5–10 years until the new practices stabilize and the user research community recognizes a new focus of value beyond owning the research itself.
2. New efficiency sets the stage for new practices: Regardless of the inertia, technology evolves because of supply and demand competition. As always on user-access can be depended on as a commodity instead of a luxury, it will enable new practices for product teams. We're not all the way there (future is here, just not evenly distributed and all that), but unless our strategic intent is to become the utility provider owning the space of always-on user access, the value lies in anticipating what this inevitable shift enables.
3. Emerging practices solve problems faster: This evolution opens up a new and much less mature practice space. The current avatar of this practice is the Continuous Discovery model. I call it continuous customer conversations on the map because that's about as far as most teams take the continuous discovery habits model. Things get left behind, but it works and works fast. (Now remember inertia: researchers will tell you that product teams who rely on continuous discovery and don't have researchers running research projects struggle and fail and die — some of that is true, and in many cases it would also be true if a researcher was on board.)
4. Emerging practices create new sources of value: Compared to research projects, continuous customer conversations may be seen as fast and loose; but they offer new means of integrating contextual insight into product cycles. With this additional operating input, we have an even larger footprint of potential learning, and more kinds of activities to orchestrate within our cycles of product development. How do we keep it all together, and learn the right stuff at the right time? How do we make sure what we learn is valid, and we can act on it? We don't really know yet. But I'm putting chips on the fact that answering this question will be productive and valuable.

For me, it's a fair summary of what's happening: a spare diagnosis that pulls in core elements, a logical chain of implication, and a springboard for framing my practice in the coming years. For you, it probably means a lot less: we didn't build it together. We didn't debate what each term meant, we didn't debate what to include and what to keep off the map, and we didn't discuss what the position of each component means.

So long as you can read the gist of it, though, here's the lovely part: you can adapt it and make it your own.

If you want to argue with my story in Unbundling User Research — all 2,000+ words of it — you have to challenge me, my word, and possibly write a big fat story of your own. We can drop the ego when we expose our thinking visually like this: to challenge the map, you discuss specific positions or placements or omissions or pathways of value that you believe exist differently, by showing those differences on a map.

It's dense and it takes a while to converse in this format. Wardley jokes that it takes seven years to get good at mapping: six and a half years of telling yourself you should learn, a couple months to experiment, and a few more months to wonder why it took so long.

I built the above in Figma — if you're interested, drop me a line and I'll share a copy so you can play with this perspective as smoothly as possible.

This is Loops and Cycles, a weekly mailing list exploring the processes that produce good products (and organizations). Share it with your team, send it to a friend, or send me your thoughts and questions.