Loading...
InnovationProduct ManagementSaeed

Stop saying “No” and start asking “Why”

by Saeed Khan

why

Every day, it seems, I see another blog post or article on product development that tells people to say “No” to feature requests.

Don’t believe me? Just do a web search on Say No to feature requests, or something similar, and you’ll see what I mean.

This advice to say “No” started, I’m certain, with this quote from who else but Steve Jobs.

“Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.”

Jobs said this to a group of people from the music industry, who, when showed a preview of the iTunes Music Store, started asking about potential feature enhancements. “Will it do [this]?”, “Will it do [that]?” etc.

This line, like the famous Ford faster horses line that Jobs also spoke about, is definitely a truism, but doesn’t constitute a hard and fast rule, dictating to people that they must say “No” to feature requests.

In the Jobs’ quote, he was simply explaining what he (rightly) believed about the innovation process.

“Why” is better than “No”

Instead of simply saying “No”,  people need to ask “Why?” and try to truly understand the reasons behind the request.

The people making the request should have a clear reason (in their mind) of why they’re making the request, and it is incumbent on you to find out.

Feature requests are pre-conceived solutions to problems. Asking “Why?” (as many times as needed and in as many different ways as needed) will get to the heart of the problem.

And only then should a Yes/No decision be made.

And even with a “No” decision, it can be “No, right now we have other priorities, but we’ll definitely consider it in the near future.” response. i.e. “No” is not always an absolute “No”

The more you understand “Why”, the more context you gain over time at underlying patterns. Different feature requests may simply be different perceived solutions to the same problem.

You’ll never realize this without asking “Why?”

So while I agree that we should say No to non-crucial items, you’ll never know what is and isn’t crucial unless you understand why.

Saeed

Tweet this: Stop saying “No” and Start asking “Why” http://wp.me/pXBON-4cJ #prodmgmt #innovation

About the Author

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.

0 comments
  1. Samir

    Great one. If only PM was as simple as just saying No to anything that isn’t core … it’s really about the balance of rich and incredibly useful functionality while maintaining drop-dead simplicity — and your advice on asking ‘why’ is a great suggestion in this direction.

  2. rcauvin

    Dead on. While product strategists must safeguard the focus and value proposition for the product, reflexively saying “no” is the wrong way to go about it. “Why” is a better start, both from a relationship perspective and from a market understanding perspective. I wrote about it in 2005, particularly how to know when to stop asking “why”.

  3. Stop saying “No” and start asking &...

    […] Every day, it seems, I see another blog post or article on product development that tells people to say “No” to feature requests.Don’t believe me? Just do a web search on Say No to feature requests, or something similar, and you’ll see what I mean.This advice to say “No” started, I’m certain, with this quote from who else but Steve Jobs.  […]

  4. Mike Brown

    I completely agree. I rarely say ‘no’….I often say ‘not now’.

    ‘No’ tends to completely discount an idea where, ‘not now’ takes into consideration the ‘why’.

  5. Craig J Willis

    There’s asking ‘why’ and there’s understanding the request. I used to recommend the 5 why’s to help the team trace the problem back to the root cause. This works but it still requires some skill to do it well. Another approach we take is to use a flowchart representation of the main flows through the product. We use this as a discussion point for the request and we can ask how does it fit in the flow, what’s the impact it will have, does it improve or hinder the user from achieving their goals? We created our own tool for doing this as we needed something that was fast enough that it didn’t hinder the conversation. You can take a look here http://the-skore.com

Leave a Reply

Your email address will not be published. Required fields are marked *