The Most Powerful Word Known to Mankind

Posted: 22 Jul 2013 03:00 AM PDT

"Nathan," my boss says to me, "we need to get this feature in before we launch the product."

"Don’t worry, it’s fairly simple and shouldn’t take long," I reply.

The request had been lobbed at me out of nowhere. The request seemed pretty straightforward, and apparently it was mission-critical.

If only I’d realized it was actually a grenade threatening to destroy our product release plans.

You’ve probably been in that same narrative before.

These seemingly small and simple requests can quickly become complex, dangerous, and an absolute nightmare.

As the product manager, I should have — and could have — avoided this nightmare by using the most powerful word known to mankind:

No.

Why I Had to Learn to Say No

It had all started so well, we knew what we had to do and started to burndown the stories in the sprint.

(By the way, we use the Scrum software development method. If a term in this article isn’t familiar, check out this Scrum glossary of terms.)

Further requests came in, which wasn’t unusual, and they were quickly accepted without proper investigation.

Oops. Big mistake.

All of a sudden, the release had become bloated and it became much bigger than we had ever anticipated.

There were early signs of the release going off track, with the sprint burndown lagging, the story points increasing significantly, and an unusually large amount of questions being asked about the new stories.

Worst of all, I had started to look like an ass.

The scope had crept, clarity was absent, and I was losing control of this project.

We were hemorrhaging big time.

The bleeding had to stop.

My mindset switched over.

I had caused this mess. So I was going to fix it.

The only way to fix this was to use that amazingly simple but powerfully potent word.

Here’s how I did it, and how you too can get to No.

Stop the Bleeding

Just say No. Don’t use fluffy, doublespeak language. Just say it.

No.

Deny new requests until you have the time and resources to properly look into them. Also, bear in mind that there will be future releases, so you can responsibly delay some ideas into the next release.

This sounds so easy, but it takes some getting used to. It takes a change in thinking.

For example, as a product manager, I’m often under intense pressure from the CEO or the client or my boss or a decision-maker. Saying No to these folks seems to be a career-limiting move.

No is your strongest tool for stopping the bleeding. It will let you reset and it will get you back in sync.

Flip the Problem

I explained why new requests were being rejected. We were close to the release date, and we just didn’t have enough time.

This, too, sounds quite easy; it was a good and honest reason for being unable to accommodate a request.

Yet it’s easy to forget that non-technical folk see what we do as black magic.

Don’t bother with the technical reasons for why the request is difficult to accommodate. Rather, highlight the consequences of adding extra work, such as a delayed release, increased costs, cranky and pissed-off software engineers, and so forth.

If you’re really pushed, make a point that every decision has its consequences.

"We can do what you asked. It just means [TheOtherFeatureYouAskedFor] has to go. Which is more important?"

The ball’s now in their court.

Appeal to Higher Objectives

If a feature request doesn’t progress you towards your business goals, or if it isn’t inline with your product strategy, why are you going to do it?

These types of scope-augmenting requests are often hastily made and not well-formed. They often shouldn’t be in the product until they’ve been better developed.

(Read more about creating good project scopes.)

Learn to say "No, it doesn’t help us get to our goals and it will have to wait for now."If the entire team is heading towards the same objectives, this will also help you gain broader support from other project members.

You Own the Backlog

One of the best tools for product managers is the sprint backlog. And you need to be all over it if you’re a manager.

If the product backlog is mysteriously growing, you’re in big trouble, and you need to step up, get all totalitarian and dictatorial, and let the offenders know the sprint backlog is your domain.

You must own it, and no one else can add to it regardless of how simple the task seems.

This might require a cultural change in your team, and be prepared for some push back, but you must get it done.

If you can’t control your backlog, you’re fighting a losing battle.

Final Thoughts

Hindsight is a wonderful thing. Watch out for seemingly simple requests that are actually grenades in disguise.

I’m now much more proactive about saying No. And if you too want to sidestep the problems I’ve faced, you must also learn how to use No, the most powerful word know to mankind.

About the Author

Nathan Conyngham is a customer advocate focusing on project, product and expectation management. He’s an avid believer that the best results are achieved by focusing on the customer, having clarity of purpose and executing well. Get in touch with Nathan via his personal blog or on Twitter @nathanconyngham.