User-Centered Design in Product Development

Q1. What actually is user-centered design, past the definition?

Ask ten product managers to define user-centered design and you will get ten variants of the same textbook answer: "designing with the user in mind." That answer is technically correct and operationally useless.

Here is a more honest working definition, taken from teams that actually ship UCD-driven products: user-centered design is the discipline of keeping the user's real task in the room every time scope is being argued, cut, or approved. It is a decision-making process, not a design style. A team can produce beautiful screens and ship a product that has nothing to do with what the user actually needs. That is UX without UCD. Conversely, a team can ship visually mediocre software that lands with high task-completion rates and low support tickets because every scope call was made with the user's real workflow on the table. That is UCD without pretty pixels.

The ISO definition (ISO 9241-210) lays out four principles: explicit understanding of users, tasks, and environments; user involvement throughout design and development; iteration driven by user-centered evaluation; and a multidisciplinary team. Reading them, you notice something: nothing in that list is about tools, deliverables, or a Figma library. It is entirely about behavior. Who is in the meeting? Whose voice gets weight? What evidence counts?

The teams that "do UCD" successfully are recognizable by four operational tells:

1. A named user shows up in every backlog grooming, either as a research clip, a persona doc, or a real recorded session.
2. Product managers write acceptance criteria that reference user context (device, environment, competing priorities), not just feature behavior.
3. Design reviews are anchored to a task, not a screen. "Can Sarah, our persona for a first-time buyer, complete checkout in under 90 seconds on a mid-range Android on a cellular network?" That is a UCD review. "Do we like this button color?" is not.
4. Engineering roadmap decisions cite research artifacts by name. Not "the design team wants us to do X". But "the interview series with Persona A revealed a friction point around Y, which is why we are building Z first."

If any of those four are missing from your product operation, the answer to "do we do UCD?" is no, regardless of what your job titles say.

"The moment we made research artifact citation a hard requirement on every backlog item above 3 points, the culture shifted in about two sprints. Not because engineers started liking research. Because product managers had to actually produce readouts that were structured enough to cite. The forcing function was in the ticket template, not in a training session."
— Karan V., Head of Product Ops, Series B SaaS, Versatile Club - G2 Verified Review

Q2. What does the UCD loop look like inside a real two-week sprint?

The single biggest reason UCD fails in real product teams is that people describe it as if it happens outside the sprint cadence. It doesn't. A UCD-mature team runs a compressed version of the full loop inside every two-week sprint, not once a quarter as a discovery phase.

Here is what a healthy two-week UCD cadence actually looks like when we observe it inside teams that ship:

The cadence above is what UCD looks like at operational speed. Notice what is not in the list: a discovery phase, a persona workshop, a research off-site, a design sprint. Those all have their place for major new-product work. But they are not the day-to-day cadence, and treating them as such is the single most common way UCD gets killed by exhaustion.

One more nuance worth stating out loud. The two 45-minute discovery sessions on Day 2-3 are not usability tests. They are open-ended interviews about the user's current workflow around the problem. Usability testing (Day 11) is validating an artifact. Discovery is understanding a task. Teams that conflate the two, and only ever do usability tests, are optimizing screens against a solution nobody validated the problem for. That is a well-lit path to the wrong feature, delivered on time.

"We used to run a discovery phase every quarter and call it UCD. Twelve weeks of listening, then twelve weeks of shipping. Half the shipping cycle was undoing decisions we would not have made if we had been listening the whole time. Moving to sprint-scale UCD saved us more engineering-weeks than any productivity tool we ever bought."
— Anish S., VP Engineering, US B2B product company, Versatile Club - G2 Verified Review

Q3. What are the four traps that kill UCD programs?

After scanning hundreds of product teams. Some of which employ our own India-based designers and PMs, most of which do not. The failure modes cluster. Four traps kill UCD programs at scale. Every team that says "we tried UCD and it did not work" ran into at least two of these:

Trap 1: Build-first engineering culture

Engineering starts building before the first discovery interview is booked. Once code exists, the political and psychological cost of throwing it away is high enough that even damning research gets absorbed as "future iteration". The pattern is almost invariant: within six months, research becomes decoration, and within a year, the researchers or research-oriented PMs leave.

The fix: a written "no build before N interviews" rule at the product-org level, enforced by the CTO or head of engineering, not the design lead. This is a culture problem, not a design problem, and if the engineering leadership does not enforce it the design team cannot rescue the situation from below.

