The Current Reframe
I’ve been a Director of Product and I’ve been a designer. Lately I’ve been thinking about the current reframing of UX practices by Product Management professionals and influencers. Just Google, “Wire framing for Product Managers” and you’ll see. Product Managers wire framing is a sore topic for a lot of designers. It’s actually not about turf. It’s more about coherence and respect, but that’s a topic for another time.
This article, Product Managers Are Not Designers by Afonso Franco provides an overview of this evolution of Product Management practices. This line from the article hurts the most because it’s so true:
I heard of a User Research Freelancer who was struggling to find new gigs. She rebranded herself as a Product Discovery Coach and she’s now fully booked.
My Product Management Chapter
When I became a product manager in 2017, I already had 20+ years of experience as a UX Designer. I had worked on emergent tech, earned patents, ran ethnographic studies, ran behavioral research, RITE studies (Rapid Iterative Testing and Evaluation), built Wizard of Oz prototypes and birthed products from seed to release. Much of this knowledge came from on-the-job experience and working alongside researchers. But I never saw myself as a researcher. I often likened myself to a nurse on a plane who can perform emergency treatment if a doctor isn't available, but I’m not a doctor. I simply have too much respect for research as a discipline.
In the Product Management chapter of my journey, I observed that what my organization defined as Product Discovery mainly consisted of Voice-of-the-Customer interviews, surveys, and solution validation. There was no research team at the company at the time, so Product Managers owned discovery. This was fine with me, since I wore the PdM hat. I didn’t have to beg for time to conduct research. I just had to do everything myself. I brought my rich UX background to the role. My 4 squads developed platform utilities like Search, Browse, Recommendations, and navigation from scratch. We had a strong culture of experimentation and prototyping. This was a highly technical space, so I partnered closely with engineers and data scientists. I quickly learned to ask questions and gleaned insights from quantitative data. A lot of how I created roadmaps in those days was informed by my systems thinking background.
Divergent Thinking
I used to say that I coached my designers to think like Product Managers and my Product Managers to think like Designers. My focus was on encouraging the team to adopt a research mindset. We held working sessions to design qualitative research studies and quantitative experiments, matching the method to the question. The practice I try to drill into designers is prolific divergent explorations. This was the doorway into so many mindsets.
Divergent explorations …
can challenge us on dimensions of use and take provocative positions. For example, “The admin user should be able to to complete this task in 5 minutes.”
prompt us to falsify our leading position by exploring alternative behaviors. This can be used to de-risk and to force trade offs in qualitative experiments. It gives us permission to kill our darlings.
encourage us to clearly articulate a behavioral hypothesis about utility and value (I push designers to incorporate placeholder behavior metrics and KPIs for each concept. This can be the starting point for the cross functional team to interrogate. It makes designers much more disciplined in being outcome focused.)
help us to break down proofs vs trying to boil the ocean
enable us to treat conceptual explorations as the starting point for research, uncovering questions we hadn't considered before to lead us to the product bet
can challenge, reshape, or refine opportunity framing
This little sliver of design practice alone can be highly strategic. It’s a way to show the critical thinking, systems thinking, and outcome thinking behind the design work. When there’s a lot of clarity, Design focuses on exploring solutions. When faced with massive ambiguity, Design is about defining quality How-Might-We questions and shaping proofs. Design always aims to provide a product perspective that bridges Utility, Usability and Feasibility. We can show instead of tell. We can expose the nuance in a behavioral hypothesis. In this way, we’re already at the proverbial table.
Integrating Research
Returning to the quote about the researcher who reframes her work as Product Discovery, it underscores the need for research to be integrated into the daily product design process, because all the nuanced questions, risks and decisions are there.
I work on science initiatives in my current job, mainly emergent tech experiences. I’m the resident behavioral researcher and designer on the team. I partner with a PM, engineers and scientists to arrive at a proof of concept. The prototypes we build are created specifically for the purpose of research studies. These prototypes cannot be built in Figma. In this scenario, the novel experience/invention itself is the differentiator. There are no existing patterns. There is no way anyone can “requirement” this into existence. It took all of us making, testing, and asking questions. But it’s the research study that provides the focus each step of the way. It’s also the research insights that gives the UX principles that governs the experience. By the time we have a proof of concept, every person on the team across the entire program would’ve already internalized the those principles. The vibe here always feels like a bunch of people tinkering with an engine in the garage.
Design Maturity Ladder
I often think this ladder below points to design maturity in an organization, where 1 = highest maturity and 3 = lowest. I paint the broad strokes here, but these can be porous and iterative.
Opportunity Framing: This stage identifies the market demands, setting the stage for value creation. The business value hypothesis is defined at this stage.
Solution Definition / Proof of Concept: The goal of this stage is to gain insight into the nuanced behaviors and motivations that create value, and those that do not. This phase results in a Proof of Concept, the behavioral hypothesis and a clear understanding of "The Bet.” When the insights from this stage provides a nuanced differentiator or shifts the Opportunity Framing, we sometimes call that, “Design Led.” This may sound tactical, but it’s the integration of research and design that makes it powerful.
Product Quality: This stage is about execution. It focuses on ensuring the product consistently meets user expectations in performance, usability, and aesthetics, while delivering value and adhering to standards.
I think Designers often don’t fully grasp the super power they already possess. They can contribute and lead across this ladder. They can have deep, durable influence. Words on a whiteboard are TLDRs. You don’t know what you mean until you’ve sketched it, prototype it, interact with it. You don’t need to wait til someone gives you the requirements, you can show outcome driven thinking in your explorations.
Strategy starts with insights. If UX is serious about building the right thing, we must be well versed in research and synthesis to guide our own conviction.
Super interesting. This is equally true that we see so many products that are a poor experience although they have huge research teams. The question is not the research itself—the question is about the *right application of research*—as you often mention—the findings, insights, synthesis, and making sense and meaning of research so that the product teams can apply those findings.
So, design is the application of research.
PS: I remember this LinkedIn discussion a few moons ago: https://www.linkedin.com/posts/jmspool_ux-uxstrategy-uxresearch-activity-7176321604681904128-O4dJ/
The way I read the Product Quality stage, it sounded terminal. I spend the bulk of my time in that activity, but I advocate for it to feed back into identifying new/more promising solutions or better/novel opportunities or framing. In other words, treat it like the A in OODA loops or the Build in Build-Measure-Learn (which Pawel Samsonov pointed out the flaws absent design, but is a familiar reference to many).