PM Interview Tips: User Focus & UX Mastery

PM Interviews - User Centric Approach & UX (Part - 3)

How would you solve the problem of high cart abandonment in an e-commerce app?

For high cart abandonment in an e-commerce app we need to look into user behavior, friction points, and intent drop-offs across the purchase funnel. The problem could be due to poor UX, lack of trust, hidden costs, or weak purchase urgency .

First, I would analyze where users are dropping off—is it at the cart page, address entry, payment screen, or after viewing delivery charges? We can use funnel analytics and heatmaps to identify friction points. For example, if a large drop-off happens after shipping costs are revealed, users may be reacting to unexpected charges. In such cases, offering free delivery thresholds, transparent pricing, or bundling deals can improve conversion.

Next, we should improve user experience by simplifying checkout. We can offer one-tap purchase for returning users, guest checkout for first-time users, and save address/payment details securely. A cluttered or lengthy checkout process is a major abandonment trigger.

To create urgency, we can use low-stock alerts, limited-time offers, or flash deals for items left in the cart. Additionally, we can flash “Still thinking?” pop-ups or cart reminder notifications with gentle nudges or discounts to re-engage users.

Finally, we need to address trust and convenience. We need to ensure that we have clear return policies, estimated delivery dates, and multiple payment options including COD (popular in Tier 2/3 India). Testing variants through A/B experiments will help determine which interventions move the needle most effectively.

Design a new app for parents of children below 5 years old.

If I were to design an app for parents of children under 5 years old, I’d start by doing proper user research—talking to different types of parents: working couples in cities, single parents, joint families in Tier 2 towns, and even first-time parents in rural setups. It’s important to understand their daily routines, stress points, digital behavior, and unmet needs before jumping into feature design.

From an STP lens, I’d segment parents by location (urban vs rural), digital comfort (tech-savvy vs low digital literacy), and parenting stage (infants vs toddlers). I’d initially target digitally connected parents in Tier 1 and 2 cities, who are proactive about their child’s health, learning, and emotional development. These are likely to be first-time or nuclear family parents looking for credible, easy-to-use support. We’d position the app as a “smart parenting co-pilot”—helping them track, learn, and bond better, all in one place.

Now, coming to the design, our goal would be to build something that feels supportive, not overwhelming. I’d include a personalized child growth dashboard, where parents can log milestones, vaccinations, sleep patterns, and nutrition habits. It’s like a visual memory journal + health tracker.

We’d also add a “What to Expect Today” feed with age-relevant tips, activity ideas, and food suggestions. And to make the app usable even when parents are rushed, I’d include voice notes and photo logging, so they can quickly capture updates or send them to caregivers.

For community and emotional reassurance, we’d create a safe parent forum—focused on practical support and moderated discussions (not social comparison). And because parents often need urgent advice, I’d build in access to pediatricians or certified experts for quick Q&As.

UX-wise, the interface would be clean, calm, and colorful—with illustrations, large touch targets, and multilingual support to include Tier 2/3 audiences over time.

At the heart of it, we’re not just building a parenting tool—we’re building empathy at scale, helping parents feel more confident, informed, and emotionally supported in the most formative years of their child’s life.

How do you conduct user research before launching a feature?

Before launching a feature, I will use user research as my compass—to help me avoid building in the dark. I would start by asking: “What problem are we really solving, and for whom?” That guides everything that follows.

First, I’d clearly define the user segment we’re targeting—are we solving for power users, first-time users, or maybe a specific geography or age group? Then I’d try to talk directly to these users—through interviews, surveys, or even informal voice notes. I prefer qualitative research early on because it helps me uncover not just what users do, but why they do it. I will ask open-ended questions like: “What’s the most frustrating part of this flow?” or “When was the last time you gave up mid-task?”

Once I’ve got some directional insights, I complement that with quantitative data—funnel drop-offs, heatmaps, support tickets, or NPS feedback. This helps validate whether the problems I heard about are widespread or edge cases.

If time allows, I would love running quick prototypes or low-fidelity mockups—either clickable designs or simple visuals—to get early feedback. Sometimes, just showing a user a screen and watching where they tap tells you more than 10 survey responses.

I also involve cross-functional teams in this process—design, support, and marketing folks often have hidden gems from their user touchpoints.

Before locking anything, I would always ask myself: “Are we solving a real user pain, or just building because we can?” That question keeps the feature grounded in value.

A product you launched is getting negative reviews. What steps would you take?

If a product I launched started receiving negative reviews, I would treat it as a signal—not just of dissatisfaction, but of an opportunity to learn, empathize, and improve. My first instinct wouldn’t be to defend the product—it would be to listen carefully and dig deeper.

I would start by categorizing the feedback—is it about usability, bugs, missing features, performance, or something emotional like trust or frustration? I’d look for common patterns across app store reviews, social media comments, and customer support tickets. If possible, I’d also reach out directly to a few vocal users for short interviews to understand the context behind their experience. Sometimes what users say and what they actually mean can be different, so listening empathetically is key.

In parallel, I’d sync with the design and engineering teams to see if we can reproduce any issues, check crash logs, or verify usability bottlenecks. If the problem is critical—say, login failures or data loss—I’d prioritize a hotfix immediately, with proactive communication to affected users.

Once the root cause is identified, I’d work on a clear action plan—whether it’s a product redesign, performance improvement, or even just better onboarding. But I wouldn’t stop there. I’d also create a follow-up communication loop—a “We heard you” note in-app or via email, release notes that acknowledge the fix, and maybe even a thank-you message to the users who flagged it.

Ultimately, I’d see negative reviews not as a failure, but as user passion—they cared enough to tell us what’s not working. My job as a PM would be to turn that feedback into a better experience and win back their trust.