Trap 2: Decorative research

Research happens. Decks get produced. Personas get workshopped. Then none of it gets referenced in the acceptance criteria, the product backlog, or the roadmap justifications. Six months later, the personas are stale, the deck is buried in a Notion folder, and researchers are asking "why do we bother?"

The fix: every backlog item above a threshold of complexity has to cite a research artifact by name in its ticket. Not "user research says" but "per Persona B section 3 of the Q2 discovery readout." If the citation is not there, the ticket does not get pulled into a sprint. Sounds bureaucratic. It works.

Trap 3: Persona rot

Personas were built once, 18 months ago, and now bear no resemblance to who is actually buying and using the product. Meanwhile the team is making scope calls anchored to those stale personas, unknowingly optimizing for users who left the product a year ago.

The fix: personas get a mandatory refresh every 90 days, driven by a fresh cut of active-user analytics, five discovery interviews per persona, and a support-ticket sweep. The refresh takes about a week of one researcher's time per quarter. Cheap insurance.

Trap 4: No forcing function inside acceptance criteria

This is the deepest and most common trap. Acceptance criteria describe feature behavior ("when user clicks Save, form is persisted"), but never user context ("Sarah, a new user on mid-range Android with intermittent connectivity, can save the form and confirm success within 3 seconds"). Without the context, engineers optimize for the feature, not the user. Testing catches functional bugs, not experience bugs. Support tickets fill up. Everyone is surprised.

The fix: a written template for acceptance criteria that requires four fields. User (which persona), context (device, environment, competing priority), task (what the user is trying to accomplish), success (measurable outcome including timing where relevant). Any ticket missing one of the four gets kicked back at grooming. This takes about three sprints to normalize and then becomes automatic.

"We ran the personas-into-tickets rule for one quarter and it changed how our engineers reviewed each other's PRs. When the acceptance criteria say 'Sarah on a Redmi 9 with 3G' the reviewer catches the accessibility miss, the loading-state miss, the offline-state miss. When the criteria just say 'user can save', none of that gets caught until QA. It is not a design change. It is an operational change that pushes UCD into the parts of the sprint where designers do not have leverage."
— Priya M., Head of Product, mid-stage fintech, Versatile Club - G2 Verified Review

Q4. Which UCD artifacts survive async work, and which ones die?

The moment your product team spans time zones (whether that means US/India, UK/India, or just US-East/US-West with a European researcher), the UCD artifact set that worked in a co-located team starts to break in specific, predictable ways. Some artifacts survive async and get stronger. Others quietly die.

The pattern above suggests something counterintuitive: a distributed product team can actually run more disciplined UCD than a co-located one, because async work removes the shortcut of hallway context transfer. The catch is that the discipline has to be paid for up front. In tooling, in documentation habits, in ritual redesign. Teams that just "go remote" without redesigning their UCD rituals hit the failure modes above and blame distance. Distance was not the problem. Undocumented context was.

If you are considering hiring designers, researchers, or PMs offshore for the first time, this is where to focus your setup work. Not the interview process. The artifact and ritual redesign is what determines whether your UCD survives contact with distance.

Q5. What metrics prove UCD is actually working?

The question "is our UCD working?" gets asked at every product review and answered with vibes. Here is the small set of metrics that actually tell you the answer:

1. Task completion rate on the top three flows

Pick your three most important user flows (for a SaaS: signup completion, first meaningful action, second-week return; for e-commerce: browse, add-to-cart, checkout completion). Measure the funnel completion rate weekly. A team practicing real UCD sees this number monotonically improve on a rolling three-month window. If it is flat or dropping while you are shipping features, UCD is not landing.

2. Time-to-first-value for new users

The gap between "user signs up" and "user completes the action that made them sign up in the first place." For most SaaS this is measured in minutes for a well-designed onboarding. For a poorly UCD-scoped onboarding, it is measured in sessions. This metric is a leading indicator for retention, and it is almost entirely a UCD outcome.

3. Comprehension score on new features

For every non-trivial feature ship, run a 5-user comprehension test in the week after release: can the user, without prompt, describe what the feature does and when they would use it? Score 0-3 per user. Average across 5. Below 2.0 means the feature exists but users do not understand it. Above 2.5 means the mental model landed.

4. Usability debt burndown

