Master the Art of the Product Manager 'No'
Product managers’ habit of using soft, evasive ways to say “no” to feature requests is seen as both a practical necessity and a source of deep frustration. Commenters describe how vague promises (“we’ll consider it for the roadmap”) create tech debt, false expectations with customers, and morale problems, arguing for clearer prioritization based on value and transparent communication about what will never be built. Many tie this to broader organizational dysfunction—misaligned incentives, politics, and risk aversion—where process and optics often trump honest trade-off decisions.
Soft vs hard “no” and feature creep
- Several distinguish between a true “no” and a soft deferment; in immature orgs the distinction is tactically useful but dangerous.
- In B2B sales, soft “nos” (“we’ll consider that”) are often heard as “yes,” causing commitments PMs never made, unrecognized revenue, and one-off features that rarely close deals.
- Multiple engineers recount products littered with rarely used, high‑quality features built for single prospects, creating tech debt and making later removal harder.
Prioritization, backlogs, and planning frameworks
- Many see prioritization as the core PM/engineering skill: there are always vastly more ideas than capacity.
- Some describe explicit criteria to move ideas from “backlog limbo” to action (feasibility, alignment with goals, ownership, relative importance, urgency).
- SAFe and heavyweight planning can help dysfunctional teams surface dependencies, but are often misused to “lock down” plans, block new work, and beat down morale.
- Long backlogs can become “idea shredders”; some PMs use simple value/effort quadrants and “next step” fields to limit re-triaging.
Honest no vs corporate euphemisms
- Many commenters dislike the canned phrases from the site, calling them passive‑aggressive, demoralizing, or dishonest.
- Some argue internal teams deserve direct, contextual “no” (“we’ll never do this and here’s why”) rather than vague deferrals.
- Others stress tailoring: softer language can keep stakeholders engaged and prevent meetings from being derailed, as long as the underlying message and odds are clear.
Engineers, process, and “just build it”
- Stories appear on both sides: engineers who quietly build prototypes that unlock value, and managers who rightly push back due to testing, integration, stakeholder impact, and priority disruption.
- There’s tension between “cowboy coding” heroics and the real overhead of shipping in larger orgs (QA, documentation, change management).
Role and perception of product managers
- Views diverge: some see PMs as political gatekeepers or “idea antibodies”; others as necessary mediators who focus teams on value.
- Several emphasize that engineers are stakeholders too, and that motivated engineers and small “option value” bets (experiments, refactors) should influence priorities.