How to Say “No” to Your Boss

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. adult-analyzing-brainstorming-1080865

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.

drawing of eBay search results on a whiteboard illustrating a PayPal logo listed next to every item for sale.
Whiteboard drawing of proposed eBay Search Results with PayPal logo on EVERY row (2002)

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

3 Practices for Building Strong Presentations

A Product Demo Field Guide

There’s a few components to a product demo. The content of the presentation itself. The nuts-and-bolt logistics of how you’ll physically present your content. And then there’s another aspect you have to plan for — the technical difficulties. The mishaps. The curve-balls.

The unexpected.

Though after having delivered a hundred some-odd product demos, these “unexpected issues” have taken a much more predictable air about them for me. In fact I’m pressed to think of a single presentation I’ve given where at least something didn’t go differently than planned.

We can’t know exactly what to expect during the course of a presentation. But we do know the general types of issues that arise, and we can position our presentations in a way that doesn’t allow these issues to unhinge them.

Below are three different ways to address the factors I’ve found to play a consistent role here. By using these frameworks when planning and producing a product demo, you can avoid a great deal of pitfalls that tend to surface while presenting.

3 Practices for Strong Product Demos

1. Limit the Variables

When planning a product demo, it’s understandable to want to “think big”. You want to wow your audience. Dazzle them. Give ‘em the real thing! And then before you know it, you’ve assembled a Rube Goldberg machine of moving parts. Variables that add extra degrees of risk in the successful execution of your demonstration.

But the thing is, the less moving parts you have in your presentation, the less opportunities there are for errors.

An elaborate show of function is not the aim of a product demo. Effectively communicating why a product is relevant, and how it can impact users should be the aim of a product demo.

Anything that jeopardizes that mission is a liability.

2. Establish Contingency Plans (and contingency plans for those too)

Once you’ve trimmed the fat of unnecessary variables, assess the remaining components and identify any possible stress points.

Play out all the scenarios in your head:

What if the WiFi network at a venue gets overloaded? Personal hotspot? Ethernet cable? Maybe I’d be better off using stored content, and not relying on having a connection at all.

What if the file gets lost? Cloud copy? Hard copy? USB Flash drive? USB-C adaptor for flash drive?

What if the device dies on stage? Backup device? Powered on, plugged in, with the demo up— standing by on another video input, just in case?
It only sounds paranoid until it doesn’t. Just ask Bill Gates…

Each demo has a unique environment and requires its own assessment. Creating an exhaustive set of contingency plans allows you to easily circumvent any “unexpected” malfunctions.

Establish and ready your plan B’s, C’s, and D’s (E’s and F’s if you have them). The more you have, the less stress you’re presentation will take on.

3. Improvise 

It’s true. Even with a structurally sound presentation, and an alphabet full of backup plans at your disposal. The best laid plans go awry.

But that’s okay. It’s part of the gig, really.

Stay loose.

Now, onstage, is not the time to be rigid. Stubbornly trying to execute your original plan, when circumstance calls for impromptu adjustments, will only make things worse.

Equip yourself with the advantage of expecting to improvise. Planning on it. Anticipating the moment when you’ll need to think on your feet, briefly.

By simply realizing beforehand that you’ll likely be called upon to make small adjustments throughout your presentation, you’ll enhance your ability to make small adjustments throughout your presentation. Everything from needing to do your demo in half the planned time, to adapting to glitches.

I can remember a product demo I gave where the audio wasn’t working. Naturally, the product being demo’ed had a feature that allowed the user to ask the device what song was playing. Well, given there was no audio the audience couldn’t hear the song playing. But instead of distracting the audience, from the feature itself, with our technical difficulty, I just talked around it.

Something to the effect of, “Now, if you hear a song you like, you can ask the device… and the song will appear on the screen.”

Looking back, maybe it was better that way. Maybe… by not having the song playing, the audience was able to focus on the feature more intently, rather than on the song itself.

Either way, the presentation was fine.

Improvisation is a small but useful tactic to the smooth execution of a product demo.

Hopefully these concepts seem obvious, in part, to most people. The concepts, themselves, are not the key here. The key, here, is deliberately integrating these features into the preparation and production process. When utilized as a cohesive playbook, these approaches can keep even the most sabotaging of issues from the audience’s attention.

Keeping the focus on the product.


Preston Smalley produced in collaboration with Mark Mizera