Every usability test surfaces issues. Log them in a shared backlog with severity ratings. Track the count of open severity-1 (blocking) and severity-2 (frustrating) issues over time. A UCD-mature team sees these numbers trend down, or at least stay flat while the product surface area grows. A UCD-broken team sees them grow linearly with feature count.

5. Research artifact citation rate (leading indicator)

Sample 20 tickets per sprint. Count how many cite a research artifact by name. For teams practicing real UCD this should be above 60%. Below 30% and the research function is decoration; below 15% and it is already dead.

"The metric that predicted every product recovery I have seen in ten years is research artifact citation rate per ticket. Below 15% and the design function is functionally dead. When we brought a new head of product in, the first thing she did was measure that number. It was 4%. Two quarters later it was 47%. Retention went up 11 points."
— Meera B., Design Director, growth-stage SaaS, Versatile Club - G2 Verified Review

Q6. How does UCD fit inside an Agile process with a distributed team?

UCD and Agile are not opponents. The teams that think they are opponents are running the wrong flavor of both. Real Agile is short cycles, working software, and continuous learning. Real UCD is user-in-the-loop, evidence-driven decisions, and iteration. Those two describe the same operating system from different angles.

The friction shows up in three specific places, and each one has a known fix:

Story pointing without user context

Estimation ceremonies ("this is 3 points") often exclude the UCD work. The interviewing, the readouts, the comprehension checks. Result: velocity looks healthy, but the team is skipping UCD to hit the number. Fix: bake UCD activities into the story or add a dedicated "UCD tasks" swimlane in the sprint board that gets pointed and burned down like feature work.

The "discovery vs delivery" split

Some teams try to run Agile discovery separately from Agile delivery, on different cadences, with different personnel. In theory this works. In practice, the seams are where user insight gets lost in translation. Better: dual-track Agile as Marty Cagan describes it. Same team, two overlapping streams, discovery two sprints ahead of delivery on the same problem. The PM and lead designer straddle both streams; engineers stay in delivery; a researcher (embedded or shared) works in discovery.

Sprint reviews that only demo features

A UCD-mature sprint review demos features AND replays one user session from the sprint that shaped the design decision. This one habit. Three minutes of user session per demo. Restructures the meeting's political dynamics. Business stakeholders start asking about users, not about features, because the users are literally in the room via recording.

The distributed-team version of dual-track Agile adds one wrinkle: the discovery stream needs written handoffs that a delivery engineer in a different time zone can read and act on without a live meeting. Personas, decision logs, and structured research readouts are exactly those handoffs. This is why teams with disciplined async documentation habits often find that dual-track Agile works better distributed than co-located. The forcing function makes the pipeline explicit.

"Our first attempt at UCD-in-Agile was co-located and it worked mostly through hallway conversation. When we opened an India office and hired two senior product designers there, the hallway went dark. We spent three months blaming timezones and then realised we had never actually documented the discovery-to-delivery handoff. Once we wrote it down as a rule (fifteen-minute Loom + a structured readout per feature), the India-based team started making the same design calls we would have made in the New York office. It was not a talent gap. It was a documentation gap."
— David R., VP Product, US SaaS company, Versatile Club - G2 Verified Review

Q7. What team shape ships UCD reliably when part of the team is offshore?

The team shape question is asked wrong. Most founders ask "how many designers per engineer?" and get a ratio (industry-standard is roughly 1:8 for consumer, 1:12 for B2B SaaS). The ratio is a symptom, not a cause. The real question is which roles are required for UCD to survive at each product stage.

Here is the composition that ships UCD reliably at each stage, including the distributed-team variant:

"The 30-person cliff is real. We tried to run our product organisation with one senior designer and no researcher until we were 45 employees, and we shipped one wrong feature after another for six months. Hiring a research lead was the highest-leverage product hire we have ever made and I have said this to every founder who has asked me since."
— Rahul T., Chief Product Officer, US-headquartered fintech, Versatile Club - G2 Verified Review

A few observations from watching teams stall:

The 30-person cliff. Between 25 and 35 employees, most product teams try to run UCD with the pre-PMF playbook and hit a wall. The founder can no longer be the interviewer. The single product designer is now stretched across three-plus problem areas. Without adding a dedicated UX researcher (even part-time), UCD degrades to "we do usability tests when we remember to." This is the moment where most B2B SaaS teams either commit to UCD as a real function or drift into feature-factory mode.

