5 ms·

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 wh

by spolsky 15y ago

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.

fmavituna 15y ago
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) .
- jessedhillon 15y ago
  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.
  - fmavituna 15y ago
    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...
    - applicomhq 15y ago
      Let me be the devil's advocate for a moment. 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. Really. Tony Mobily http://www.apollohq.com http://www.apollohq.com
jjm 15y ago
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. [1] Eric Ries "Harnessing the Power of Early Adopters" http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2291 http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2291 [2] http://www.startuplessonslearned.com/2009/03/minimum-viable-product.html http://www.startuplessonslearned.com/2009/03/minimum-viable-...
giberson 15y ago
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.
- DrJokepu 15y ago
  I think many people would be uncomfortable with being patronized by a website. Switching on advanced features should be driven by the user.
- jbwyme 15y ago
  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.
mmaunder 15y ago
Thanks Joel, this helps.
teyc 15y ago
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.
cjung 15y ago
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.
- cjung 15y ago
  More here: http://bit.ly/iKyBQt http://bit.ly/iKyBQt
jazzdev 15y ago
Jared Spool defines a model of core users (who have domain knowledge) and ring users (without domain knowledge): http://www.frugalmarketing.com/dtb/corevsring.shtml http://www.frugalmarketing.com/dtb/corevsring.shtml 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.
applicomhq 15y ago
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. Tony Mobily http://www.apollohq.com http://www.apollohq.com

by spolsky 15y ago

fmavituna 15y ago

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

jessedhillon 15y ago
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.
- fmavituna 15y ago
  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...
  - applicomhq 15y ago
    Let me be the devil's advocate for a moment. 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. Really. Tony Mobily http://www.apollohq.com http://www.apollohq.com

jjm 15y ago

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. [1] Eric Ries "Harnessing the Power of Early Adopters" http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2291 http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2291 [2] http://www.startuplessonslearned.com/2009/03/minimum-viable-product.html http://www.startuplessonslearned.com/2009/03/minimum-viable-...

giberson 15y ago

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.

DrJokepu 15y ago
I think many people would be uncomfortable with being patronized by a website. Switching on advanced features should be driven by the user.
jbwyme 15y ago
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.

mmaunder 15y ago

Thanks Joel, this helps.

teyc 15y ago

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.

cjung 15y ago

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.

cjung 15y ago
More here: http://bit.ly/iKyBQt http://bit.ly/iKyBQt

jazzdev 15y ago

Jared Spool defines a model of core users (who have domain knowledge) and ring users (without domain knowledge): http://www.frugalmarketing.com/dtb/corevsring.shtml http://www.frugalmarketing.com/dtb/corevsring.shtml 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.

applicomhq 15y ago

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. Tony Mobily http://www.apollohq.com http://www.apollohq.com