Lessons from launch: help us learn how you track time
37signals.com
37signals.com
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.
>...Plain and simple, this is why time tracking isn’t in the initial release of the all new Basecamp. We simply don’t understand it well enough.
huh?