4 ms·

Lessons from launch: help us learn how you track time

25 points by hawke 15y ago

Pewpewarrows 15y ago
I don't understand the comments from people on the blog wanting them to rush this feature and get it in ASAP. Like they mentioned, you still have Basecamp Classic. There's nothing forcing you to move to the new Basecamp before they take the time to get time-tracking right.
- sudonim 15y ago
  I found that surprising too. 37signals presumably are supporting both products side by side to prevent people from having this reaction. Im not sure if those people are yelling loud to make sure time tracking gets in to Basecamp Next or because there are just rude and obnoxious people on the internet.
ROFISH 15y ago
Why the focus on time tracking? There are plenty of other Basecamp features I'm sure other people want to be ported too. For example, my company relies on the Textile writeboards to provide pretty tables and lists. It was much disheartening to see our carefully constructed pages get devoured into an ugly mess of unversioned code when moving a project to the new system.
xbryanx 15y ago
I appreciate this post's lack of snark. It's nice to see them responding to a need that they (37 signals) obviously think is useless, but that their customers think is important. That's a hard line to draw when creating a tool.
cantastoria 15y ago
>...we didn’t anticipate such a strong visceral “no time tracking is a deal breaker” reaction. This was definitely a blind spot for us. >...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?
breckinloggins 15y ago
> 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.

25 points by hawke 15y ago

I don't understand the comments from people on the blog wanting them to rush this feature and get it in ASAP. Like they mentioned, you still have Basecamp Classic. There's nothing forcing you to move to the new Basecamp before they take the time to get time-tracking right.

sudonim 15y ago
I found that surprising too. 37signals presumably are supporting both products side by side to prevent people from having this reaction. Im not sure if those people are yelling loud to make sure time tracking gets in to Basecamp Next or because there are just rude and obnoxious people on the internet.

ROFISH 15y ago

Why the focus on time tracking? There are plenty of other Basecamp features I'm sure other people want to be ported too. For example, my company relies on the Textile writeboards to provide pretty tables and lists. It was much disheartening to see our carefully constructed pages get devoured into an ugly mess of unversioned code when moving a project to the new system.

xbryanx 15y ago

I appreciate this post's lack of snark. It's nice to see them responding to a need that they (37 signals) obviously think is useless, but that their customers think is important. That's a hard line to draw when creating a tool.

cantastoria 15y ago

>...we didn’t anticipate such a strong visceral “no time tracking is a deal breaker” reaction. This was definitely a blind spot for us. >...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?

breckinloggins 15y ago

> 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.