Saying "NO" | Hacker News Reader

Saying "NO"

blog.objectmentor.com

91 pointsfogus31 comments

Four techniques for saying "No" without your client knowing it:

1. Tell them how much something will cost. "Great idea! A live chat widget will cost another $20,000. What do you think?"

2. Make them prioritize. Pick things that you know are more important. "How should we prioritize that change compared to paid subscriptions and the Help system?"

3. Make them remember. Put it on the backlog and don't start it until they ask for it again.

4. Offer them alternatives. We once had a client who wanted native Excel exports of reports. We suggested either CSV exports or HTML table exports, which Excel can read.

(This is more "no" to features than to design decisions, but the principal is similar.)

Great points, #2-4 work in the enterprise world as well.

Absolutely!! The answer is always yes, sometimes qualified. The only no is when you decide you don't want them as a client and you find a reason to not do further work.

This is interesting, the comic makes it kinda cute, but OP's conclusion is exactly the opposite of what I firmly believe. I have learned over the years that the best way to win and keep quality business is to find a way to say "YES".

Buyers of software products, like small children, hear one word more than any other: "no". "No, it can't be done." "No we don't do that." "No, if you did that it would screw up everything else." "No, that's stupid" It doesn't matter if you're right, all that matters is that you're just another person saying "no".

You differentiate yourself from others by giving the exact same answer, but with the word "yes" instead of "no".

"Yes, in order to do that, we'd also want to look at..."

"Yes, let's make it 'pop' using some of the things we bring to the table..."

"Yes, no one even thought about that, and we should now before we get any further into this thing..."

or even the extreme:

"Yes, there's a way to do that. No one has ever done that before, so now is the time for someone to be first..."

As I've told my customers many times, "The answer is always 'Yes'. You may not want to do it once you understand what it will take, but the answer is still 'yes'."

No other word has helped me more to find myself and do my best work for others.

When you say no to some things, you obviously have to think about what to say no to. It helps you prioritize and focus on the most important stuff first. Only when you've stripped down an idea to it's bare minimum can you really say that you understand it.

"Yes, there's a way to do that. No one has ever done that before, so now is the time for someone to be first..."

This sounds dangerous. What one really wants is to add stuff that will be useful to the user and will help him get things done easier. If the client proposes a feature and you say yes because "it's the time for someone to be first", then you are wasting time and effort on something that maybe isn't really necessary.

huh. I guess I am more 'product oriented' than you are, but I tell people 'no' when they want passwords rather than ssh keys to access their out of band console. I imagine it would be different if I was charging by the hour, but I'm not.

But this is part of why I like being a product company. I do my R&D on my own time, without an angry customer if it fails or if I take longer than I thought. "Here" I say, "are the products I've sold to hundreds of other people. I can sell these to you, too." Then I add "If you want something else, suggest it, I might add that as a product as well, then I will sell it to you and others who want it at a low cost, but I'm not going to make it just for you."

(of course, being a product company, if I screw up production, I have many, many angry customers.)

For me, this has largely solved the problem of not estimating correctly and/or managing customer expectations. Here is what I have. you don't like it? Oh, I'm sorry. would you like a refund?

On the other hand, if you can convince them that ssh keys are better than passwords, you might never get to the point where you have to say no.

mostly it's a filter. If you can't make an OpenSSH public key, you should probably not be managing your own VPS, and you should certainly not sign up with me, as all my interfaces are command-line only, and I don't have a nice GUI web control panel like many competitors do, and my support is email-only. go, pay the extra bucks, pay slicehost, and get someone to talk you through it on the phone. I don't charge enough to deal with that sort of thing.

If you wanted to hire me by the hour, that'd be different, but we're talking about people giving me $8/month.

Your line makes more sense now, since you're talking about a different situation from the article. It's a different relationship; since anything you do would have to benefit the many of your users at once to be worthwhile, it makes sense to have users who are similar to each other, ie, to say no to the outliers.

Yeah. a successful product business involves a whole lot more 'no' than a consulting business.

However, I think even when working by the hour, when I charge what I seem to be able to charge lately, I try to say "No, that's outside of my area of competence" because really, they are paying me way too much for me to 'figure it out.'

