Product teams speak a great deal about understanding users, but much of what passes for empathy is still strangely external. A few interviews, some clips from research, a dashboard, a support summary, and perhaps a customer visit if the quarter is going well. The PM learns about the user, but rarely feels anything close to the shape of the user’s day.
There is a meaningful difference between hearing that a workflow is frustrating and living even a diluted version of the conditions that make it frustrating. One gives you information. The other changes your judgment. It changes what you notice, what starts to feel intolerable, and what no longer sounds like a minor edge case once it begins stealing attention from the work that actually matters to the user.
The point is not to imagine the user better
The phrase becoming your user can sound theatrical if handled badly. It can drift into a kind of product tourism, where the PM briefly samples the user’s world and comes back declaring deep insight after a few hours of inconvenience. That is not what I mean.
The goal is not to imagine the user more vividly. The goal is to borrow enough of the user’s constraints that your product judgement changes in useful ways.
That distinction matters because users are not defined only by goals. They are defined by context. What time pressure are they under? What other systems are open? What risks do they carry if something goes wrong? How fragmented is their attention? What language do they think in? Which decisions are reversible and which ones will come back to haunt them in an audit, a manager review, a customer escalation, or a missed operational target?
Good method acting in product is not identity play, it is constraint play
There is an important ethical line here. A PM cannot become the user in any complete human sense. They cannot briefly inhabit a profession, identity, power structure, or lived experience and claim equivalence. That would be shallow and, in many cases, arrogant.
What a PM can do is become answerable to a version of the user’s constraints.
That is the more useful frame. Do not try to imitate the person. Try to inherit enough of the conditions. Work with the same interruptions. Use the same information quality. Accept the same timing pressure. Force yourself into the same system boundaries. Limit yourself to the same training level. Carry the same downstream consequence for delay or error, even if only through a carefully designed simulation.
The most powerful immersion technique is to inherit the user’s compromises
One of the biggest differences between how product teams think and how users behave is that teams think in terms of optimal flows, while users often operate through compromise. They trade accuracy for speed, structure for momentum, local inconsistency for getting the day unstuck, and perfect usage for something that is simply survivable.
A PM begins to understand the product properly when they are forced into the same compromises.
Also Read: Your customers are not buying your product, they are buying a better version of themselves
What do you skip when the system asks too much? What steps do you stop trusting? What notifications do you mentally tune out? Which fields do you fill carelessly because the form has trained you that accuracy is rarely rewarded? Which safeguard do you work around because it arrives at the wrong moment? Which part of the workflow becomes ceremonial rather than meaningful?
This approach improves prioritisation because it changes what feels expensive
One of the quiet failures in product organisations is that teams often price effort correctly and price users badly. They know what engineering work is expensive. They are less precise about what user adaptation is expensive.
Method acting helps correct that.
Once a PM has felt the repeated cognitive drag of a confusing permission model, the hidden embarrassment of a brittle workflow during a customer call, or the compounding irritation of a product that requires too much memory to use safely, they start evaluating product choices differently. What once sounded like a small usability issue starts looking like an ongoing tax on serious work. A feature request that felt secondary becomes strategically important because it removes repeated mental labour rather than adding visible novelty.
Product teams should immerse themselves in pairs, not in isolation
There is also a practical lesson here. A single PM doing an immersion exercise can still turn it into a private epiphany that never quite translates back into the organisation. The better model is paired immersion across functions.
A PM and a designer should take the same support shift together. A PM and an engineer should attempt the same first-time setup under the same constraints. A PM and customer success lead should walk through the same renewal period using only the product and resources a customer would have. Not because cross-functional alignment is fashionable language, but because products fail in layers and different disciplines notice different truths under pressure.
The PM may notice expectation gaps. The designer may notice interpretive failure. The engineer may see state fragility. The customer-facing partner may understand where confidence actually breaks. A shared immersion experience creates a much stronger basis for action than a single insight carried back into a prioritisation meeting.
It also has another advantage. It makes the user’s reality harder for the organisation to sanitise later.
The risk is romanticising pain instead of removing it
There is, however, a failure mode here that product leaders should be honest about. Teams can become fascinated by immersive research and still not change the product in ways that matter. They collect vivid stories, run internal exercises, and leave the user impressed by the company’s curiosity but still burdened by the same avoidable friction.
Also Read: When AI leaves the screen, cybersecurity becomes product responsibility
That is where this whole idea becomes self-indulgent.
Method acting only deserves the name if it leads to stronger action. The purpose is not to feel more empathetic in meetings. The purpose is to remove false assumptions from the product and to design with greater seriousness about what the user’s day actually costs.
If the immersion does not change priorities, defaults, sequencing, onboarding, trust cues, or the burden placed on the user, then the team has performed understanding rather than built from it.
The deepest insight often comes from repeated immersion
There is a tendency in product culture to search for one transformative field visit or one intense customer session that will unlock truth. Reality is usually less cinematic.
The more valuable form of becoming a user is often repeated, almost boring exposure. The PM takes the same support block each week. They use the same constrained setup path every month. They attend the same operational checkpoint at the same stage of the customer cycle. They revisit the workflow during the moments when pressure actually rises.
This matters because many product truths are not dramatic. They are cumulative. A tiny delay repeated forty times. A confusing label that produces just enough hesitation to disrupt pace. A weak default that creates small but constant recovery work. A permission design that nobody describes as broken, yet everyone silently routes around.
Repeated immersion is what reveals these patterns. It turns empathy from a moral gesture into an operating discipline.
—
Editor’s note: e27 aims to foster thought leadership by publishing views from the community. You can also share your perspective by submitting an article, video, podcast, or infographic.
The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of e27.
Join us on WhatsApp, Instagram, Facebook, X, and LinkedIn to stay connected.
The post Product management as method acting: Becoming your user appeared first on e27.