Gatekeepers say no to everything. Proxies give a yes to every request. How do you find the right balance?
The Problem With Saying No
There are hundreds of articles online about how and why product managers should say no. In this context, negating refers to stakeholder requests that aim to change the scope of a product.
In the short term, product managers get some breathing room by rejecting requests. A frequently encountered quote comes from Warren Buffett: Saying no to almost everything is a characteristic of successful people. This may apply to many professions. But also if your focus is on user-driven products?
The problem arises when the product role is interpreted as a gatekeeper. If the imaginary gate is always closed, you’ll sooner or later find yourself alone in your garden. Repeated rejection can cause a person to give up and not try again, even if change was possible.
Can You Achieve Product-Market Fit Alone?
Achieving product-market fit is a core task in product, perhaps even the core task. A product needs a market or it becomes purposeless. In addition, the product-market fit is a good guiding principle for finding the right balance between gatekeeping and being a proxy.
To find out whether the product meets the market demand, you rely on collaboration: coworkers, users, customers, customer care, key account managers, business analysts, researchers, marketing, cooperation partners, finance people and numerous other stakeholders are an important corrective in order to bring supply (product) and demand (market) into balance.
It’s not up to product managers to decide what the market should want. It’s about hearing what the market actually wants and adapting the product accordingly.
If stakeholder requests are turned down too often, this valuable flow of information will inevitably dry up.
Knowing When to Say No
The idea of a stakeholder is first and foremost a hypothesis. Example: “If users receive a time-limited offer after 14 days of use, the free-to-pay conversion increases by at least 3%.” This hypothesis needs to be verified or refuted qualitatively or quantitatively.
If the hypothesis is refuted, it cannot find its way into the backlog. The important thing is not to reject it straight away, but to give it a chance.
In real life, most stakeholder requests won’t arrive as clear hypotheses. It’s up to the PM to translate them into the appropriate format.
What Needs to Be In Place Before You Can Say Yes
The prerequisite is a product team that has been given the necessary decision-making scope within the organization. If the team’s responsibility is to execute a roadmap, it is difficult to shift the focus to something new.
However, if the team’s responsibility is to solve customer problems and generate added value for the company, new impulses can be included. This only works if the organization trusts the team’s judgment to focus on the right initiatives.
Wrapping It Up
Resist the reflex to say no, even if that’s what product managers are often expected to do. Yes or no is always a case-by-case decision. The key is to form hypotheses from stakeholder requests. These can be verified or refuted. The organizational premise is the product manager’s scope for decision-making to prioritize initiatives based on their business and user value.