PM Interview Tips: Execution & Collaboration

PM Interviews - Execution & Collaboration (Part - 5)

A senior stakeholder disagrees with your roadmap. How do you handle it?

If a senior stakeholder disagreed with my roadmap, I would approach it as an opportunity to listen, align, and strengthen the plan—rather than a personal conflict. My first step would be to understand their perspective fully before defending my own.

I would set up a one-on-one discussion where I could walk them through the context, assumptions, and data behind my roadmap decisions. At the same time, I’d actively listen to their concerns—whether they are about business priorities, timelines, resource allocation, or market opportunities we might be missing. Often, disagreements arise from different success metrics or time horizons (short-term revenue vs. long-term growth).

If our priorities still conflict, I’d look for common ground—maybe reprioritizing certain features, adding a proof-of-concept phase, or building a parallel track for quick wins while keeping the long-term plan intact.

Throughout, I’d maintain transparency and document the rationale for any adjustments, so both leadership and the team have clarity. My goal wouldn’t be to “win” the debate—it would be to co-create a roadmap everyone can stand behind, ensuring execution isn’t derailed by misalignment at the top and that ultimately it benefits the user.

How would you write a Product Requirement Document (PRD) for a live chat feature?

If I were writing a Product Requirement Document (PRD) for a live chat feature, I would ensure it’s clear, structured, and detailed enough for engineering, design, QA, and business teams to align on what we’re building, why we’re building it, and how we’ll measure success.

I would start with the objective and background, explaining why this feature is needed. For example, “The live chat feature aims to improve customer support by enabling real-time assistance within the app, reducing ticket resolution time and improving customer satisfaction scores.” I’d then define the scope, clarifying what’s included in the first release, such as real-time messaging, canned responses, file sharing, and chat history—and what’s out of scope, like chatbot automation or multi-language support, which can be planned for later phases.

Next, I’d outline user stories to describe the feature from the perspective of both the end user and the support agent. Functional requirements would detail the must-have elements, including the chat interface, agent assignment logic, notifications, file upload capability, and chat history retention. I’d also add non-functional requirements like response latency under 2 seconds, 99.9% uptime, and end-to-end encryption for privacy.

To aid the design team, I’d attach wireframes or mockups showing the chat entry point, conversation interface, and notification flows. For measurement, I’d define success metrics such as reducing average resolution time by 20%, increasing CSAT from 4.2 to 4.5, and handling at least 30% of support queries via live chat within the first three months.

Finally, I’d note dependencies (e.g., integration with Zendesk or Freshdesk, push notification services, and backend authentication) and outline risks like agent availability issues, along with mitigations such as staggered shifts or a future chatbot fallback. I’d then review the PRD in a cross-functional kick-off meeting to ensure everyone is aligned before development begins.

You're behind on your release deadline. How do you manage cross-functional expectations

If I were behind on a release deadline, my first step would be to acknowledge it early. Delays are best managed when everyone knows what’s happening before it becomes a surprise or a shock. I’d work with the team to pinpoint the root cause, whether it’s technical complexity, dependency bottlenecks, or late-stage bugs and gather enough detail to present a clear, fact-based update to stakeholders.

I would then communicate openly with engineering, design, QA, marketing, and leadership, explaining what caused the delay, how much time we realistically need, and the options we have. For example, I might propose cutting or deferring non-critical features to meet a revised launch date, or adding resources to parallelize work. This way, stakeholders aren’t just hearing “we’re late” ; they’re part of deciding the recovery plan.

Example from my own experience: On one project, we were building a payments reconciliation dashboard for a fintech client, and a third-party API change during final testing caused major delays. I immediately gathered the engineering lead, QA, and client stakeholders to realign. We agreed to launch a “read-only” version of the dashboard with core reporting features on the original date, while the API-dependent automation was pushed to a Phase 2 release two weeks later. This approach kept the client happy, allowed marketing to go ahead with their campaigns, and gave the team breathing room to deliver the full feature without cutting corners.

By owning the delay, being transparent, and offering practical alternatives, I was able to maintain trust, keep morale high, and deliver a quality product without burning out the team.