The Art of Saying NO

A framework to keep crap out of products

Great products have one thing in common: A product leader that says “no” to most ideas. It is that focus — that relentless pursuit of mission — that achieves the impossible: products that touch millions of lives. If you’re in the business of building products, Intercom’s “Product Strategy Means Saying No” is a must read.

But in reality, saying “no” is hard. Very hard.

If you’re not Steve Jobs, you know what I mean. There’s a vision. A roadmap. A set of priorities. Piles of defects. Ideas — from hallway conversations, random brain farts, user feedback, whatnot. Then there’s stakeholder pressure — “CEO wants this, Board wants this, Sales Channel wants this, etc.”. Every day, you’re inundated with ideas and feature requests from people that care about your product. And people that don’t.

Of-course, there’s data. But more often than not, it looks more grey than black or white. Data is not always right, and more importantly, instincts don’t often agree with data.

Whether a product is new or old, something is always broken with it. Every time you stare at it, there’s something that just doesn’t belong there. Yet it’s there. And removing it feels impossible.

Very few products in the world feel like they get this “no” right. That their makers are adamant —sometimes even arrogant — about saying “no”. I still miss that center-align button that Medium removed last year. But I get it.

I often wonder — how many product managers are out there screaming “this is not right!” as decision after decision is forced on them by people they can’t say “no” to; who are sometimes shy to tell their friends about the product they lead because of how shitty it is.

Whoever came up with that “Product Manager is a mini-CEO of a Product” clearly never had that job.

So how do you say “no”?

By not saying “no”, but by establishing a framework to say “yes” or “no”. A framework that everyone on the team not just agrees to, but lives and breathes; and uses it to evaluate ideas.

It’s about four principles: vision, values, strengths, priorities.

Vision

This is your world view. Your first principles. A fundamental belief on why your product should exist, why the user needs it, and how it’s different from— and better than — any other alternative available to the user. Without this, a product shouldn’t exist.

In the early stages, this evolves with more understanding and validation. But it doesn’t (or shouldn’t) change. If it does, that’s a different product. Early stage is all about experimentation, so changing the vision is not a bad thing, but once it’s chosen, sticking to it is important to build a product around it.

If everyone on the team is not 100% clear (and aligned) about this world view, that’s a problem that must be solved.

Values

These are some core beliefs that dictate what you will not do. A set of ideals that your product will not compromise. Some that in your view no product should compromise.

They define the character of your product. They’re not just “do no evil”, they are concrete beliefs such as “quality is more important than quantity”, “reads are more important than views”, “lowest price is more important than broad selection”, “never post on Facebook without user’s permission”, “make decisions for the user”, etc.

As a product goes through ups and downs, there’s constant pressure to compromise. Especially when those growth hackers arrive, and take positions with their viral weapons. Great product teams don’t have growth hackers. Problems change, solutions change, but values don’t change.

Strengths

These are your core capabilities as a team that dictate what you can do. They include your engineering capability (and specialities), knowledge about the users and their problems, sales and marketing horsepower, and relationships in the space.

In the early stage, this is all you have to begin with, and it (hopefully) determines why you will succeed (or not). It really helps to think hard about this and write it down, because it is so easy to ignore this and embark on efforts that are guaranteed to fail. This is one of the biggest mistakes I’ve made, and something I see almost everyone make.

It is easy to add search, but not easy to get it right. There’s frameworks to build anything, but making it work right is extremely hard. The grass always looks greener on the other side. All water looks drinkable from 10,000 feet.

Priorities

These are goals that must be accomplished within a certain period of time, sorted by importance. They’re always changing, but they’re always there. So any new activity has to be weighed in and slotted amongst these priorities.

With such a framework, you can collectively evaluate ideas and feature requests by framing the right questions:

• Does this fit into our world view?
• Is this something we believe in?
• Are we capable of doing this?
• Where does it fit in our priorities?

And then make a call, as a team, to say “yes” or “no”.

The hard part is coming up with the framework itself — it takes a lot of collective thinking, brainstorming and debating to create it (and constantly refine it). But once it’s there, it can be a powerful tool to keep crap out of product.

The most important part is communicating it over and over again. To a point where it sits in their long-term memory; and subconsciously does it’s act when new ideas or feature requests arise. “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime” — Maimonides

I’m not sure if this is the best way to do it. I’m not sure if there is a best way to do it. But I do it. Ultimately, especially in consumer products, everything is an experiment. The trick is to pick the most promising, calculated experiments without blowing things up or before time runs out.

But crap is not worth it.

Liked this post? Please hit 💚 below so others can benefit! Thank you!