There has been a cultural divide between the techies and the art-based application developers. As a techie, I’ve said for a long time that the requirements elicitation process is broken, but it is broken as a matter of the indifference of engineering efficency as the core value and the political filters of organizations.

The key is recognizing functional cultures. You can do concepting all day under the execuitive sponsor paradigm and working through screens will be the end result of working through the indifference of that economic sponsor.

Until we recognize the individual or at least the functional unit as a unit of meaning and encode that meaning and its relevance of work, we will continue to produce average functionality that leaves hidden costs in its wake. It’s not a matter of whether there is joy in work, but in the cold hard truth about the cost structure inherent in averaged functionality.

I like what I’ve read so far, but if you want further comments, provide a blog for that. This isn’t my blog. It just seems that centralized comments would be more focused.

”Working through Screens: 100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work”

View / Download online book: http://www.FlashbulbInteraction.com/WTS.html

Very curious to hear any thoughts that you might have on this project.

Tick, tick, tick….

In an existing category, you have choices in regards to how you will fight price-based competition in the late market. You should make those choices before you enter the late market.

If you are going to sublimate your interface, you should build in the model-view controller pattern facilitation as early as possible. If you are going to move to mass customization, then you need a view-population pattern facilitating architecture. If you are going to die by price competition, then you need to have a discontinous technology coming down you pipeline before you consume 50% of your market cap. Late market, the price-based competition and consumer/non-geek market is a deaveraged market on the B2B side, and one-to-one marketing is about deaveraging even the most average market around.

As for Ford, they have probably moved to XM radio or some such. If I have to pay extra to hear music in my car, I won’t. Somewhere under the decision to remove FM radio is a strategy.

Cell phones companies are pushing texting as a way for them to make money, so I get a lot of free text messages to get me used to them. Your feature set serves multiple strategy constituents.

Over time features become commodities. If those features are playing gates, as in to be in the market you must provide that feature, then leave it in. Otherwise, it is not providing value, revenune, or profit, so it is time to take it out.

Taking things out means having a technical architecture that lets you get that done.

Another example was Macromedia. They had a framework that spanned all their applications. When they M&Aed, they took the application catelog of that company and put it on their platform. This led to the demise of features, but always improved the product.

For strategic reasons product features are redistributed or repackaged to drive different market segments as you mentioned.

And then on the other hand in custom projects where there the maintenance costs of features and the removal of risdual bugs and design flaws can still be a high cost features may be removed that are not working so well. I have removed functionality from custom products only to have customer complaints. Our judgemenet was that the cost of the features was higher than the overall benefit.

What I couldnt think of was a mass produced market product in the same segment that has lost a feature. And if it happened why? The Ipod nano will no longer have podcast or playlist playback ability? The ford focus will no longer offer an FM radio option.

On the other hand this is really only interesting for established product offerings. In the mobile phone industry for example nobody really even thinks of a model or funcions. The AZ3423 will have Mp3 and the TH234TF Flip will not. The exception being Apple but probably only because they are so new to the game.

Remove a feature? Wow! Cant think fo any IT or physical product where we actually have seen a product lose a feature. Most of times we have had that happen in our IT products the users end up punishing us!!

Best Regards,
Mans Shapshak

This is the link to the translated post:

http://rashaas.jeeran.com/Techno/archive/2008/6/586232.html

I agree with this particular post because even if the product is full of features, they may not really address the client’s needs and issues. It is far better to tell them how your product solves their problems instead of bombarding them with features and functions that they may never use ever.

I recently blogged about the need to Design for User “Delight”
http://sachendra.wordpress.com/2008/05/22/design-for-user-delight/

Excellent post. We had this saying that release planning was more about what things not to do than what things to do.

Coincidentally, I just blogged about an article on Business Week where they talked to Chris Hacker at J&J.

Check it out at
http://productmanagementtips.com/2008/05/22/customermotivation/