“Bad customers will drain you of passion. Really bad customers will drain you of both passion and profits. Unfortunately, most bad customers will degenerate into really bad customers if you don’t do something about it.” -Dharmesh Shah

Very few people enjoy firing anyone, much less a longstanding client. I know it’s not my cup of tea. But there is no doubt that having the wrong clients can quickly sink a company and put all its clients in a bad position. Here is an exercise to help you know which clients are winners and which may be bleeding you. (I recommend doing this in a spreadsheet.)

1. Make a list of your engagements over the past year
2. Beside each engagement enter:
   1. Revenue generated
   2. Total profit (total profit = revenue – ((billable + non-billable hours) * cost per hour))
   3. Profit margin
   4. On a scale of 1-10, how much you enjoyed it
   5. Whether this client has been a one-time buyer, repeat buyer, or better yet, an advocate (refers work to you)
3. Now sort the customers by each of the columns

You may be surprised at what you discover. Often I find I favor clients based on how much revenue they produce and how much I enjoy working with them. But profit margin is critical, as well as the amount of repeat work they bring or refer. If you’d like some help measuring your profit and profit margin, stay tuned.

Have you ever been to the grocery store, went to aisle 7 where the baking powder always is, but couldn’t find it? Anywhere? That can be very irritating. If the store never had baking powder or at least gave me some indication of where it had moved (if it moved), the irritation would lessen significantly.

It turns out the baking powder had been moved to the other end of the isle, but the big “Baking Powder” hadn’t been moved with it. More commonly, the store is just plain out of something, but I have no way of knowing that so I waste my time searching.

Consistency puts customers in control of their experience. Do I want a quick, cheap meal? I go to Taco Bell. Do I want something nice? I go to the Acropolis. When customers are in control they at ease.

Back to the grocery store: I don’t expect you to carry endless varieties of specialty breads (which I enjoy). I don’t expect you to have everything you carry in all the time (although it would be nice). But would you at least keep things in the same place so I can know when something is out of stock?

I’m left asking myself, are we providing consistency to our customers?

Are we there yet?

How do you make time for a project that doesn’t pay and doesn’t have a client asking when it will be finished when you have lots of paying client projects? Right now we’re in the process of bootstrapping our first web application, and let me tell you, it isn’t easy to make time and retain momentum.

In the past we’ve worked on (and never launched) two other web applications. We launch client projects on time every month though. So what gives? Here are a few of the lessons from our unshipped web applications:

1. When there is no “client”, it’s easy to want to add “just this one more thing” before shipping. Or even more likely, a whole laundry list of additional features that seem “essential” to the product being successful. A list that never ends.
2. When there is no “client”, there is no deadline and no one bugging you wanting to know “are we there yet?”.

So in short, the equation looks something like this:

Infinitely flexible scope + infinitely flexible timeline = a product that never ships

So what is the solution? We haven’t launched yet, so I can’t claim to be an expert, but here are a few things that are helping us get there.

Decide what’s in (and what’s out)

Follow your standard procedure for locking in scope like you would on any other client project. For us, that meant producing a detailed estimate of exactly what we would do before launch. The important part of this exercise is that it forced us to say what we wouldn’t do before launch.

Decide when you’ll launch

In our case, we’ve been using this product internally since February, so most of the work towards launch relates to polishing and preparing the application to work for multiple subscribers (it’s a subscription web application). Choose a date you’d like to have it ready for public launch or at least for a private, invite-only beta.

Next, figure out how many hours you can realistically work on the application between now and the launch date.

Face reality

Here’s where it’s critical to apply discipline. Compare the hours you have before launch to the hours you expect it will take to complete the scope you’ve outlined. If you’re good at estimating time required and half as excited about launching as we are, there’s a good chance your “hours to launch” estimate will greatly exceed your “available hours before launch”. Consider it a blessing! As Mike McDerment of Freshbooks says, you can’t take a feature away once you give it to your customers. Better to take anything that isn’t absolutely essential out now.

We went through this process twice and each time cut the scope about in half.

How we’re doing

We now have about 25% of our estimated scope time left, but we’ve passed our target private beta launch date by a couple of weeks. That means that we had a lot less time available (or made a lot less time available) than we expected. The next step is to begin setting aside time proactively each week just like we do for client projects. I’ll keep you posted!

Shipping is a feature. A really important feature. Your product must have it. – Joel Spolsky

In our development process, we typically write brief narratives describing how users will interact with the website or application (user stories), then move right into building a working prototype. But this week I finished up a set of wireframes (a static prototype) to complement the narratives for a project.

I learned at least one important lesson: include only the most necessary details in the prototype at each stage of the development process, focused exclusively on the decisions at hand. Don’t hesitate to discuss other decisions as they come up, but don’t put them into the working model. Why? Additional detail distracts from the primary decisions and wastes time better spent at later stages.

In the wireframe/narrative stage, the critical things to decide are:

1. What general things display on a particular view
2. How those things work

As I look back I see a lot of copy I added that doesn’t matter at this stage. Instead, I should have used a placeholder that noted what would be there (“Benefits list here”). Fortunately, the customer was able to focus on the decisions at hand, but I wouldn’t blame him if he fixated on the choice of copy.

“There is nothing so useless as doing efficiently that which should not be done at all.” – Peter Drucker

Deep down we all know these aren’t true, but we can still catch ourselves believing them when it’s convenient. After all, if they were true, it would make our jobs a lot easier. Or, more likely, we would be out of a job.

1. If we build it, they will come.
2. If we build it, they will continue to come.
3. If they come, they will take action.

Many campaigns are unwittingly built on all three of these assumptions, on the part of the agency, the customer/sponsor, or both parties.

The underlying problem is quite simple: a myopic focus on what the customer/sponsor wants. What the customer wants (what is perceived as valuable to the customer) should only be front and center when the customer is also the audience for the project (e.g. an intranet). If we want “them” to come, we’d better deliver something that “they” want and continue to do so.

Once we agree to focus on value for the audience, there are two roads to take to determine the focus (the value and the audience).

1. Find an audience that values what the customer already provides
2. Discover what is valuable to the audience the customer already serves

Often the road to take is a combination of both, a re-alignment of value and audience.

Oddly enough, when we stop focusing on what the customer wants we can start serving the customer’s best interests.