Archive for the ‘clients’ Category

The best clients are the ones who want to make money

Wednesday, March 24th, 2010

To my surprise, I’ve found that clients who truly want to make money are the best clients. I guess at some point I might have worried that such people would be ruthless, but I have not found it so. Clients who want to make money accept my best ideas. Clients who want to make money tend to be honest about what they want. Clients who want to make money tend to stay calm when things are bad – they are less emotional. Clients who want to make money do not sabotage their most successful projects.

However, clients who want to make money are rare. Sad to say, most of the clients I’ve had have been interested in acclaim. Most of my clients have been born into wealth. They grew up rich, so money is not much of a draw for them. What does appeal to them is becoming a little bit famous. During this last decade a certain amount of glamor attached to web startups, so they were drawn in – not so much to get rich, but to become famous. I found that these people lie about their motives – they will hire you and they will tell you they want to make money, but they will focus on areas, like music, which are glamorous but which get way too much investment. They avoid boring industries that might be highly profitable. They stifle money making ideas, and they never give an honest reason for doing so.

For all these reasons, I found this bit interesting:

You see, there are three types of people who want to make money:

- Those who want to be looked up to

These are the people who talk about having expensive cars, living in a big house, or having a hot model girlfriend. I will never do business with these type of people, because they don’t really want money. They are insecure and unsure of themselves and they think that having money is going to change this. The problem is that these people, once they get into a position of power, they will lose their hunger for money. Once they are being looked up to, they will lose their interest in the money and they will fail you.

You can see these people in that they want people to recognize them, they want people to ask their advice, they want people to pay attention to them. Fame and popularity will always be first for these people, and money will take a secondary role.

- Those who want to be comfortable

These people are even more dangerous because there are so many of them. They are poor, they are broke, and all they want is not to be broke. They say that they want to be rich, but once they start making $6000 a month and they can buy all the toys they want, and can have a kid comfortably, they are going to get incredibly lazy. These people are employees masquerading as entreprenuers. They don’t want to be rich, they just don’t want to be poor.

You can recognize these people in that they dream of getting rich and then retiring to some beach to drink cocktails and doing nothing. They work so that they don’t have to work, but that doesn’t work.

- Those who want to have more money

These are the people who see making money as a game, and can’t ever stop. All they want to do is make more and more money, and the toys and the fame are completely incidental to this. Do business with these people, partner with them, because when there is an opportunity, they will go along with it. They will not drop out of the game because they have got enough, and they will not drop out once they make a certain amount.

These are the people who don’t care about their dress or about what car they drive or that people know their name. And these are the people that you do business partnerships with.”

Jason Pelker: web developers should seek retainers

Friday, March 5th, 2010

Jason Pelker makes a good point about the frequency with which projects get underestimated:

90% of the time, the freelancer is going to get screwed on the estimate. My guess is that 9.9% of the time, the client gets screwed (I use the term loosely—as long as the site is completed within the contractual constraints of the project, the client is generally happy). That leaves 0.1% of all estimates that accurately reflected the correct amount of time it took to accomplish the project. Of course, any time valuable should to be taken with a grain of salt because what takes an hour today might take 90 minutes or 45 minutes tomorrow depending on all external factors, not the least of which is distraction.

The bigger point is that clients hate unexpected change, especially a price increase due to underestimation on your part. There are few things most likely to guarantee that you won’t be asked to do second project with a client than raising the cost of your invoice halfway through a project (in fact, most contracts aren’t going to permit this anyway, so again, you’ll likely eat the extra time and costs yourself, anyway).

Using a Retainer to Eliminate Guessing

Herein lies the beauty of the retainer block. You might already be using retainers after the project is complete for tasks like website maintenance or social media marketing (if you’re not, you should—it’s a great way to earn residual income).

I have suggested to a number of clients that they simply pay me a flat monthly fee, but then they worry about the months when not much is changing – why would they want to pay me then? Estimation is a point of pain in the relationship between developers and clients. It is difficult to educate the clients so that they can understand why things cost as much as they do. Its tragic how many times I’ve seen a potential client go with the lowest bidder, knowing full well that the bidder was planning on ripping the client off, because the price was far to low to do what the client actually wanted.

The E*Society: a new website

Sunday, October 4th, 2009

We are pleased to announce that the new E*Society website is now live.

Too much work, and clients who don’t pay

Wednesday, September 9th, 2009

Fellipe Eduardo is complaining about too much work, and clients who do not pay:

I’m really busy. I have a BIG TODO list, many things to study, and less time. Well, you can include some clients that not had paid me (normal here, NORMAL!?! well, that’s comum, person that use and not pay, it’s boring, time doesn’t is money always, sometimes your time is trash to some people). One month without surf, sixmonths without soccer, really this last weeks was being hard.

Time? Watch Lost? Study english? Nope, only work, work, work…

I relate to this. I faced several months of this earlier this year, when the financial crisis hit and suddenly all of my clients were broke.

How much, or how often, should a design idea be discussed?

Monday, April 6th, 2009

