How to say “No”
As Product Managers, we often get a lot of requests on daily basis. These various requests, while interesting, can easily clog our backlog and slow us down. Saying “No” allows us to focus on the things that matter and helps us achieve our vision. For the second leg of our series on the “Fundamentals of Product Management”, we brought in Jan Pabellon, the Director of Product Management at Netsuite, with over 8+ years of Product experience under his belt as our speaker last February 21st at the Canva office. Jan has extensive experience managing stakeholders across different countries for different platforms and shared some tips that proved useful to him for managing stakeholders over his career.
The Case of the Pentagon Wars
After introducing himself, Jan kicked off his talk by showing a clip of the Pentagon Wars movie. In the clip, we see Col. Robert Smith (aka. The “Product Manager”) present a troop carrier design to the military top brass. Although the initial design was approved, the top brass began requesting more and more features to be added to the original troop carrier design. Smith couldn’t do anything except to accommodate their results. What resulted was that the troop carrier morphed into a mishmash vehicle completely different from the original design, with a lot of features, but wasn’t good for anything.
Jan then points how Smith actually had a pretty good idea of what he wanted at the start, but because of his inability to say “No” to his bosses, his product turned into a mess that had no focus and no real use. He then presented his key takeaways from the movie and shared specific techniques that he has actually used for each takeaway.
Getting Everyone on the Same Page
Jan’s first takeaway was that for you to say “No”, you need to get everyone on the same page. He enumerates a couple of ways you can do this. First, by having a clear vision of where you want to go, you can align everyone with what you’re trying to achieve. He uses Apple as an example where Steve Jobs, by having a clear vision of the iPod and the Mac, was able to start revolutionizing the consumer electronics industry. He emphasizes that having a clear vision of what you want to achieve in the future, allows you to go back to it and get your stakeholders to be on the same page.
Second, another approach that has helped Jan by was presenting his product roadmap of where they wanted to be in the next couple of releases and linking it to the business strategy. Not only was this a way to align stakeholders on what’s going to happen in the next months or quarters, this also allowed Jan to implicitly say “No” to his stakeholders. If their request was on the roadmap, then they’d know when and what to expect already. Otherwise, they would know that their request was declined or at the very least, was not as part of the focus of the business strategy.
Finally, Jan shares a technique that helped him get everyone on the same page by articulating who the target segments of the product were. By clearly stating who you’re building the product for, it gives clarity to the rest of the team on how their requests are going to be received. Does it fall under the target market? Then we’ll mostly build it. Is a related but different segment? Then maybe we can consider, but it’s not a priority. If it’s completely outside of our target market, then we’ll have to say “No”.
Help them understand the trade-offs
Jan’s second takeaway was that for you to say “No”, you have to help your stakeholder understand the trade-offs. One of the specific techniques for helping stakeholders understand the trade-offs that Jan shared was to show the opportunity cost through the use of the iron triangle of scope/quality, speed, and cost. He emphasizes how you can only pick at most two at the expense of the third. Building a product quickly and for cheap will result into a crappy product, while building a high-quality product quickly is expensive. He also shares how this holds true, no matter what your software development methodology is — Waterfall holds the scope constant while varying the speed and the cost of development, Agile, on the other hand, holds the speed and cost constant, while playing around with the scope. He summarizes by saying that, ultimately, we can ask our stakeholder to ruthlessly prioritize what they’re asking for.
Jan also shares a common problem with managing stakeholders is the failure to weigh the short term versus the long term. It’s very easy to build a feature — it’s hard to maintain it. He shares how a lot of young companies often underestimate the amount of work need to maintain a feature and end up having a hard time maintaining as they grow and scale into other markets.
On the other extreme, another common problem that occurs when the product managers fail to say “No” is feature bloat. Often for more mature products, the number of features a product has will grow over time. If the product manager does not safeguard the product backlog, then the product will begin to lose focus, and a result, will alienate its users. Users would use only a small subset of the product’s bloated functionalities while viewing the other functionalities as an annoyance. As a result, this often results into users leaving the product, and often, translates into lost revenue as well.
Present your case effectively
Lastly, Jan’s final takeaway for being able to say “No” is the ability to present your case effectively. People are more often than not rational. By using facts and data to back up your decisions, people will be able to understand where you’re coming from and are more likely to accept your decision. Jan tells a story of how he prioritized their backlog of features needed to localize their product to various countries. He was getting requests from the different head of sales in each country, and each of them was asking for features to be developed before the product could be localized into their country. He then took a look at how valuable each country was in terms of potential revenue, and from there, he saw that roughly 80% of the total market share actually belonged to a select few countries. Armed with this data, he was able to prioritize these select few countries, and present his case effectively.
Another technique Jan shares for being able to present your case effectively is by shifting the frame of reference for your stakeholders. Jan elaborates how in Netsuite, their leadership in the USA was focused on developing features that mattered to the US, without seeing how the situation looked like in other markets. By telling the story of their growth in other markets like Australia or Japan, Jan was able to shift their frame of reference from a US-centric perspective to a global perspective with multiple markets other than America. This reshifted frame of reference allowed them to focus on the new markets that were still growing instead of continuing to push for US-centric features that actually prevent them from being effective in other markets.
Finally, Jan shares his last resort technique for being able to say “No”. One of the most powerful ways you can present your case effectively is by telling your stakeholders what is in it for the stakeholder. He shares how articulating to the stakeholder the negative aspects of their decision would haunt them later on and creating a detrimental effect on their ego and on their stature in the company. Overall, Jan emphasizes how important it is to talk the jargon of your stakeholders. The head of Sales wouldn’t care about how a certain feature gets built or what tech frameworks you use, but they would definitely hear you out if you talk to them in terms of potential revenue, profit, and loss.
“I didn’t talk about features, or that this will take X months, this will a re-architecture from this Javascript XJS library to this library.
They don’t give a f***. What they care about is the language of business.”
Conclusions and Breakout Sessions
We then wrapped up by breaking into groups of five for the discussions. Some of the interesting highlights from the QA and the group discussions revolved around managing HiPPOs (Highest Paid Person in the Office), How to prevent yourself from becoming a HiPPO, Dual Roling (or Multi-Roling) in a startup environment, and being able to protect your backlog.
Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV
