When a few weeks ago I requested on Teamwork's mailing list and on the forum for some feedback, I had no idea whether I would get any answer. Actually, the first day I got only one answer, which ran more or less “We don’t use it and we are happy about it”. So I wondered whether it was a good idea. But after a few days, feedback started coming in, ranging between fans saying that it is perfect as it is, to constructive criticism. And it keeps coming and coming. Thanks!
You know why it took a few days to start? Because the feedback we get is highly structured: people are sending us detailed excel charts with features, issues, and comparisons, discussed in group meetings. Users of structured software have refined interactions :-)

Among all this feedback, my dear friend Massimo Iacolare, a new born micro-ISV entrepreneur (when is your website coming up Massimo?), pointed to me to these links:

http://www.shmula.com/158/focus-on-the-customer
http://37signals.com/svn/archives2/instore_good_or_athome_good.php

where it is briefly stated the need of "simple" and very specialized software, and that features look good in stores but not when using the apps.

Well, what I can say is that Teamwork is surely good at home; for the good at the store, we’re working on it: we’re "Crossing the chasm"" (for a contextual perspective see the beautiful "Eric Sink on the Business of Software").

Its good at home because first of all the model is good. Differences in interface reflect also differences in articulation of the underlying model; and my claim is that our competitors (in particular those reviewed in the previous posts) have simplistic models. On the 37signals post I found this brutal comment:

Sebhelyesfarku 06 Sep 06
I like feature packed products. I’m not retarded like average consumers.

Well, this is sort of funny, but I am not saying this. A user evaluating work management software can easily confuse the fact that we have to render a complex model, with feature bloating. The fact that Teamwork’s interface is more complex then that of some of its supposed competitors is not due to feature bloat, but to the articulation of the concepts involved. Actually, our powerful interfaces are a sign of health.

Let’s consider security problems for even a medium-small company, say with a hundred employees. I bet that no one can find a single example of such a company where everyone can see all the information floating in the company in the IT structure. But more: there will always be local exceptions to a simple role-based security model, because there will always turn up a particular project that has its own security

Teamwork 2 had a role based security model, further refined by “areas”, which were a way of completely separating say departments, in which the roles could be distributed. There could be users having different roles in different areas. But, as in all fundamentally role-based models, once you had a role, you would have it in the entire area; so once you could read a task in say production, you cold read all tasks in production. So users complained again and again that they wanted a more fine grained security, as fine grained as a single task. And notice that this has to scale with respect to the numbers of projects, users and roles, for example when you do a search, so you have to express this in HQL (or equivalently, in SQL) in order to performant instead of navigating the objects, and you have to comply to the security model, which is non trivial. But for version 3, by leveraging Roberto’s intuition of giving a role weight to assignments, we got all we had with version 2, plus fine grained security; and teams and structured work for free, too.

All competitors I’ve seen so far don’t even reach Teamwork 2’s security model. And any (Team) work management application that doesn’t solve the case of exceptions, simply cannot work. Full stop.

So you must have a complex model, covering 100% of cases. What distinguishes a good model from a bad one is how it covers limit cases. Assuming that your model covers all above, and more, then we can talk about the interface ergonomics; but applications with a wrong model, will not fit the real world, however pretty their interface may be.

Also the reasoning of some competitors for separating applications is leaky. How could you have distinct applications for security and work management? And users are supposed to jump from one application to the other? Not very user friendly.

Interfaces for such applications cannot be simple; but they can be comfortable. And in Teamwork we have and are working hard on this (a page dedicated to “comfort” features of Teamwork 3 will appear soon on the web site). From release 3.0.0 to 3.0.6 the interface has been improved in hundreds of places, but the model in unchanged.
We are working today on showing how to use Teamwork to support SCRUM methodology; even if we studied SCRUM last week, we are almost done implementing it and the model is fully compatible with it.

Sorry for the long post, but I hope our ideas are clearer now. Pietro