One of the tough calls to make, when managing a project, is figuring out how much time should be devoted to talking things over. If you are the manager, there are two mistakes that you might make:

1.) You cut off conversation too soon, before the designer has had a chance to defend their idea, or before the client has had a chance to fully articulate their dissatisfaction, or before your programmer can explain why one option would take more time, and therefore more money. You force a decision to be made before all the facts are in. Possibly you kill the conversation just as people are warming up to what would be a brilliantly creative set of insights, if only you allowed more time.

2.) You allow the conversation to go on too long. After awhile, people begin to repeat the same points they made 4 hours before, or perhaps the day before. Your team begins to fear these conversations, which seem to be endless swamps of unproductive debate. The team craves action, decisions, movement, they want to finally be building something, but instead you keep pushing for more information, another round of opinion gathering.

It is difficult to find the right balance. I suspect we all have our preferences about what we consider the right level of conversation versus action.

Over at 37 Signals they’ve posted an extended chat that Jason Fried and Ryan Singer had about adding a new feature to Basecamp. It is useful to see how such a well known and successful team works through their design issues.

(14:42:41) Jason Fried: What are some of the pushback points we’re anticipating?
(14:43:02) Ryan Singer: “i use milestone attachments for [some crazy custom reason] and this doesn’t apply to me”
(14:43:30) Ryan Singer: possibly: “i want dates on my to-do items, not the lists themselves”
(14:44:12) Ryan Singer: i don’t think the first point is a problem
(14:44:18) Ryan Singer: there are always people who bend the interpretation
(14:44:51) Jason Fried: What if the date thing said “On or before March 14”
(14:44:59) Jason Fried: I think the ridigness of it may be a problem.
(14:45:03) Jason Fried: And this could soften that a bit
(14:45:05) Ryan Singer: a bit long, but i like that idea
(14:45:52) Ryan Singer: hm kinda long
(14:46:08) Ryan Singer: becomes harder to interpret too

I know that in such conversations I tend to defer to the designer, and I tend to want to reach a conclusion quickly. Probably because I’ve been in so many, many meetings where someone else forced the conversation to go on for many more hours than was needed, I tend to play the role of the person who is willing to reach a quick agreement. Ryan Singer reminds me of myself, in this portion of the chat, where he seems willing to go along with the “Due by” language, even though he initially disliked it. He seems eager to reach a final agreement.

(14:46:35) Jason Fried: After seeing this the issue I have is the rigidity of it.
(14:46:42) Jason Fried: This list IS DUE on this date
(14:46:45) Jason Fried: Well, not really
(14:46:57) Jason Fried: It’s part of a milestone that is due on this date.
(14:47:07) Jason Fried: So I’d like to see if we can figure out how to present that reality a bit better
(14:47:15) Ryan Singer: good point
(14:47:18) Ryan Singer: ok
(14:47:41) Jason Fried: how about
(14:47:47) Jason Fried: “Due by 14 February”
(14:47:49) Ryan Singer: “Milestone: 14 February”
(14:48:03) Ryan Singer: nice that Due by is shorter
(14:48:05) Jason Fried: Milestone may work. Ties it into the feature.
(14:48:07) Ryan Singer: shorter is better for this flag
(14:48:12) Ryan Singer: even “Milestone: 10 Feburary” is quite long
(14:48:13) Jason Fried: Due by is less rigid than “Due on”
(14:48:15) Ryan Singer: doesn’t hold together as well
(14:48:16) Ryan Singer: yeah
(14:48:37) Ryan Singer: Due by looks pretty good. screenshot coming

But Jason Fried won’t be rushed into a decision. Instead, he keeps the conversation going, even though Ryan Singer was willing to go along with “Due on”.

(14:55:14) Jason Fried: Due is good, but it’s an opinion 5 years after the fact.
(14:55:20) Jason Fried: That’s why I’m pushing back a bit.
(14:55:30) Jason Fried: We’re not introducing attachments today
(14:55:37) Jason Fried: If we were I’d feel better about it.
(14:56:15) Ryan Singer: i think if we don’t go with “Due..”
(14:56:26) Ryan Singer: it would be better to explore moving the link below the title into the list description area
(14:56:30) Ryan Singer: and actually naming the milestone or something
(14:56:41) Jason Fried: right like…
(14:56:54) Ryan Singer: like “For Ship v1 of the Home Page, 14 Feburary”
(14:56:57) Jason Fried: “This to-do list is attached to a “milestone name” which is due on 14 Feb”
(14:57:23) Jason Fried: I feel like we don’t lose anything with that direction.
(14:57:27) Jason Fried: And we gain clarity

If you read the whole transcript, you can tell these two are getting warmed up as the conversation continues – they are thinking hard about this problem, and they are getting deeper and deeper into the nuances. I relate to this chat quite a bit, as it reminds me of so many of the more productive meetings I’ve been in.

Finally, an hour goes by, and Jason Fried keeps pushing them until they arrive at what they both agree is the perfect answer:

