How to say no

I think it's also important to document no's (and yes's). The obvious place for that would be the bug tracker.<p>Documenting a "no" does several good things: 1. It avoids repetition 2. I think it creates a certain sense of accomplishment for the user you're responding to? He's come forward with a suggestion and the resulting dialogue has left an <i>artifact</i>, which can be useful as per point #1.<p>It's also important to document "not now"'s for the same reasons above. I'd just make an entry with a very low priority. (oh damn I'm stating the obvious here).

I've noticed a pattern with the 37signals folks.<p>How to profit on the internet: Make something people want and charge.<p>How to say no: Explain yourself, be honest, and just say no.<p>I guess it just has to do with what you leave out.

Some horrible manager in a previous career must have really tortured Jason by wasting time with Gantt charts.<p>Gantt charts are probably not all that useful for a group of 3 YC founders living in an apartment paid for with pg's spare change, but when you're got multiple departments and companies on a deadline, they can be very valuable. Knowing how your bit fits in and who's doing what this week are valuable things.

Another opinion <a href="http://www.whybasecampsux.org/" rel="nofollow">http://www.whybasecampsux.org/</a>, this is mostly about Basecamp saying "no".