Firstly, prioritization should always be about delivering value, not just features. Be transparent with stakeholders early in the process. Give them a heads-up and involve them in risk assessments so that they have a clearer understanding of why certain trade-offs are necessary. I always encourage my PMs to wear the “company hat” and re-evaluate their stance from a broader business perspective. It’s crucial to clearly share the rationale behind decisions, too. Combining clear communication with empathy helps acknowledge frustrations and build trust. Finally, provide an alternative plan, such as a future timeline or workaround. This reassures stakeholders that their needs are still being considered, even if the feature is delayed.

When stakeholders push back on deprioritized features, embrace the conflict. It's a sign of passion. I once faced a furious VP demanding we revive a scrapped feature. Instead of deflecting, I invited him to a war room session. We plastered the walls with user data, revenue projections, and resource constraints. For hours, we debated, scribbled, and rearranged priorities. We asked, "If we do this, what are you willing to sacrifice?" This shifted his perspective from demanding to problem-solving. We emerged with a compromise - a scaled-down version of his feature, bundled with a high priority item. The keys - Transparency, involvement, and forcing tough trade offs. Don't hide from conflict, use it to build stronger alignment.

Weight factors: Engage in active listening with stakeholders and affirm their frustrations. Clarify prioritization: Articulate the reasoning behind the prioritization of current work, centering on business objectives and user impact. Establish long-term value: Reassure stakeholders by applying deprioritized features to future releases. Offer alternatives: Propose quick wins or alternative solutions that may alleviate some of their frustrations, without pushing out additional features. Be transparent: Continue to have regular conversations about how the project is progressing so they are aware their input will make it into the product through a future update.

It's normal to face pushback, whether internal or from customers. For example, a client once requested a security feature for an app that allowed users to notify others of danger on specific routes. Given his security background, I understood the importance, but looking at our roadmap and backlog, we had to prioritize a referral feature instead. The client wasn't happy, so I met with him, acknowledged his concerns, explained why the security feature was deprioritized, and showed him the roadmap. After taking his feedback, he felt reassured. We proceeded and successfully delivered the solution.