(15:20:08) Jason Fried: In the app we say “Attach to…” so I wonder if we should repeat that here.
(15:20:18) Ryan Singer: i would rather change the language in the other places
(15:20:23) Ryan Singer: “Attached to” looks weird here
(15:20:28) Ryan Singer: and it doesn’t fit with the normal expectations of what an “attachment” is
(15:20:36) Jason Fried: K. We don’t want to change the language elsewhere so we’ll consider that one a no go.
(15:20:39) Jason Fried: Umm…
(15:20:46) Jason Fried: “Related to” works for me.
(15:20:47) Jason Fried: Cause it is.
(15:20:51) Ryan Singer: actually the edit dialog says this:
(15:20:55) Ryan Singer: “Does this list relate to a milestone?”
(15:20:58) Jason Fried: Perfect
(15:20:59) Jason Fried: Done
(15:21:02) Ryan Singer: done

Classic problems that clients make

Wednesday, August 27th, 2008

Darren Hoyt has a great post up about “the empty handed client“:

But what happens when a client has nothing to submit — no photos, no taglines, no logos, no text, no identity? …Obviously a project can begin without all the materials, but it’s far from ideal. In the absence of photos and text, you can help the process along by quizzing the client about their industry, business philosophy or desired audience. In this sense, you’re getting a feel for “content” even without materials.

In response to it, I posted a comment about classic mistakes that clients make. I’m reposting my comment here:

If my client is empty-handed, unsure even of the idea of their site, then I feel the best option is to talk to them, to help them clarify their thoughts. Sometimes I feel like a therapist, listening as the client pours out their hopes and dreams and fears and worries.

We’ve acquired 3 new clients this summer. In all 3 cases, I was brought in at an extremely early phase, before the basic idea of the site was decided. I do not mind sitting in on brainstorming sessions. So long as the client can pay me for the time I spend at meetings, I enjoy helping them avoid mistakes.

For instance, one mistake is the behavior pattern I would describe as “too much brainstorming”. If I’m in meeting with the client for the 3rd time and the meeting is still a pure brainstorming session, I warn the client that they are at risk of wasting a lot of money on simply trying to figure out what they should do. I once saw a substantial fortune wasted on what turned out to be a 2 year long brainstorming session.

I’m sympathetic to the argument that the opposite is also true: it is crazy to risk a vast fortune on an idea that you have not thought about carefully, so a prolonged period of testing the permutations of an idea can certainly be justified if the project seems likely to be huge. So, as I said, I don’t mind sitting in on the brainstorming sessions, so long as the client can pay me. I feel especially helpful when the client suggests something that I know, from previous experience, is a terrible idea. Certain thought patterns are traps, they always fail, yet they are quite common among clients considering their first web project. Among those traps:

1.) If I (the client) build it they will come (also know as, “If I have a clever idea, I won’t need a marketing budget, because the site will get mentioned on TechCrunch/Newsweek/The New York Times”).

2.) Feature-itis: “If I add in all the good features from all the popular sites, then my site will be as popular as all those other sites combined.”

3.) I can/should be all things to all people.

4.) If one person offers a single piece of off-hand, poorly thought-out, casual feedback, we will immediately re-design the entire site to comply with their feedback. And then tomorrow, when someone else offers some casual, poorly thought-out feedback, we will do the same. And then the next day…

5.) Flash is more dazzling than anything that HTML can offer, therefore our whole site should be built in Flash.

6.) Things that move or blink grab my attention, therefore if everything on the page moves or blinks, we will have a truly attention getting site.

7.) Text is boring.

8.) Images are always better than text.

9.) I (the client) am over the age of 35/40/45/50 therefore people will think I’m out-of-date and too old to be starting a web business. I will prove my youthfulness by only using the most bleeding-edge technologies.

10.) Bleeding edge technologies are always more interesting than older technologies such as text.

11.) Users prefer cutting-edge technologies over older technologies such as text.

12.) The more creative/unusual the interface, the more interested people will be.

13.) If my site starts off with a narrow focus, then its prospects for growth will be limited. People will pigeon-hole it and I won’t be able to add new content channels later.

14.) I can spend my money at an unsustainable rate because 6 months from now my site will be bringing in a profit.

15.) I have a lot of money right now, therefore I am a genius web entrepreneur (the money may have come from inheritance, good luck selling a house at the peak of the housing boom, or perhaps thrift at a younger age – none of which confers the business skills needed to run a business, online or off).

I could go on. I’ve seen many mistakes, and I’ve seen a few successes, or, at least, glimpses of successes. When a client comes at me empty-handed, I talk to them until an idea takes shape and seems concrete enough that construction can begin.

I do think it is wise to try to get to something concrete as fast possible (as per 37Signals). It might be impossible to get the whole idea mapped out quickly, but sometimes small parts of it can be made solid. I think it is wise to have the graphic designer try to put visuals on anything that can be agreed upon as unlikely to change.

I also liked an earlier post that you (Darren) wrote, over at Sitepoint, about working toward a single mockup for the front page (rather than offering 3 different versions of the front page). I do think that getting the front page into a concrete form greatly helps getting the whole project solid.