It seems in our oh-so politically correct times, that we’ve been a little brainwashed to always compromise. Find the middle ground, we’re told. Let no-one be unhappy. If one person wants one thing and another wants something different, the quick conclusion seems to be to do just a little of both, placating everyone and avoiding confrontation.

Trouble is, the quick conclusion often isn’t the right one. Especially when you’re working in a startup (where up is down and down is up, and many of the other laws of physics just don’t seem to apply).

I wouldn’t suggest you run around being completely stubborn about everything (especially when dealing with your boss). However, there are a couple key places where compromise can actually be a mistake for a startup. This is particularly true for the leaders of the company, who are responsible for setting direction and often for arbitrating disagreements that might otherwise play out as compromises (as people will naturally want to do).

When you’ve got several of your people disagreeing about a particular issue, be wary of compromising just to placate them and avoid a fight. Don’t be scared to choose a side and completely piss one of them off (if it’s the right decision for the company). If they’re mature enough, they may not agree with you but they’ll respect that you’re doing what you believe is best for the company. If not, they’ll eventually quit and you’ll be rid of them.

One obvious example is quality. The age-old compromise with quality is that if we do less testing, we can ship sooner, make a little money, and fix it later. I would argue that this is never a good idea. You ship when you’re done. That means when you’re absolutely comfortable with the quality of your product.

The “first mover” advantage has been disproved countless times, particularly on the Web where switching costs are near zero. You’re far better off toughing it out and being completely uncompromising when it comes to quality – even if that means someone else ships first. Don’t race to the finish line, build the best damn product you can. That’s what will get attention (and free PR as people talk-it-up).

Another time you should avoid compromise is during feature selection (and design). Big companies can afford to pack everything into their products. They have a lot of time and money to throw at a problem. They also have large existing customer bases that they have to satisfy on an on-going basis, so they are forced into design-compromise situations all the time.

That’s how products from big companies end up being bloated, confusing and sometimes have lower overall quality than their smaller, leaner, more focused counter parts.

When you’re building a product that has to serve everyone, you inevitably also make it somewhat less applicable to everyone at the same time. General-purpose-ness is inversely related to relevance. When you’re just starting out (with no existing customer base), the only thing that is going to make you successful is if you are significantly and obviously better at something than your big-player competition – even if you actually do less things.

Here’s a tangible example. My company, Devshop, is making a project management tool just for software teams. The goal is to absolutely nail the problem of late software. That’s it, in a sentence. Over the last year, I’vehad several people tell me that I should also have time-tracking (a.k.atimesheets) built-in. After all, lots of companies use timesheets.

Normally, when enough people give me a piece of consistent feedback about something, I listen. In this case, I have absolutely refused to include this in the product even though it would have been an easy compromise that may have made a few people close to me happier.

My belief is that because time tracking is off the roadmap and not directly related to the mission, it has no place in the product. I believe that the only way that Devshop will get any kind of attention is if it is absolutely focused on solving that original (and critical) problem of late software, and everything else is just noise.

In this case, I have absolutely refused to include this in the product even though it would have been an easy compromise that may have made a few people close to me happier. My belief is that because time tracking is off the roadmap and not directly related to the mission, it has no place in the product. I believe that the only way that Devshop will get any kind of attention is if it is absolutely focused on solving that original (and critical) problem of late software, and everything else is just noise.

Do it once or twice and no one may notice. But eventually it will catch up with you as your product becomes a collection of compromises that does nothing exceptionally better than any other product, and now has become an also-ran, with no following, no attention, no PR, and no sales.

Craig