> How and why... I can't comment on the "how", but the "why" is easier. 37signals is a product company, and a modern one at that. By "modern" I mean that the

> How and why... I can't comment on the "how", but the "why" is easier. 37signals is a product company, and a modern one at that. By "modern" I mean that they do things differently from traditional product companies. Not tracking time probably works well for 37signals and many other nimble organizations. But it doesn't work for everyone. When I picture a 37signals customer, I tend to picture a company... well... like 37signals. But Basecamp has a large user base. And it is not homogenous. Large corporations, smaller traditional companies, freelancers, and consultants all use your product. Anyone who bills by the hour needs time tracking. Anyone who is accountable to a "cost center" needs time tracking. People who want to improve estimation in a project over time need time tracking. Skunkworks "rebel" projects embedded in a larger organization still have to give cost reports to their superiors. They need time tracking. Do I need to go on? I won't fault 37signals for omitting a feature they did not understand, but they shouldn't have been blindsided by it. It demonstrates an underestimation of the diversity of their users. Okay, maybe I will add my thoughts on the "how": You're 37signals. Don't you like to keep things simple? Why not start with two input fields on every task: 1. Estimated time 2. Actual time Roll these up in any "aggregate" view of more than one task. A little "estimate vs actual" sparkline would be cool, too. Provide deeper access via API so the data can be integrated with existing tools the client has. My opinion is that would be better than nothing. And it would stay out of the way.