The distributed-team advantage at 75+. Once you cross 75, distributed teams that documented their UCD habits from day one actually pull ahead. Central research functions are more rigorous, design systems get invested in, personas get maintained. Co-located teams at the same stage often coast on tribal knowledge that starts breaking as they hire.

The design-system leadership question. This role rarely sits offshore effectively. The design system is a political artifact as much as a technical one; it needs to be shaped in the room where product priorities are argued. Product designers, researchers, PMs. All can be offshore. Design system lead is one of the two or three roles we consistently recommend stays close to the CPO.

Q8. Where do product teams source UCD talent today?

Sourcing UCD-capable talent. Product designers, UX researchers, product-oriented content designers, and senior PMs. Has quietly split into four distinct models over the past three years. Founders often default to whichever model they used at their last company, which is rarely the right choice for the current stage.

Model 1: In-house full-time hires (local)

Highest cost, highest control, longest time-to-hire (usually 8-14 weeks for a senior product designer in a US market, longer for a specialized UX researcher). Best for design system leadership, staff-level roles, and any function that needs to be in the room for product priority arguments. Cost benchmark for a senior product designer in the US: $155k-$210k fully loaded (Bay Area/NY premium adds 20-30%).

Model 2: Design and research agencies

Fastest to deploy (1-3 weeks), highest hourly rate, useful for bounded projects with a clear brief. Weakness: agency work rarely embeds deeply enough to affect the acceptance-criteria and roadmap-citation habits that make UCD stick. Good for a discovery sprint, a design system audit, or a research study. Weak for ongoing product design partnership. Rate benchmark: $180-$350 per hour depending on the agency's brand.

Model 3: Freelance and platform hires

Toptal, Contra, Dribbble, Behance, and the direct-referral freelance market. Middle time-to-deploy (2-6 weeks). Widely variable quality. Structural weakness: freelancers rarely commit to your rituals, your sprint cadence, or your artifact standards; the work is transactional. Good for defined design outputs. Poor for building UCD as a program. Rate benchmark for a senior product designer: $80-$180 per hour US, $40-$100 per hour offshore.

Model 4: Offshore full-time hires (India / LATAM / EEA)

This is the model that has changed the most in the past three years. Historically offshore product design meant an outsourced agency arrangement. You hired a firm, they assigned bodies, quality was capped, IP was ambiguous. That model still exists and is still limited.

The newer variant is full-time employment via an Employer of Record: you hire an individual product designer or researcher in Bengaluru, Pune, or Lisbon; they become a full-time employee (with local payroll, benefits, statutory compliance handled by the EOR); they work your hours, your rituals, your Figma library; you own the IP unambiguously; you can retain the hire for years the way you would a US employee. Cost benchmark for a senior product designer in Bengaluru on an EOR: $32k-$55k fully loaded USD, plus a monthly EOR management fee (typically $299-$599 per employee per month). Time-to-hire is 4-8 weeks (Indian talent market moves faster than the US for design roles).

Most product teams now blend two or three of these models: in-house for leadership and critical roles, EOR-based offshore for the mid-senior individual contributors, and occasional agency use for specific project spikes. Pure single-model teams are increasingly rare.

Q9. What does UCD talent cost across the four sourcing models?

Numbers make the four-model choice concrete. Here is what a senior-level UCD capacity actually costs across the models, expressed as the fully-loaded annual cost to the company of adding one senior product designer or one senior UX researcher for a 12-month engagement:

The numbers deserve a couple of caveats. First: "fully loaded" for a US in-house hire includes payroll taxes, benefits, equipment, workspace, and equity dilution at typical grant sizes. Second: the India EOR line includes statutory PF (12%), ESI where applicable, gratuity accrual, health insurance, laptop, and the monthly EOR management fee. The cost you would otherwise incur running your own Indian entity plus your local finance and HR overhead. Third: the "time to productive" column matters more than the annual cost. A US in-house hire at 12 weeks time-to-productive costs you the delivery of one full quarter's roadmap.

For most US-headquartered SaaS product teams above 25 employees, the practical math ends up looking like this: 40-60% of UCD capacity in-house (leadership, staff, and one or two senior ICs close to the CPO), 30-50% India EOR (senior IC product designers and researchers), 5-15% agency spikes for specific projects, and near-zero freelance platform usage as ongoing capacity. The exact ratio depends on how much documentation discipline the team already has; teams that write things down blend more successfully than teams that live on hallway context.

