Feature Ecology
Posted by Jeremy Voorhis Tue, 19 Sep 2006 20:35:00 GMT
Throughout my years as a software developer, I have come to recognize that it is silly to think a product can be improved by adding features. A product is its features. More specifically, it is the union of its features within a given context. When a feature is added to a product, the nature of that product has changed. Can you imagine a product with no features? I doubt it. Can you describe a product without mentioning any of its features? Can you compare two products while ignoring their features? Try it.
Features are not additive; they alter the environment of all other features. I recall when 37signals added Writeboards to Basecamp. When posting to Basecamp, I decided whether I was posting a living document which would be best handled by Writeboard, or a temporal message, which was best handled by the messages feature of Basecamp. Messages also excelled at fostering discussion, but Writeboards did not; they were more wiki-like, and over time the identity of the original author matters less and less. Later, 37s integrated Campfire with Basecamp. Since then, Basecamp users who want to initiate a discussion can use the cooler messages option or the warmer Campfire group chat.
After these two features were added to Basecamp, its messages weren’t used in quite the same way. If you are reading this blog, it is very likely you are participating in creating a product of some sort. Do you have compartmentalized ideas of a product and its feature list? Do you implement features in isolation, or can you find the interactions between features within your product’s environment?
I tend to look at a group of features as possibly being a product in itself. This product could in turn become a feature in another product.
I’m not saying merge products to make something new. However, what makes Basecamp come off as so darn cool to me is the fact that there are these features/products that I can turn ON or OFF within Basecamp.
PLUS, these features/products are useful if I use them by themselves without having them in the Basecamp environment at all.
Separation of products seems to allow you to focus on making that product and its features better which in turn will make any other product that uses it better as well.
Features as musical instruments. Add congas, and your country song’ll be experienced very differently. Related: “Needs more cowbell.”
Merlin Mann talks a lot about how different apps make him feel differently, when working with them.
A product is a collection of thoughtful solutions for a specific problem or set of problems. Features often shape the solution… but are just part of what builds the final solution. Developers and client have given too much merit to features and it’s of my opinion that the real value of products is determined by the solutions it provides.
So… I would argue that a product is a solution.
What solution does a featureless product provide?
The important thing to remember is that products are filling a problem in the market. These solutions consists of features but these features are the bells and whistles in the project.
The cd player in a car is a feature… but isn’t what the buyer is needing. They need a car to travel places. An iron helps you get wrinkles out of clothes. Hair dryers… help you dry your hair. Basecamp provides a space where clients and contractors can collaborate on projects. These products provide solutions… not features.
I know where you’re coming from but I’m not convinced that features are what make up a product. If it doesn’t solve a problem… it’s worthless. :-)
I’m cool with the zen-ish “products are features” but “features collected are not products” if I’m just being contemplative. But I’m wondering how does this help me think about software?
What is the definition of “feature”?
If features are not additive, what is the thing-that-is-not-feature that comes into existence when two or more features are put into relation with one another? What do we call it? How do we talk about it?
By your definition, “A product is its features”, a featureless product is a nullity. But a solution is not the same as a particular product. As you’ve pointed out before, an effective solution to your problem of tracking contacts was an alphabetized moleskine. For others, it’s a Palm, etc. The solution is something like, “To keep track of contacts, record them on persistent media from which they later be retrieved.” One solution, multiple implementations.
There’s something of the typical disagreement here between synthetic and analytic perspectives. One can attempt to decompose a piece of software into discrete, nameable bits. Another can examine the qualities of the system as a whole. Neither will be 100% accurate. Such is the wave-particle duality.
@Robby
I wasn’t talking about bells-and-whistles. A car typically has wheels. I would consider that is a feature.
Perhaps they do need a car. That is a common solution, but we haven’t yet established any need for a car – only that the buyer needs to travel. Depending on the context, other options exist. I admit this is a trivial example, but it illustrates how quickly we jump to a particular solution.
A product is something produced.
I think Jeremy’s original statement, which I might paraphrase as “utility of a product is a (strongly) non-linear function of it’s features” is fairly hard to argue with.
Robby: Wouldn’t it also be fair to call “it goes from A to B” a feature of a car? If not, what would you call the things a product consists of that are not features?
Brian: we can call it utility.
I’m not sure what the rest of this dialog has to do with the price of tea in china, so I’ll abstain.
It’s apparent that we’re not understanding one another in our discussion, which is ultimately the problem.
When you say that, “a product is its features” you’re essentially saying that if you select a bunch of features and mash them together… you have a useful product. What I am suggesting is that when you decide to build a product… you are hoping to provide a solution (or set of solutions) to a targeted audience. The features are just a means to an end. Features are important in a successful solution but most features can be replaced with new features and still provide a similar solution. For example… a car might currently have wheels, which is a feature/attribute of the solution… but if we figure out how to get cars to hover.. the wheel feature will be changed. The product manufacturers are still able to provide a solution for the users/customers.
I’m not dismissig the value and/or importance of features… but when we’re working with clients we definitely want them to think of their product as just a set of features. When they approach us with a list of features and are attached to them… it causes a lot of problems when discussing alternative implementations. When we are able to get them to agree that they want to develop a solution… we can then collaborate with the client, without prior attachments to features, on innovative features to help provide a great solution… not just a stack of features.
Robby,
You seem to be fixated on your solution language; I am talking about something different. First, consider this: a product is composed of its features. It is also an environment, not a “stack”. When you stated that one cannot “select a bunch of features and mash them together” to create a useful product, you have not succeeded in disagreeing with me.
Furthermore, while an automobile and a hovercraft may provide what seems to be an equivalent solution, introducing the consumer hovercraft would introduce new patterns of behavior and alter society’s relationship to the automobile. Producers should take interest in these dynamics.
Jason: I’m not sure what you’re referring to with “utility”. I’m not talking about the effect caused by the interaction of features. That may be negative as well as positive. So utility doesn’t seem a good fit.
When talking about a product as a collection of it’s features, it’s helpful to put your finger on what is a feature. Consider an analogy: your hand could be considered a feature. But what are the boundaries of your hand. Anatomically, there isn’t a clear boundary. In common parlance, we generally draw the line at the wrist. But talk to someone doing Structural Integration (Rolfing) and they will tell you the “hand” extends well into the forearm because the “hand” functionally includes the tendons and muscles that actuate it.
To effectively talk about “features” and the effects of features in relation or interacting, it would be nice to develop a working definition of feature.
Brian:
You haven’t read my latest post yet.
Brian: I think utility is the perfect concept. It covers the nonlinearity (eg the negative and positive interaction of features) as well as the subjectivity (one users must have requirement might be another users bell or whistle). Marginal utility has been very useful in economics, and I think the concept directly applies here.
I believe I’m offering a useful framework of terminology for discussion. If you’re going to criticize that, perhaps you could offer your own definitions, and show how they are more useful?
Personally I believe an ostensive definition of feature is satisfactory for this discussion. Your hand example is quite appropriate; I’m with Wittgenstein: it doesn’t seem useful to doubt that here is one hand.