Or Worse: Your Boss’s Boss
It’s a product manager’s worst nightmare:
An Exec gets an idea from a teenager that lives next door. Imbued with optimism, the higher-up urges you and your team to drop everything and put all hands on deck. This is where we should be focusing right now.
Great.
Well, not only do you disagree with the efficacy of this proposed feature, but you’ve also seen the train wrecks these situations can cause. Teams get frustrated by being told to do something without understanding why it’s important. Execs get frustrated by a lack of production.
Your instinct is to push back.
But is there any good way to say “no” to your boss? And if there is a good way to do it, is it ever a good idea in the first place? For me, the answers are: yes, and definitely.
If you’re in a leadership role, working within a hierarchy, being able to say no to your boss can actually be an essential skill for success. If done correctly, it can make you a better leader, a more valuable employee, and a more reliable teammate.
Plus you’ll never actually have to say the word “no” to your boss.
Here’s how:
1. Stop Thinking in “Yes” and “No’s”
The first step in effectively saying “no” to your superiors – when it seems necessary – is to stop thinking in “yes” and “no’s”. This part’s really about good listening.
When a superior gives a sudden order, it’s natural to analyze the order itself. But by immediately jumping to that step, you’re missing the bigger picture. Before rushing to give this person an answer, ask them some questions about the idea they’re proposing.
Create a dialogue with them and, eventually, your team members.
2. Identify the Issue
Just as great art often comes from pain and suffering, great ideas often come from problems and difficulties. But in a business, some issues are more important than others. Find out where this idea came from. What customer issue would this feature be solving?
The issue at the root of an idea is more important than the idea itself. An idea may be interesting, but if the problem it solves isn’t that important, than the idea really isn’t as valuable as it may seem.
3. Enable Your Team Members to Weigh In
Once you’ve identified the underlying issue, go back with your team members and evaluate the problem.
Bring in the data: Are we losing customers from this issue? Might we gain users by solving it? Are we already solving it? Might this new idea, in fact, be a better solution?
If it becomes evident that this issue is significant, take a moment to explore other viable solutions, and weigh them against the original proposition. If, on the contrary, the underlying issue is revealed to be insignificant, it’s probably best the feature not be built.
4. Sleep On It
Whether you found the underlying issue to be significant or insignificant, take a page from old wisdom and sleep on it.
Even if you manage to complete this process within the same business day, you don’t want this person to feel like they’re being brushed off. Aside from the notion that you probably owe it to this person to give their idea at least a full day or two’s worth of consideration, you never know. This part may surprise you.
You might have an idea yourself. Someone from your team may send you an overlooked piece of data they stumbled across.
I could’ve used this advice earlier in my career. There was a instance at eBay years ago that I can remember clear as day. While figuring out how to enable users to find items that accepted PayPal, an Exec suggested we have the logo pop up on every search result that featured the service (already accepted by 95% of sellers). At the time I was a very-much green UX designer and I’m thinking in my head, this guy wants to make the website look like the sidewalls on a NASCAR track. Only the problem was I wasn’t just thinking this in my head. I actually jumped out of my chair and shared my reaction. At the time I was so green I didn’t even understand that my actions were unadvisable. It just seemed so wrong I had to stand up.
I realize now that while my stance may have been justified, there was a better way to go about expressing it.
If the circumstances allow it, give yourself a chance to process the findings before presenting them.
5. Present a Data-Driven Decision
Most of all you must follow up.
Never assume that, if you’ve found the idea to be something you shouldn’t pursue, that you just leave it there. If you don’t follow up with the Exec they will naturally think you ARE pursuing the idea. And if they ask you about it later, you’ll be on your back-feet in terms of reporting on your earlier process (steps 1-4)–and will need to start over.
In the end, you can let the data speak for the decision.
Demonstrate that you’ve analyzed the issue at the root of the idea. You’ve explored viable options. And ultimately you’ve landed upon the solution that best aligns with company goals.
And if this means essentially saying no to an Executive’s idea, at least you’ve followed a judicious and egalitarian process. You’ve done what you’re paid to do.
A good executive will be able to see that.
Preston Smalley produced in collaboration with Mark Mizera