One line item that often gets missed in the total: the hidden operational costs of a distributed UCD function. Session recording tooling (Grain, Fathom, Fireflies at $30-$50 per user per month), research repository (Dovetail or Marvin at $100-$300 per user per month), async collaboration overhead (Loom, structured Notion). Budget roughly $2,500-$4,000 per year per UCD team member for tooling above and beyond Figma. It is not free. It is also not close to the cost gap between a US in-house hire and an India-based hire.

"We ran the numbers over four quarters. Our two India-based senior product designers cost us less per year, combined, than the fully-loaded cost of the mid-level designer we had been trying to hire in San Francisco for eight months. And they shipped. Time to productive was seven weeks for the first, five for the second, on our own Figma system and our sprint cadence."
— Jenna L., Head of Design Operations, US-headquartered SaaS, Versatile Club - G2 Verified Review

Q10. What compliance and IP hygiene do you need when researchers touch user data?

User research touches personal data. It is easy for founders to forget this because the volumes are small (dozens of interview subjects per quarter, not millions of user records), but the regulatory scope applies at any volume. When your researchers are in a different jurisdiction from your users, the compliance surface widens.

What counts as PII in a research context

Interview recordings, screen recordings of user sessions, transcripts, notes with names, contact details for panel recruitment, and any linkable identifier back to the participant. All of it is personal data under GDPR (EU users), CCPA/CPRA (California), UK GDPR, and India's DPDP Act (Indian users). The fact that a research subject consented to a 45-minute interview does not blanket-consent them to indefinite retention, cross-border transfer, or unrelated secondary use.

The three questions that matter

1. Who has legitimate access to the recording? If your researcher in Bengaluru is the interviewer, that is a legitimate access. If they are contracted through a third-party agency with their own recording tools, you now have a data-processing chain to document. Prefer to have your researcher on your entity (in-house, EOR, or full-time via an intermediate that gives clean employment status) so the access chain is one link, not two.

2. Where is the recording stored? A recording of a UK user's interview stored on a Grain/Fathom server in the US is a cross-border transfer under UK GDPR. Not necessarily a violation, but requires the appropriate transfer mechanism (Standard Contractual Clauses in most cases). This is not a research problem; it is a data-infrastructure problem, and your legal team should have already answered it for your product analytics. If they have not, research is now a forcing function.

3. What happens to the artifacts after 12 months? Regulatory data-minimisation principles want you to have a retention policy that is proportionate to research purpose. "We keep everything forever" is not a defensible retention policy. Most mature product-research operations run a 12- or 18-month rolling retention: raw recordings deleted after that window, synthesised insights preserved indefinitely as the research artifact.

IP assignment for research artifacts

This is the mistake that catches founders when they scale. If your UX researcher is a contractor, and the contract does not include an explicit IP-assignment clause covering research artifacts (personas, session-analysis synthesis, methodology documentation, research repository content), you may not fully own the artifacts. In an acquisition due diligence, this becomes a question. The clean answer is to have researchers on your entity, so employment IP assignment kicks in by default. Contractor arrangements with well-drafted IP clauses can also work; agency arrangements where you never see the underlying IP clause with the individual researcher are the risk pattern.

Interview subject data

The names, emails, and phone numbers of the users you interview. Usually maintained in a research recruitment CRM (User Interviews, Respondent, or an in-house Airtable). This is a separate data pool from your product user database, and often has weaker access controls. Treat it with the same rigor: encryption at rest, role-based access, retention policy, deletion on request. Losing an interview panel database is a small breach in volume but a large one in trust. Those users volunteered.

None of the above is unique to distributed teams. It just becomes visible when researchers are in a different jurisdiction from users, because the cross-border transfer question forces you to answer questions you should have answered anyway. Teams that hire compliantly-employed researchers in India (rather than contractor arrangements) find the compliance surface simpler, not harder, because the employment relationship carries clean IP and access rules that a contractor arrangement has to bolt on.

"Diligence for our Series C almost stalled over IP assignment on user-research artifacts. We had used a boutique research agency for two years and the master services agreement did not clearly assign the underlying research repository content to us. The remediation took our lawyers four weeks. The lesson: your research assets are IP assets, and how you employ your researchers determines how clean that IP is."
— Vivek P., General Counsel, growth-stage US SaaS, Versatile Club - G2 Verified Review

Q11. How Versatile helps product teams build UCD capacity in India

