Best Practices

Product Managers: You Can Say No and Still Make People Happy

In just about every conversation we have with product managers we hear different versions of the same story: We must say no to feature requests that don’t map to top priorities, and we have to do it about 10 times a day.

Product managers get requests from multiple sources: the sales team, key customers, the competition, the executive team and their own market research. Sometimes going through the process of rejecting someone’s idea can be draining, especially if there isn’t a common understanding of priorities across the organization. And no product manager wants to find themselves alienated from those key parts of the organization.

How to do prioritization well–and how to defend your priorities–is an ongoing conversation in the product management community. We’ve gathered up a few recent blog posts from some of the best minds in the Product Management community who offer up their expert advice on this topic:

“Prioritization Requires Strategy” by Rich Mironov

Product Coach Rich Mironov discusses the vital importance of alignment among executives to ensure that the product development plan maps up to the overall business strategy.  In this post Mironov describes a situation in which an organization wants to cut costs and scale output–at the same time– and Product Management, in this case a director of multiple product managers, has to take responsibility for prioritization and driving alignment at the executive level.

“But without some force-ranking among these top-level issues, the development organization can’t prioritize stories or work. There is no natural prioritization of development work without an underlying strategy.”

Only after this strategic framework is in place can Product Management ensure that the right user stories are selected and the engineering and operations teams are working on the right things. [Read more about how Jama enables ranking.]


“Don’t Prioritize Features Based on Development Cost” by Jeff Lash

So your product roadmap is solid, mapping to business strategy and the organization is in alignment. Then a bright developer brings an idea to you that indeed seems to fit on the roadmap, but you know from experience that’s not enough to prioritize this feature. In this post Jeff Lash of Sirius Decisions talks about a next level of prioritization, not just considering the effort to develop a new feature, but also the cost to test, deploy, market, sell, and maintain it.

“The cost to develop an enhancement may be only a tiny fraction of its overall cost.”

Before development on a new feature can get the green light many other expenditures of effort and money have to be considered:

  •  QA Testing
  • Training sales engineers
  • Creating demos
  • Support training and documentation
  • Sales training and support materials
  • Marketing materials
  • Customer Success training for onboarding customers

And likely Product Management isn’t responsible for all of these activities so enlistment of the departments who will do the execution is wise before you commit the organization to new development.

Lash offers some great frameworks from Sirius Decisions, including a product management tool guide (including Jama Software!) with more guidance for product managers.


“Dealing with one-off feature requests” by Steve Johnson

Once you’ve said no to a feature, you have to make sure the people requesting it understand why. In the case of Sales this is critically important as they’re the people who are doing hand-to-hand combat in the field against your competitors, who may already have this seemingly critical capability. Whatever they think of your decision, Product Management (likely with the help of Product Marketing) has a responsibility to support the Sales team in the field.

Steve Johnson, a product management coach, suggests a “battle card,” a cheat-sheet of competitive intelligence that guides sales conversations to position your product favorably against a competitor and, just as importantly, tells sales people how to recognize when to walk away from a deal.

“One-off feature requests are usually competitive in nature so you’ll want to provide a battle card showing how to win against each competitor. Admit that they have lower prices or stronger architecture or whatever. And then position yourself against them in a positive way. ‘They are good for this but we are good for that.'”


Want to find out more about prioritization and keeping teams aligned? Register for our webinar on Agile Workflow Design on May 21st with Jama Product Manager Robin Calhoun. Can’t make it that day? A recording will be available on the Jama Resources Page. You can also read more about Agile Workflow Design in this past post.