Product Strategy Means Saying No | Hacker News Reader

Product Strategy Means Saying No

insideintercom.io

166 pointsruswick39 comments

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.

Following on my own comment, I see this as meaning don't include any feature that doesn't directly contribute to the wholeness of the product.

Great analogy. Need to remember that :)

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.”

1. http://www.ideasicle.com/Ideasicle_Site/Blog_%26_Podcast/Ent...

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.

Picasso was famous for bartering sketches:

http://answers.yahoo.com/question/index?qid=20100916104440AA...

I'd say $10,000 is a pretty good deal!

Which is absolutely your prerogative - as long as you're not asking anyone to pay you for the service or to base their work on yours.

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.

Here are great insights about how Pixar creates great stories: http://www.prdaily.com/Main/Articles/Pixars_22_rules_of_stor...

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.

e.g.: I love this hack:

"When you're stuck, make a list of what wouldn't happen next. Lots of times the material to get you unstuck will show up."

Sounds similar to the McDonald's theory:

"I use a trick with co-workers when we’re trying to decide where to eat for lunch and no one has any ideas. I recommend McDonald’s.

An interesting thing happens. Everyone unanimously agrees that we can’t possibly go to McDonald’s, and better lunch suggestions emerge. Magic!"

from: https://medium.com/what-i-learned-building/9216e1c9da7d

I think this is great but as a person who has never lead product, when is it time to say yes?

Great question.

For our team, we say yes to whatever solves the biggest pain, for most of our users.

We discover this by reaching out to customers, and doing a lot of listening. We're trying to answer two questions:

1) What is your biggest pain in your daily work?

2) What is your biggest pain in our software?

#1 usually leads to new features.

#2 usually leads to revisions of what we have already.

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).

Can I interview you for my book?

info@howtofindsaasideas.com

Shameless plug: working on a book that goes into how to reach out to potential customers when you have none.

http://howtofindsaasideas.com/

(Yes, I know the landing page sucks and is buggy. Working on a new one.)

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

Only when these things intersect do you say yes.

it usually helps to turn the question around - "what if we don't do this?"

end of the world? end of the customer? etc.

same triage as in medicine. once customers get silent, it gets dangerous. as long as they are screaming, they are using your stuff and want more.

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.

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.

Off topic? Not sure.

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.

[1] https://www.intercom.io/

Simplistically on target. Well written & good visuals. Agreeing with @wasd that it feels like half the discussion.

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.

Terrific post.

"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/

This was a fantastic post, and though i havent implemented the service personally i have used it and the discipline shows.

very insightful article.

Well presented work.

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.

Am I wrong? How?

That very much depends. Are you saying no because the requested feature doesn't match your vision, or because it doesn't match what the user needs?

If it's the latter, great! You're on track to a first-rate product.

But most designers make the mistake of going with the former. That's why most products are second-rate.

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?

A related essay recently posted on HN too (not sure how to find the HN comments thread...)

http://firstround.com/article/The-one-cost-engineers-and-pro...

Excellent post! And great example of how to say no at the end.

The best part of this post is definitely "candi_awesome1988@yahoo.co.uk" from "BUT MY COUSIN’S NEIGHBOUR SAID…"

#Accurate #Description of the #Industry

#Great#Job

#Thanks #Team

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.

Reply on news.ycombinator.com