One of the most difficult tasks of a product manager (or project manager, or entrepreneur, or anyone else in a decision making position influenced by multiple stakeholders) is to say no. There’s a real temptation out there to try and be all inclusive and accommodate everyone.
I’ve always believed as a good product manger you shepherd the product, influencing it in the right direction by balancing as many of the external forces as possible. To best serve the product the most important and shamefully underused tool is a simple two letter word, no.
Every day we as product managers make countless decisions that refine the product’s identity. We react to the market around us and all the conflicting tugs of the stakeholders in order to speak for the product’s ultimate best interest – the fulfillment of its value proposition. Well, that’s the hope anyway. What actually ends up happening is we end up compromising one or more aspects of the product’s identity and put ourselves in more difficult positions than had we just confronted the bad-idea head on.
There’s three parts to my usual method for approaching a no situation. They spell ACT because I like acronyms and I also wanted to point out that saying no is NOT being inactive, it is as much taking an action as bending to some wayward suggestion.
Begin by reiterating the proposal to be sure you understand the what, why, when and how of the request. Ask questions for clarity if you are unsure about any part of the request. It’s a standard communication technique that is meant to mitigate confusion and confrontation by helping reenforce to the other person you understand their position and ‘get it.’ It also makes them hear what they are asking. You would be surprised how many times I’ve witnessed the restatement of a request to the requester result in the rescinding of the request when they hear how little sense it makes or how much is really missing from a suggestion when put through WWWH assessment.
It is the first step in providing buy-in even if you don’t necessarily agree with doing what they’re suggesting so don’t by-pass it.
Now that you’re sure you understand what it is that’s being asked formulate your counter. There are a number of ways you can produce a no, but not all of them are created equal.
First and foremost three don’ts:
1) Don’t get mired in the details. It is really easy to pick apart a proposal point-by-point and that tactic almost always puts people on the defensive. The minute the proposer goes on the defensive they stop listening to you.
2) Be careful not to lose sight of it being about the product. There’s an inherent temptation for humans to project our feelings. If you’re not a fan of the proposal stay neutral about the person proposing it. A bad proposal doesn’t make them a bad person (most of the time). This isn’t a debate about them, so don’t allow it to accidentally become framed as such.
3) Never lose focus and become tempted to off-the-cuff suggest something else to pacify the requester. Nothing causes more trouble than suggesting an un-researched solution to an nonexistent problem. It’s a pandora’s box – open it and only bad things will happen.
Instead, try these three dos:
1) Focus everything on the value proposition. All changes to a product should positively impact the underlying value proposition. By taking all product decisions back to the Value Proposition you are forced to justify it against a common definition. This counteracts tendencies such as when using agile techniques like Feature Driven Development and Scrum where the day-to-day operation can overtake the big-picture view or when there are a large number of competing stakeholders trying to influence it. Remember the Value Proposition defined the strategy and roadmap for the product initially and continues to define it’s management and marketing throughout the life-cycle.
2) Use the product roadmap and long-term evolution strategy to your advantage. If the proposal doesn’t align to these established guides for the product it effects the established scope. There’s a tradeoff when impacting the scope both on a product and project viewpoint using the constraint model. Assuming the triangle of Scope-Budget-Schedule if you increase the burden on scope you need to increase budgets and schedule accordingly in order to maintain product quality. This naturally results in overruns of budget and time to market, and still has the potential to impact quality as well.
3) Frame broad concepts around Return on Investment / Cost-Benefit Analysis logic. This can be in financial terms, which is how most people view it, but ROI can be calculated in any number of ways and how you, your division or your company decide to include human capital and other resource inputs as well as outputs such as good will and brand equity will impact your deduction. There are plenty of case study examples of product innovations that yielded increased revenues with a high human capital cost in the process which is why I always suggest a balanced ROI approach. Regardless of how you deduce the ROI, cost-benefit analysis
One caveat is this is an initial rejection not a patent one. The important difference being, just because an idea doesn’t fit now the way it is doesn’t mean it cannot or will not fit later at another time. Value Propositions and product strategies change over time. They are inherently dynamic as consumers and society are constantly evolving.
Now that you’ve made your case for no, stand behind your decision. If you took the time to counter the proposal in the first place