If you have arrived here reading straight through, the shape of a practical decision is probably forming: you want to build or expand UCD capacity, some of it is going to be in India, and the ambiguous middle is whether you hire through a contractor or agency route (fast, but IP and compliance debt) or invest in full employment on the ground (cleaner, but requires either an entity or an EOR partner).

Versatile is an India-native Employer of Record. That means we run India payroll for US and UK-headquartered product companies on our own Indian legal entity. Your senior product designer in Bengaluru, your UX researcher in Pune, your senior PM in Bangalore. All become full-time employees under Indian employment law (with statutory PF, ESI where applicable, gratuity accrual, health insurance, laptop, statutory leave) but reporting to your product leadership, working your sprint cadence, using your Figma library, shipping your roadmap. See our full breakdown.

What that means operationally for a UCD program: clean IP assignment via employment, straightforward cross-border data handling (we can help set up DPA and SCC where needed), no ambiguity about who your designer or researcher works for. You do not have to educate an intermediate agency on your sprint rituals. You do not have to renegotiate IP clauses every 12 months. You do not have to pay the outsourcing markup on someone else's designer.

Two things worth noting about our approach that differ from the global EORs. First: we are India-native. That means our compliance operations, our HR generalists, our benefits administration, our labour law counsel all sit in India, not in a global HQ that flies to India occasionally. When a design or research hire has a question about PF withdrawal, gratuity vesting, or maternity leave under Indian law, they get an answer from someone whose full job is Indian employment. Second: founder-led operations. We are small enough that Sagar and the ops team know every hire's name. There is no ticket queue.

Practically: if you want to hire your first India-based product designer or UX researcher, or move an existing offshore-agency-based team onto full employment, the path is a 15-minute call to scope, a 5-day SLA on the first hire's onboarding once the offer is out, and a first month free per hire. We do not need you to sign a long contract to try us with one hire.

FAQs

Is user-centered design the same as UX design?

No. UX design is a discipline. UCD is a decision-making process. A UX designer can produce beautiful screens without ever running UCD. And a strong PM can run UCD with a mediocre design team and still ship a good product. UCD is about who has the last word on scope: the user's actual problem, or the loudest voice in the room.

How many users do you need to interview per round?

Five is the working floor for qualitative discovery per persona per round. That is Jakob Nielsen's number and it still holds up. Below five, you catch maybe half the usability problems. Above eight, returns flatten fast. For quantitative work (surveys, analytics-backed hypotheses) you need real sample math: 200-400 responses depending on effect size.

Can UCD work with an offshore or India-based product team?

Yes, and often better than a single-office team. The catch is that async forces you to document things a co-located team gets away with skipping. Personas, decision logs, session recordings with timestamps, written research readouts. If your team lives on Slack DMs and hallway conversations, moving offshore will expose the gap immediately. If your team writes things down, distance disappears.

How is UCD different from design thinking?

Design thinking is a broader ideation framework: empathize, define, ideate, prototype, test. UCD is narrower and older: it starts from the user's task, keeps them in the loop through every decision, and validates against measurable outcomes. Design thinking is what a workshop teaches you. UCD is what a shipping team practices.

What is the biggest predictor of UCD failure?

The build-first culture. When engineering starts shipping before the first user interview is complete, UCD becomes a decoration. You can see it in the artifact trail: research decks that nobody references, personas that never make it into acceptance criteria, session recordings that never get watched. UCD dies quietly, not loudly.

Should researchers be on the product team or on a central research function?

Embedded on the product team is faster; central research is more rigorous. Most teams under 100 people should embed. Above that, a central function with 2-3 senior researchers who set methodology and quality bars, plus embedded researchers on each product team, is the sweet spot.

How much of a product manager's week should go to UCD?

For a PM leading a mature product, 20-30% of the week is a healthy floor: one long user session per week, two hours of recordings review, four hours of writing (personas, readouts, acceptance criteria that reference user context). PMs who spend less than 10% of their week on UCD are functionally roadmap coordinators, not product managers.

Do you need a UX researcher, or can a PM do it?

For discovery work (open-ended interviews to understand a problem space) a strong PM can run it. For evaluative work (usability tests, comprehension studies, quantitative diary studies) you want a trained researcher. The methodology gaps show up fast when a PM tries to run a moderated test. Best-case: PM runs discovery; researcher runs evaluative studies; both work off the same personas.