Captain’s log, stardate 20161206
Sent by Jonathan Stark on December 6th, 2016
Below are some questions I got back re the Seinfeld clip of the indecisive carpenter. I’ll respond to each in-line.
> “So, clients should not be involved?”
Clients should be involved, sometimes heavily. Lots of regular communication is a good thing. But the communication shouldn’t be them telling you how to do your job. It should be them providing and/or clarifying the business cases for various requests. This sort of thing happens to me constantly:
client: “Can you please paste this snippet of code into every page on the marketing site?”
me: “Sure. Why do we need it?”
client: “It tracks conversions by location.”
me: “We have Google Analytics on the site already, which does that. Will that work for you?”
client: “Oh, sweet. Yeah, never mind. Thanks!”
In this exchange, the client asked me to paste a snippet of code, but that that’s not what he wanted. He wanted a particular bit of business intelligence so he could make marketing decisions. He was trying to be helpful by doing some homework and providing me with one possible solution. It just wasn’t the best solution.
Remember: The client is an expert at what they do, you are an expert at what you do. In your regular project communications, strive to limit the exchange to things about which your client is an expert. Every time they instruct you to do something very specific, ask them what the business case is for the change.
NOTE TO DESIGNERS: Remember that design is how it works, not how it looks. Your work is meant to achieve an outcome. And in a business context, the stated outcome is rarely “to appeal to the aesthetics of the CEO”. Define the desired outcome before you start working and push back against any requested changes that don’t serve the stated goal. Anything else threatens the success of the project.
> “I just do my job without asking do they like or not?”
Yes. It’s not a question of them liking your work, it’s a question of making demonstrable progress toward a desired outcome. You’re either doing it or not. Instead of asking “Do you like it?” in a status review meeting, ask “Are you happy with the progress?” This is why it’s critical to have a Why Conversation up-front. Without it, you’re flying blind.
> “But what if I do a scope of work for 3 days and then they say: ’I don’t like it, change it’?”
Tactfully remind the client that whether he or she “likes” the output is irrelevant. The only thing that matters is making progress toward the stated goal of the project. This is a key point because clients tend to forget the stated goals over the course of a long project. You owe it to them to keep them on track. Getting distracted by irrelevant input can jeopardize their success.
> “When the carpenter went off and made all the decisions himself, it turned out to be way too much.”
Agreed. I didn’t see that whole Seinfeld episode but the result clearly indicates that the carpenter did not have a Why Conversation with Jerry before starting the project.
> “I’ve had quite a few clients come back and say ’I want this button to be red’, or ’I want this button to be bigger’. Should I just do as they say or try to push back?”
The proper response to a question like this is, “How will that help us achieve the stated goals?” If they can make a convincing case for the change, just do it. If they can’t, tell them that you’ll log the request and once the project is complete you can consider it for a v2 if they still feel it’s important.
Feel free to send in more questions!