When it is in my area of competence, I think it's just as important to say "No, I think that's a bad idea, and here's why" - They are paying me silly rates, presumably because I know more than they do about what we are trying to get done; Sure, sometimes you need to translate the technical choice into a business decision and push it up the chain, but sometimes it's a purely technical decision, and within your realm of knowledge, and in that case, I am not doing my job unless I say "Don't do that" when the customer asks me to do something that is clearly incorrect.

In a previous lifetime, I was a graphic designer working at the Field Museum in Chicago. Fresh out of college and my first task was to design a logo for a client. I was eager to please, and I came up with about 10 logo ideas. I showed them to the client and all hell broke loose. They basically wanted a "super" logo that combined all 10 ideas, plus their own ideas, and I found myself in a very awkward situation of trying to figure out how to tell them that's a really bad idea. After the ordeal was done, my boss said "Yeah, next time, only show them two."

The comic referenced at the top of the article was good for a laugh or two: http://theoatmeal.com/comics/design_hell

I think it also illustrates where this article goes wrong. You don't say NO to the client, you say NO to a potential customer before they become the client.

Citing the second part of the comic - Client: "Our last designer was an IDIOT". Then the next appropriate question is - What idiot hired/managed him?

You're about to become the 'last designer'

> You don't say NO to the client, you say NO to a potential customer before they become the client.

This is critical, and it's fairly easy to recognize potential 'problem clients' when there's still time to escape.

Or just make sure you have an escape clause in your contract. Maybe the last designer actually was an idiot. I've found that if you behave like the doctor (in the article) it's often quite easy to steer the course of projects with even very difficult clients.

The part in the comic about the client photoshopping the design a bit seems fine to me, as long as they are just moving components around the screen (switching column locations, etc). I wouldn't blanketly suggest it is bad for the client to do this, since it may be easier to communicate what they want in photoshop than in text.

the comic doesn't suggest that its blanketly bad either.

It was an entertaining comic, but I agreed much more with Uncle Bob, the author of the linked article.

The comic said: "The client has completely forgotten that they hired you, the web designer, to build them a great product."

Whereas I see: "You have forgotten that the client is paying you to build a site which best represents the business in which they are the domain expert."

Just because you're good at X doesn't mean you're good at every (X, a) composition. For example, being a good golfer doesn't imply you'll be able to teach it; being a good singer doesn't imply you'll be able to write music; and being a good domain expert doesn't imply you'll be able to recognize a design that most effectively causes customers to purchase the products/services in your domain.

I wish I could vote this up 100 times. The first rule of requirements gathering: the customer doesn't know what they want. You have to tell them.

While I'm not disagreeing with needing to say no to a client, the moment you figure you know everything they want or more importantly, need, YOU are the one with the problem.

There are numerous examples of programmers/providers figuring that they know what the customer needs. They're called enterprise software.

There's a difference between telling people what they want and telling people that they want something that they don't want. You have to listen to them. But bear in mind that if they

Well, you can't tell them. You have to lead them on a journey that ends with you both finding out.

Obligatory Henry Ford quote: "If I had asked people what they wanted, they would have said faster horses."

I think designers have this problem since anyone can have opinions about design. It's also hard to argue objectively why one design should be better than another, since design is subjective (for most parts).

Maybe the design process should be more "Google like" and include more design patterns that are field tested. The basic principle should be to use data to back up claims instead of subjective arguments. An example, if the customer wants an "intro page", then point to a "anti pattern" that argues against intro pages. Etc.

Couldn't you just defer to functionality when pressed on a design decision?

If you can't justify your decisions then I'd say having to humor the client is fair-game.

Design patterns are fine, but a bit theoretical for most people. Everyone will say "sure, that's true in general, but I think we'll get it right, because of blah blah blah..." I much prefer A/B testing each individual change and showing the client how many of their customers think something is an anti-pattern.

If you find yourself saying no a lot you need new clients, or a new line of work. Being a designer is hard, and so is finding good clients.

As an aside -- nightmare clients tend to crop up more on projects with thin margins. If you are taking on a new client, make sure the margins are not thin.

The problem with his rationale regarding the very comic he's talking about, is that every body and their mothers think they got a clue about design, and that they know what is beautiful better than you . Most of us think that way, and that's what makes designing web sites such a painful job

Part of this is just diplomacy. Don't say "No," just figure out what results they want, not just what actions they've asked you to take;

http://www.byrnehobart.com/blog/how-not-to-say-no-to-a-clien...

I thought this was a review of http://islostarepeat.com

Reply on news.ycombinator.com