The 37signals ethos of having an opinion and saying no a lot creates wonderful experiences and products for users who are new to a certain field. For someone who is new to project management, for example, the fancy programs with every feature and option are confusing and scary. Products like Basecamp are beautiful for these users.
As users gain more experience, their needs become slightly more complex. They start to understand the simple product completely, and then they have the cognitive ability to understand more fancy bells 'n' whistles. For users who have been doing project management for a long time with any software product, they will have a long list of things that they know -- from experience! -- that they need.
That is why there's a market for simple and there's a market for full-featured. Both are discrete markets, usually. Obviously every software designer strives for "power made easy" -- it seems easy at first, but there is power under the hood when you need it.
I wonder if there is room for a product that grows with you?
What if there were a product that is exposed to you first in the simplest form. It's clean, elegant and simple. Easy and not intimidating to use.
As you use the product, your needs begin to increase and suddenly you need a new feature. As it turns out, the product actually supports this feature and so you turn it on. Now, you are turning on feature X, not feature package premium--just feature X.
In fact, the product actually has several additional features and functionality that can be enabled and disabled one at a time. None of these "extra" features cost "extra". They are all included in the base price of the package.
What if your product has a training module, where users can be guided through test use case scenarios that expose and demonstrate new feature modules. And what if we make it so that when you enable a new feature on the product, that feature only shows up to users who have completed the training guide for the new feature in the module.
In other words, in order for any specific extra feature to show up it needs to be:
1) Turned on by the administrator.
2) Flagged as "trained" on a per agent basis.
This way the base product has easy accessibility and additional features can be exposed gradually not taking effect for an agent until they have gone through the training to learn how to use it.
I'm going to go ahead and answer your question: I don't know if there's room for a product that grows with you, but I don't think such products are feasible.
I worked with a large personal finance software company at a time when they were enraptured with re-use. They had visions of doing things like sharing contact and project management modules across customer relationship management (CRM) and invoicing applications. I had a large stake in making sure they thought through these issues clearly, as the very form of the product I was leading the creation of was at stake.
We think about an invoice or a project or a task or a contact as something that's fairly self-evident, but they're not. More precisely, an application needs to create a model of these things, and that model is a useful simplification.
It is likely that "a product that grows with you" is one that fundamentally changes the model of the entities that your product works with. So, for example, a simple invoicing tool might have a client or a customer field, and that works in let's say ninety-five percent of the cases, but for some people, they want a full-on contact manager where you need to know that an invoice is for ABC Co., that the client contact is John Smith, that invoices should be sent to payables@abcco.example.com. Pretty soon you're going down the contact management slash engagement business process analysis rabbit hole.
And going down that rabbit hole is fine, but you're never going to be able to create 1. a simple, novice-friendly view of that industrial strength application that 2. stores data in a way that is semantically correct so that 3. when the user decides to upgrade from Invoicr Lite to Invoicr Enterprise Platinum their data isn't a nightmarish state.
This is one of the reasons why it took Windows user experience so long to approach anything even remotely as pleasant as the Mac: Windows had to support a much — let us say out of politeness — richer model computing than the Mac did. The Mac user was never exposed to certain details — like whether your filesystem was "really" hierarchical (the original Mac didn't have this feature) — but instead shown a simplified view of the world that Apple and developers had the freedom (and obligation) to implement by any means necessary.
That is how emacs has felt to me. There was a large amount of upfront learning, more than there probably should be for this example to make perfect sense, but after a few months with it I am able to do the basics pretty well. Every time I wish I could do something in emacs, a little bit of googling shows that there is a key binding for exactly what I want. So bit by bit, emacs is going from a weird text editor that does the basics into something way more useful than I thought.
/noob rant about the magic, magic!, of using emacs.
I think you are on track for an interesting idea but forcing training is certainly not the way to do it. I hate doing training in any software. UI/UX is all about keeping things intuitive/similar so new users pick it up with ease so there is no training required. Training is a buzz kill.
However, I think a piece of software that evolves is what most people intend when they start with a minimum viable product. What you don't see too often are benchmarks to "grade" users and automatically move them up to more advanced features. I'd have to think more about it to see how it could be implemented and how beneficial it would be but I think its interesting none the less. It would be similar to a game in which you "unlock" certain maps/levels/etc.
"UI/UX is all about keeping things intuitive/similar so new users pick it up with ease so there is no training required. "
Thats a fine objective for _some_ software. Twitter clients should be like that, the majority of what email clients or web browsers can be like that.
It's possible (probable?) that fully featured project management software can't be like that. There's too much external system level understanding required to expose everything the user needs to know about how and why to use the system in optimal ways to be able to encode it all in beautiful UX/UI.
Try and work out, as an exercise, how you design a UX/UI for a git client that'll allow a cvs or subversion user to "pick it up with ease". Some things "just don't work that way", and I'm reasonably sure project management, at least at medium and large scale, require user training (whether formal or self-trained-via-google, or through many iterations of trial and error).
Indeed, there's a balance to strike between retraining and familiarity.
_The Humane Interface_ discusses the balance between delivering something with "optimal usability" from an objective and scientifically validated standpoint vs. delivering a product the target audience can quickly familiarize themselves with and transfer their existing domain knowledge to.
So, while the Canon Cat may be a revolution in word processors, the average user will do better with something similar to Microsoft Word because they know it and can apply what they already know rather than learn a whole new way of word processing.
What about when the alternative to the software also requires training? For example, draftsmen didn't intuitively know how to create usable architectural or machine drawings; is it so horrible that today they have to be trained in the use of CAD software, instead of being trained in pencil and pen drafting?
If you're performing a complicated task, it's reasonable to ask that the software not make the task harder, but it's also reasonable to expect to have to learn how to use a new tool.
I suspect that project management (at least for some large projects) may be such a problem domain, where the tools are unavoidably complex.
The spreadsheet is a great example of something that is ridiculously intuitive when you first use it, and grows with you. From inserting values in cells, to formulae and UI features like freezing, to advanced constructs like pivot tables, and ultimately to programming.
I would call that a smooth UX trajectory from novice to expert.
The training is not meant to be patronizing, it's meant to insure that your users can use the feature properly. Also, there is to levels of user here--the admin user (who is in control of the feature) and the agent users (the agents who use the product to operate). The forced training is at the agent user level.
From experience, I think mandatory training is necessary otherwise you end up with your agents using fields as they _think_ they should be used instead of how they should be used.
this approach was tried by Gnome's Nautilus for a while, a few years back... and it failed miserably. It feels to me like a bad excuse for not designing a good UI in the first place...
Word's ribbon is a pretty good attempt at hiding the complexities of the program. I think that approach is better than a program which is always changing.
evrsoft 1st page [http://www.evrsoft.com/] implemented this pretty well. they have four modes, each of which shows a greater range of tools and options, but it's fully under your control which mode you're working in.
When considering product development it may help to focus on an early adopter group [1]. Use that to grow and add more features. Having a group of early adopters (happy test subject) is crucial.
"So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback."[2]
While you could argue that some products appeal to certain segments (unexperienced users vs more experienced users), there still is no reason why you couldn't use that customer group and refine your existing product, create a secondary product (addition), or a new one entirely focused to that 'other' customer group. In this example, a new product focused to the more experienced user might be easier as that is exactly who you focus on for an early adopter group.
On a slight tangent, there has been much furore over Final Cut Pro X because a lot of "Pro" features has been ditched in favour of usability improvements. David Pogue said that he managed to get a home project out in short order, but the people who actually do this for a living are rather unhappy because their workflows have been broken.
It seems that Pro Am and Pro are separate market segments that marketeers have difficulty positioning.
The reason is that people fancy themselves as being more competent than they actually are, and would go out and buy the souped up version that has features they could not possibly need (like 12 simulataneous cameras) and look like a space shuttle cockpit instead of something simpler.
This is an interesting problem. I wonder what could be done about this? You'd virtually be forced to name the actual professional edition as something rather staid, like "Final Cut Classic" in order to properly sell your product.
Very good point, we moved from Unfuddle to Fogbugz exactly because of this. We grew out of Unfuddle (they are kind of following 37Signals about simplicity choice) .
I followed the same path of Unfuddle to FB. I found Unfuddle to be an uninspired clone of Trac, however, which is exactly why I chose it -- I had used Trac and wanted a hosted version of that.
I liked unfuddle and assumed they would add features, however after 1 year of usage it was clear that they were not big fan of features and didn't add anything useful (at least anything useful for us). Which always amazes me, how a startup can spend a year without adding any good features or just add 1-2 minor features and try to get away with it...
Adding features is hard work, risky, expensive, and sometimes counterproductive (!).
It's hard work, because you need to change an existing, working piece of software with new code, and deploy it. Including possible database changes.
It's risky. Deploying a new version of your software might introduce nasty bugs, huge usability problems, or you might change the way things worked before, actually displeasing a lot of users.
It's expensive. Programmers aren't cheap. Then you need testing, QA, ticket triage... all things that cost a lot of time, and money.
Counterproductive. Your new features might only benefit a tiny portion of your userbase, and might not attract new customers. They might break your existing model. And so on.
Once you've reached a good feature set, doing continuous development is more of a life choice, rather than a business decision that makes sense.
Perhaps the OP developed a core competency in project management, which requires a different app. Spool implies that it is hard to have an app that can meet the needs of both core and ring users, since they have different needs.
It's not novice vs expert in the app that matters, but novice vs expert in the domain area.
I am not so sure. It's easy to write a program that is easy to use and has very few features. It's very easy to bloat a program with so many UI elements that it becomes unusable. On the other hand, it's _very_ hard to write a program that has a simple UI, and yet has a lot of features. This comes from programming experience... And it's our daily struggle with Apollo.
If it would be true that 'beginner' and 'expert' are best served by discrete solutions, my mother would use a different MacOS than i do. But she is very happy with the same software than probably you too.
The ultimate goal for software design is to increase features and simply the interface at the same time. Thats where 37signals fails. Keeping it simple is only half of the battle.
Today Basecamp is 7 years old. Signups are stronger than ever.
Whenever we survey customers asking them what they love most about Basecamp, the top response by a mile is: it's simple, easy, and their co-workers and clients actually use it. It's not multiple choice either - the words "simple" "easy" "intuitive" show up more than any others in the open ended textarea.
We've made Basecamp a lot better over the years. Some people still ask for more. Others say it's too complicated and they wish it was even simpler.
Software development is a challenge. Everyone wants something different. So you do what you can to thread the needle and make as many of the right customers as happy as possible. Not everyone is the right customer.
It sucks to lose a customer because we did something wrong, but it's OK to lose a customer if we just aren't the right fit anymore. People move on from all sorts of things. Clothes, houses, cars, jobs, relationships... Why not software? As circumstances change, one product may not fit someone forever. That's OK as long as it fits plenty of other people at the same time.
Some customers stick with you forever. Others come and go. Many who go come back after trying other tools that promise them more but that no one actually used. In the end, the tool that actually gets used is the one that's the right fit for someone. It's really really hard to get people to actually use things.
We've found that the simplest stuff is what actually gets used. It's why email is still the world's most popular project management tool.
It's a good point if you don't think that you _can_ develop feature-rich software and still keep the interface nice and easy.
It's an excuse if you believe that you _can_...
I think you need to walk the line on this one. That's what we do with Apollo... We managed to include a CRM in there, and still keep the UI very simple.
Then perhaps 37signals need to make exporting existing Basecamp data for easy importing into the "next step up" products. As far as I know they only provided a raw XML data dump.
Agreed. It's really up to those other products to develop import routines for BC data. Wordstar didn't develop 'save as MS Word' functionality, but MS did WS imports just fine.
You have it backwards: tools that want to be the next step in the chain should make it trivial to import Basecamp data. 37signals has done their part by making it easy to get data out.
That may be, but when the provider of said simple solution is simultaneously ratcheting up the price, people who are using the product will bleed over into other products.
It seems to me that the people who are attracted to the most basic set of features will also have the least amount of pain shifting to a new product while having the lowest price elasticity.
Apple does OK charging high prices for simple products. The target market is prosumers - people who pay a bit more for a product that is (or is marketed as) a joy to use.
Most software engineers are prosumers, so you either target them or the enterprise.
Now, "onion" products are better - they let the user grow from a simple base. But a simple product is a lot easier to make, which frees up resources for marketing or other products.
Apple doesn't typically raise prices - usually same price point and better hardware, more features, etc. The OP was taking issue with coming back to Basecamp and having to pay more than he used to, without getting any new substantive features.
If Apple did this - raised their prices while also taking a 'less is more' approach wrt features, many of their most ardent supporters would eventually defect.
re: basecamp - I knew several orgs in 2008-2009 that had paid versions of it. none of them liked it, but used it because it was something, and they were paying for it so it must be OK. I suspect that over time, BC will bleed enough paying users to the point where they'll reinvigorate the team and start adding more value. Then again, they may just raise the price and ride out their name brand making boatload of money for many more years to come.
Apple products are not simple. Apple products are extremely complex. Their genius is in making extremely complex things usable, so much so that they seem simple.
If I make the world's simplest todo list, I have not made an Apple product. I have made a toy. If I make a phone into a tablet computer that is immediately understandable to a child, I have made an Apple product.
"Apple" = "genius" (OP) + prosumers love Apple (above)
Can't we have a bit of cooling down on this Apple fan thing? The first and last Apple computer I booted myself did crash hard and there was no way to recover, go into BIOS, "hack" it if you will. Ok it was 10 years ago but still, when I see an Iphone owner I ask: show me your files, your music and pic files. Don't you /own/ these?
How can you hack something if you don't have access to its files? When I mount my Ipod, I always wonder why tf they did rename all my music to F01.mp3, F02.mp3, etc. And because of this renaming there is a silly upper limit on the number of tracks I can hold on this said wonderful gadget (I use it because it has a 80G sized belly).
We should be hackers here (and defend the positive meaning of this word given by pg, particularly now). I understand why a CEO would love to use a nice looking toy as their phone, even in a tech startup. But I feel any true hacker should/would feel imprisoned with any device that you cannot mount and scp to, right?
Why would I care about files? I want to see a photo, I want to listen to a song, I want to open a document.
I why would I want to hack it? I don't want to hack my car, I want to use it.
Ok, I am an iPhone programmer, so I need to see below the surface. But the typical user does not. I am sure you know Clarke's law "Any sufficiently advanced technology is indistinguishable from magic".
Do you know what makes it so? Invisible implementation details. File system is an implementation detail. RAM vs. ROM is an implementation detail which exists solely because of the technological limitations. The classics of UX argued about need to hide these details long before iPhone.
Why do you think we see the rise of different "clouds"? Because they hide another layer of details. And yes, they move files you love so much further away from us. For the best, in most cases.
The times when hackers and users were the same people a over. Hackers today must understand, that the users of their products are no longer other hackers (with exceptions, of course) so different rules applies. Normal user will not care about implementation details. They may scare him. What the user want is to pick your product up and just use it.
Failing to understand that you fail as a hacker. On the other hand, succeeding to hide implementation from the users is a great hack.
Well, have you never been in need of opening a .doc with a simple text editor like vim and fix some issues? Really?
> The times when hackers and users were the same people a over.
That not my point. I reacted to the false claim that prosumer (ie power users / hackers / hn readers) prefer Apple.
As a matter of fact, most geekest geeks I meet in my job are all having Nexuses. Maybe because I live in China, but it was about the same in France and in Germany.
Interestingly, I find having that low-level access to be more restrictive. Suddenly, a thing that I just want to work (in this case, the music player) requires that I think about how I'm going to put files onto it, what the best way to synchronise those files is going to be, whether or not I have to mount it myself, if I ought to write scripts to manipulate it, the feeling that I need to write scripts to manipulate it, else why have all of these programming skills?
When really what I wanted to do was just listen to music while I'm walking around, and have a limited amount of worrying when it comes to getting music onto the device. (IE, it Just Works territory)
My behaviour is now circumscribed in other ways - my attention is split between things I really want to work on and this malaise of I ought to be crafting better tools to work with my music player.
"You can just set up rsync once!" is kind of a non-argument response to this - an Apple gadget, in this case, I set up nonce. Plug it in, it initializes, and syncs everything. Now I can listen to music where-ever I happen to be, and I don't have those circumscriptions to my attention.
If my Apple device annoys me sufficiently that I really want to have that level of control, there's a myriad of devices out there that automount as USB devices, that I could set up all sorts of nifty on-insert rules and script to high-heaven.
"I find having that low-level access to be more restrictive."
This look like an orwellian paradox to me, like "thinking less makes you free". Having low-level access don't mean you /need/ to use this power, it means that you /can/. Not having this power means you gave the keys to someone else. I'd rather keep most of the keys on my side, personaly.
The first time I saw an Ipod, it was at a party, in a friend of mine's hands, looked good, he had nice music, then I asked him to give me a few mp3, and it was "impossible right now". My god...
--> Never bought an Apple product myself (the Ipod I use is my wife's).
Maintaining a competitive edge with software that a small team can produce free of charge is a bit more challenging than a multibillion dollar hardware and software company with factories, no?
I was expecting the author to say something to the effect of "37signals added too many new features and now the software is confusing." So I was a little surprised to read on and learn that, no, 37signals kept their software somewhat basic, just as they said they would.
I have a feeling the author will write a similar piece in a year or two after using Podio -- no software is perfect.
For those who say that 37signals has allowed Basecamp to stagnate, I'd trot out as exhibit A the changelog: http://basecamphq.com/changes
Being very deliberate about making sweeping changes to an application with an extremely large number of very satisfied users is not the same as allowing it to stagnate. Having spent 4 years of my life working at 37signals I know first hand the incredible amount of energy that is devoted to it by an extremely talented team.
That said, it's certainly not for everyone. And if you outgrow it, fantastic, feel free to move onto a new product that suits you better. We do this with many other aspects of our lives, why should software be any different?
This is a story of success, not failure. He used BC and loved it for almost 6 years. I'd be very impressed if the next product Christian uses fulfills all his project management needs for the next 6.
1. Apollo has great customer service, and listens.
2. Apollo's interface doesn't look like Windows NT
3. Apollo is moving forward, while Basecamp seems to have stagnated/rested on its laurels.
I think Basecamp is a good product, but it's not that good.
I'd really like to hear from hackers organizing their projects what software in this category they like best. I have liked Basecamp as a framework for sharing do-list items with colleagues (most of my colleagues and I work independently of face-to-face meetings most of the time) but I am willing to learn about other products or service. Efficency is key. What do you recommend to do best what Basecamp does?
As a designer, I was frustrated using Basecamp before and that made me start Teambox. I chose the open-source way (like Redmine) and a simple feature set (like Basecamp), trying to make a more up-to-date version of what I thought project collaboration should be.
Things I found missing on BC and I did implement on Teambox: a single account (37s got this right later), a real activity stream (Facebook style, reply to anything from the feed), an open-source codebase so others could extend it and tight integration of first level elements: Conversations, Tasks, Pages.
Redmine is great after Basecamp. Minimal, fast wiki. Repository viewers (svn, hg, git). Access control, which can be used to create public pages quite easily. Nested projects.
GitHub's nice if you're focused on building software. Project wikis, home pages, code review, huge open source community.
I just set up redmine about 2 months ago, and I'm loving it. Recently got my SVN linked up and now I can cross reference commits with issues in the tracker.
I absolutly love redmine. Easy to customize, hundreds of add-ons, tons of functionality (including turning off tabs you're not using) and lots of support. If you're a geek that manages your own server, it's the way to go for sure. There's even a "basecamp" theme that looks and works great ;)
I like Open Atrium (http://openatrium.com/) because of its modularity and beautiful deafult theme. It's based on Drupal, so if you were building Drupal websites before then you will find it very easy to customize.
I have yet to find a project management app I like more than AgileZen. It allows me to model my workflow, assess against estimates and to top it off it's very pretty. There are a few things about it that bug me: notifications suck and there is no interaction between projects. Other than that, it's awesome.
Redmine? It has a ton of features, so it limits a lot of the more complicated stuff by default. Notifications are awesome, and cross-project stuff works beautifully when using subprojects (shared gantt, cross linked wikis, timelines, etc).
Refering to a Robert Scoble post while accusing DHH of being on insider bubble is really hilarious. There is no one more in the bubble than Scoble, and no one who is more blinded by the fact that he's in the bubble than Scoble.
DHH was fundamentally right, even if the details were wrong. For 99.9% of apps there is a replacement app available on any of the mainstream phone platforms. The long tail maybe gets you a bit more polish, but its polish on non-core scenarios. Most people will decide based on the polish for their core scenario, not on Textalyzer.
The cheapest Basecamp plan (Basic) is in fact $24/month, not $49 as mentioned in the article.
If you run a full time consulting business, $24/month is a negligible expense for software that supports the core function of your business.
I'd argue that all the prices are negligible as they scale with the size of the business. Even the Max plan ($149/month) is only $1788 per year, which is equivalent to less than 2 weeks worth of man hours. Logically, if using the Max plan of Basecamp saves you and your team 80 hours over the course of a year it should be a no brainer.
I just finished reading ReWork, Jason Fried's latest book. The irony of this submission is that the book describes Christian to a tee: the customer who always wants more; the customer who has outgrown the product; the customer who compares competitors but would rather complain than move.
I have to admire the way 37signals has grown over the last few years. Sure, they clearly don't integrate every feature. The user interface certainly works but has no iGloss about it at all. Pricing is steep and they hide the lower-priced plans. But it works: people still use the service.
If you're a coffee shop you concentrate on your coffee. If you're an electrician, you concentrate on the quality of your work. Adding extras like "nice cable ties" are irrelevant. 37signals are concentrating on their core functionality. When the day comes that the majority of their users require X feature and that feature becomes a norm in Project Management, Contact Management, Collaboration, etc then I'm almost sure they will react: why wouldn't they?
Basecamp is a good product but only if you share its "opinion" on workflow and design. Obviously 37Signals has done well by sticking to a minimal set of features and catering to a very specific audience.
We are of the mindset that software should fit the way you work, not necessarily the other way around. We're building a Force.com-like platform that allows you to create custom business workflow apps in minutes to handle not just tasks, but also lightweight crm, recruiting, and other business functions involving a relatively defined process. We provide a fast UI to access these records, so all you do is specify the schema and callbacks.
We're still in beta, but happy to release some invites and work with members of the HN community -- http://www.devcomb.com
The fact that a user goes out of the way to broadcast that they're walking away from the service is a testament to how bad ass it truly was for them. Every developer should hope for that sort of torment at the end of use period for a user. Clearly it was a big enough part of their workflow to complain.
Most (all?) of us developers / product guys fight with feature creep. I'm glad 37signals is there to remind us, by example, that it's OK for a software business to focus on a specific solution, sans bloat. There are users that will appreciate your vision - and gladly pay.
I don't think you've listened enough, because 37signals has stated repeatedly that it prefers customers to outgrow the services (as is your case) than to intimidate new customers.
I was introduced to Basecamp through a project I was invited to contribute to. Before I had heard about the product, but I had never used it and as far as I can tell I wasn't significantly biased for or against the product or the company that made it.
However, within days I came to hate Basecamp intensely. Not so much because it imposed certain structures and ways of working -- discomfort is to be expected when you learn a new tool. And, of course, sometimes, it turns out you can learn better ways to work from tools that force you into certain ways.
No, what made me hate Basecamp with a passion is that the thing is slow. It is unacceptably slow. And the UI, be it the web UI or the various apps that existed for it at the time (late last year), did not manage to meaningfully mask the fact that the system was slow as molasses.
The fact that 37signals, a much lauded company, would allow an important product to have such a glaring fault now means that I see anything that 37signals say or anything that is said about them in a different light. I am now thoroughly biased to think that they have no business telling anyone how you make good software. I can't help this, though I will acknowledge that this is an emotional response rather than a rational one.
It also means that anyone singing the praise of 37signals now also seems suspect. Do they even form their _own_ opinions or do people just parrot the praise that people they look up to heap on the company.
Slow apps are not cool. Companies that make slow apps without visible embarrassment are not cool. Basecamp is dead slow and it is perfectly okay to point out that the monarch appears before the court sans clothing.
You didn’t integrate the Writeboard into Basecamp.
Worse, it hasn't been papered over well either. I can't load a Writeboard from Basecamp without some weird 1990s-style "we're loading your Writeboard" page hanging around for a couple of seconds. UI-wise, I'd be satisfied with it being separate if it weren't for the extra page coming up wasting time and making me think something happened.
I think the effectiveness of project management software depends greatly on the type of project being managed.
For example, I don't consider Jira as in the same arena as Basecamp (and I've used both a good amount). I see Jira as a programming/development specific management tool, to be used by programming teams and maybe the managers of those teams.
I see Basecamp as a far more flexible project management tool that can fit a wide variety of needs. It works great for organizing our Entrepreneurs Unpluggd events. It works well for some web dev projects and design projects, but not others.
Basecamp isn't always THE solution. For some types of projects, it is. For others, it isn't.
At the end of the day, the right answer is the project management software that helps you more efficiently organize your specific projects. Because Basecamp doesn't work for Joe and his projects doesn't mean it can't work amazingly for Sally and hers.
A few years back, when I was working for an IT analyst firm, I headed a project to find us new task/project management software. (Our existing application for this was old and homegrown and pretty bad.)
The issue is that the significant majority of our tasks/projects were very small: Take a briefing with a client, write up notes, attach presentation, possibly include a followup note for sales, done. So project management software that was organized around the principle of a modest number of projects with milestones, actions, sub-tasks, etc. didn't really work for us. (Including the 37signals options.)
We eventually settled on trac which worked pretty well for the purpose. And we'd probably have supplemented that with something more like Basecamp if we got into some more complex projects and simply handled them as a separate case.
My broader point though is that I found that the "best" project management software depended on what you were trying to track.
My company pays a whole hell of a lot more for a far far more complex and way over bloated system. I applaud 37signals for their choices and sticking to it. The author here needs to just get over the fact that his needs outgrew the software and to seek another solution. No need for the dramatics.
Basecamp seems to be designed exactly for a web design shop that wants to take on bigger projects and present an organized appearance to clients. More client management than project management.
Well, the OP is German, so I'm sure he's doing the best he can. And it's really not that bad -- certainly writes better in English than I can in German! :-)
As users gain more experience, their needs become slightly more complex. They start to understand the simple product completely, and then they have the cognitive ability to understand more fancy bells 'n' whistles. For users who have been doing project management for a long time with any software product, they will have a long list of things that they know -- from experience! -- that they need.
That is why there's a market for simple and there's a market for full-featured. Both are discrete markets, usually. Obviously every software designer strives for "power made easy" -- it seems easy at first, but there is power under the hood when you need it.