Reminds me of something I learned from doing art. I've often said, "People think I'm a great photographer. Really, I'm a great editor." I only allow the world to see 2-3% of my output. Working with less experienced subjects, they'd often want several versions of the same basic shot, because I took several good ones. Me, I only want the best version to see the light of day.
It seems that people are afraid to "throw away" work, which means they hold on to things they've built (even when they shouldn't) just because they've invested time in them.
But the throwing-away of work is crucial to building something lasting, similar to editing the photos you show to the world. At the very minimum you gain a better understanding of the problem. The thing you keep probably wouldn't be as good without having done the throw-away work.
This also kinda reminds me of the Picasso Principle [1]:
The famous Pablo Picasso was at a party. A woman
recognized him and approached the Master. She asked,
“Will you create a sketch for me?” Picasso agreed,
and, as he pulled out his sketchpad, asked her for a
subject. “A bird in a tree will do,” she responded.
So Picasso spent about a five minutes doing what
Picasso does on the sketchpad. Finished, he ripped the
sketch off the pad, handed it to the woman and said,
“That will be $10,000.” The woman was floored. “Ten
thousand dollars! Why, it only took you five minutes to
draw that sketch!” To which, Picasso replied, “No,
madam. That sketch took me a lifetime.”
Reminds of a joke about a mechanic who charged $500 for hitting something with a hammer. When the customer grumbled, he said he wasn't charging $500 for the blow, but rather for knowing where to hit it.
You'd better maximize your listening skills before hurrying to sharpen your 'saying No' skills. Half the time I've heard people say "our problem is we can't say No", it was simply a rescue blanket for their pride because they couldn't/wouldn't face the real problem.
I like to think about products as stories. Some things fit into a certain story and some don't. Some stories work well for some audiences and don't for others.
You can imagine and tell any story (build any product) you want. The art is rather to build a great story and often leaving things out even if they sound like a good idea makes the story way better.
Obviously not directly applicable to Product Management but I'm pretty certain that being a great story teller is one of the key skills for Product Management.
The question here is how many of the potential customers you've already reached? How do you define the target group? How do you limit it, especially in very early stages?
At first, startup has 0 customers. Apple has a bit more. Both define customers differently.
For new products, we try to validate the idea with at least 10 people that are wiling to pay. We start with a narrow niche (as narrow as we can make it).
When it answers a need that a sizeable percentage of your users have.
When it makes things easier for a sizeable percentage of your users.
When it can be done at a reasonable cost.
When someone with significant clout specifically hires you to. - In enterprise software it sometimes makes sense to build things to order for a specific client, even if just as one-off project.
When it saves you money behind the scenes.
And, to a certain extent, when you can rapidly prototype it and don't know what will happen - you can sometimes spin it off into a separate product if you're large enough.
Note that need and easier are not things that the users necessarily know themselves.
Sometimes your roadmap is for sale, it happens (http://www.bothsidesofthetable.com/2013/04/15/how-to-sell-yo...). But you know when to say yes by having:
1) A vision of what your product is going to become
2) Understanding of your customers and your market
Reading this, as I prepare my list for tomorrow's product management meeting, having to decide our product's next ~6 months development priorities. Around 100 feature requests and our team's ideas we have to order, of which may be up to 5 major ones and/or 20-30 small ones can be actually developed. An easy task? Definitely not.
So it's a good question, when is it time to say yes?
It definitely depends on the product's stage and having reached or not reached a good product/market fit. There's also the question, have you already discovered a local maxima or is it a global one? And there's a mix of product owner's gut feeling and long-term vision vs proved market feedback.
This post brought into my attention Intercom[1], which seems like a great product, which perhaps was and is still built with that "The Art of Saying No" philosophy, and which can help you communicate with your users and say yes or no to their requests.
It is important to view your product from a holistic/macro perspective. With all the various metric tracking available it's easy to derail your product's focus by optimizing features rather than the product.
So much wisdom. I don't know what the author does for a living, but I hope if it's product management, he get the piles of cash for it he very clearly deserves.
"Yes" to anything not absolutely critical also carries a below-the-sea-part-of-the-glacier opportunity cost to focus on the most compelling part of your offer.
Product posts are always fun here. This "no" strategy is awesome, but only works if you've got support from the C suite. If not, you have sales goals and whoever runs sales will always convince people that they can get more sales with "feature X", which is of course almost always just deflecting responsibility (and is sometimes true for large features that open up new markets).
Fantastic post! The iceberg analogy is one I have used for myself and with my teams many times - the downstream complexities are unpredictable and often large. A great post on this topic by Kris Gale, VP at Yammer: http://insideintercom.io/product-strategy-means-saying-no/
If the product in question is an application or Web service with well defined purpose/workflow, then I agree.
If the product is something like an operating system then I disagree. Visualise different users needs as a series of overlapping circles in a Venn diagram. OPs approach would result in truncating the Venn diagram at the intersection, thus satisfying nobody.
If a feature request doesn't align with the product's vision, it's perfectly fine saying no. If the vision itself is flawed, then the product is not likely to succeed.
Every vision is flawed, because we are fallible. The question is what we do about that. Do we keep the product nailed to the flawed vision until the last user has gone elsewhere, or do we use feedback from reality, from users telling us what they need, to improve the vision?
Another repetition of that commonplace. If you're stupid and untalented, it won't help you, if you're smart and talented you do not need those generalisms and their points are not important to you.
