Slashdot Mirror
Subject to Change
prostoalex writes "Most companies would call themselves innovative and would claim they're delivering an above-average service to their customers. Yet, their customers opinions might differ. If you drill a company on their innovation practices, they would probably mention two approaches they employ:
1. Their research department meets with target groups, compiles presentations for the upper management, which then occasionally hands those reports over to the development department. 2. Their research or marketing department comes up with competitive matrix of the products available from competition. In a meeting then, executives see that their product is missing a feature, and hence the development department is assigned the task of adding 'an Internet-enabled installer' to the product, since everybody else offers them, thereby creating market expectations." Read on for the rest of Alex's review.
Subject to change
author
Peter Merholz, Todd Wilkens, Brandon Schauer, David Verba
pages
186
publisher
O'Reilly
rating
7
reviewer
Alex Moskalyuk
ISBN
9780596516833
summary
Creating great products and services for an uncertain world
Subject to Change is a book, written by four Adaptive Path veterans describing new approaches to product development and innovation. Who are they to have the authority over the subject? Adaptive Path is a consulting shop helping large and small companies with product design, Web design and industrial design. They're perhaps mostly known to the general public for coining the term AJAX, and articulating the idea of building dynamic Web sites with asynchronous data retrieval, but they certainly didn't invent the technology. Their design experience is behind many products we use today, but due to licensing agreements they're not always at liberty to disclose their customers.
So what do Adaptive Path designers advocate?
Making the design emotional. While the idea itself is not new, this is something that product manufacturers have to face sooner or later. Early Kodak cameras did not succeed because of superior technical qualities or ease of film development — they managed to cross this emotional barrier, where people who previously thought "This is too complicated" after getting a glimpse of the ad or product demo thought "Even I might be able to enjoy this."
Understand people's needs outside of your company-approved usability testing guides. Two great examples provided by the book are Adaptive Path's own usability study of Epinions.com — product review and comparison shopping site. When a woman showed up for usability test with her newborn baby, she was frequently distracted by baby's needs during the test. Bad test candidate? Vice versa. Adaptive Path learned how confusing it could be for someone who needs to get away from the comparison shopping process to come back and quickly realize where they were in the process. Another example has to deal with babies as well — after watching new mothers use the diaper wipes at their homes, Kimberly-Clark researchers redesigned their diaper wipe container to be easily accessible with just one hand.
Make the whole system coherent, not just patch new interfaces throughout product holes. Financial companies and banks certainly suffer from a desire by single group to innovate the others out. My own example — I go to Fidelity Web site, and upon login offered to also check my NetBenefits(SM) or check out the FullView(R). Now, there might be customers who think in those terms, but I surely did not log in to check NetBenefits(SM) or do FullView(R) or check out mySmart Cash Account (SM), I just wanted to find out how my investments were doing. A simple graph would do. Yet my options from Fidelity are either downloading quarterly PDF account statements, and then punching the numbers to create a graph, or going to Account Positions page, where I can view the graphs for every single stock and bond I own for any time value except the time span that I need — from the day I bought the security to today. This is not a rant on Fidelity Investments in general, this is just another example of different groups within the company handling such things as stocks, bonds, retirement planning, cash investments, quarterly account reports, and Web site design. Each group probably doesn't think highly of the existing user interface, and hence the desire to introduce that new simple interface, call it a different name, and expect the customers to get on with a program and use it.
The authors provide a lot of good case studies for design successes and failures to support their point. Case studies are borrowed from outside literature or told in first person — Adaptive Path's customer names are changed to be KeyboardCo or FinanceCo to protect the innocent. The book explores several different permutations of design and relevance:
When design is great, and product is relevant, market success is a given. The example is Apple iPod series. Somewhat less known example is Google Calendar, that outgrew Yahoo! Calendar and MSN Calendar, even though all 3 calendars are tied into Web-based e-mails, and Yahoo! and Hotmail both have market shares multiple of Gmail's.
When design is great, but product is not relevant, market success will be extremely hard to achieve. Segway scooter and Apple G4 Cube come to mind.
When design is bad, but product is relevant, market success will quickly turn into failure as competitors copy the product and invest in design. Diamond Rio, the pioneer of digital music player industry, learned a hard lesson that way.
When design is bad, and the product is irrelevant, it's possible it will never even come out in the market. Adaptive Path's own example of KeyboardCo wanting to implement a downloadable music service right on the keyboard is a good example of this.
Overall the book is informative and inspirational, albeit a bit dry. Chapter 7, dedicated to describing agile approach in software development, seems to be out of place. Maybe it's because I am a software engineer, and have familiarized myself on various development methodologies, the chapter was old news to me, or maybe it's the idea that you're being sold one specific methodology, instead of implementing dozens of small improvements within the product development process, that threw me off.
On page 162 the authors claim "Google and Yahoo!, once technology companies, are now media players, and their advertising-based business models mean they compete more with Los Angeles and New York than their Silicon Valley brethren." Now, I don't see how being a media company leads one to compete with a US municipality. Maybe they meant "New York [Times|Post] and Los Angeles [Times]", in which case it's time to look for another proofreader. But to be fair, I haven't noticed any glaring errors or omissions in the title.
Subject to Change is a good book to read if you're into product development or design. If you're staying abreast of the industry trends, most of it is probably not going to be big news to you, nevertheless, it's a good collection of case studies and a summary of rules relevant for modern-day product development.
You can purchase Subject to Change from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
So what do Adaptive Path designers advocate?
Making the design emotional. While the idea itself is not new, this is something that product manufacturers have to face sooner or later. Early Kodak cameras did not succeed because of superior technical qualities or ease of film development — they managed to cross this emotional barrier, where people who previously thought "This is too complicated" after getting a glimpse of the ad or product demo thought "Even I might be able to enjoy this."
Understand people's needs outside of your company-approved usability testing guides. Two great examples provided by the book are Adaptive Path's own usability study of Epinions.com — product review and comparison shopping site. When a woman showed up for usability test with her newborn baby, she was frequently distracted by baby's needs during the test. Bad test candidate? Vice versa. Adaptive Path learned how confusing it could be for someone who needs to get away from the comparison shopping process to come back and quickly realize where they were in the process. Another example has to deal with babies as well — after watching new mothers use the diaper wipes at their homes, Kimberly-Clark researchers redesigned their diaper wipe container to be easily accessible with just one hand.
Make the whole system coherent, not just patch new interfaces throughout product holes. Financial companies and banks certainly suffer from a desire by single group to innovate the others out. My own example — I go to Fidelity Web site, and upon login offered to also check my NetBenefits(SM) or check out the FullView(R). Now, there might be customers who think in those terms, but I surely did not log in to check NetBenefits(SM) or do FullView(R) or check out mySmart Cash Account (SM), I just wanted to find out how my investments were doing. A simple graph would do. Yet my options from Fidelity are either downloading quarterly PDF account statements, and then punching the numbers to create a graph, or going to Account Positions page, where I can view the graphs for every single stock and bond I own for any time value except the time span that I need — from the day I bought the security to today. This is not a rant on Fidelity Investments in general, this is just another example of different groups within the company handling such things as stocks, bonds, retirement planning, cash investments, quarterly account reports, and Web site design. Each group probably doesn't think highly of the existing user interface, and hence the desire to introduce that new simple interface, call it a different name, and expect the customers to get on with a program and use it.
The authors provide a lot of good case studies for design successes and failures to support their point. Case studies are borrowed from outside literature or told in first person — Adaptive Path's customer names are changed to be KeyboardCo or FinanceCo to protect the innocent. The book explores several different permutations of design and relevance:
When design is great, and product is relevant, market success is a given. The example is Apple iPod series. Somewhat less known example is Google Calendar, that outgrew Yahoo! Calendar and MSN Calendar, even though all 3 calendars are tied into Web-based e-mails, and Yahoo! and Hotmail both have market shares multiple of Gmail's.
When design is great, but product is not relevant, market success will be extremely hard to achieve. Segway scooter and Apple G4 Cube come to mind.
When design is bad, but product is relevant, market success will quickly turn into failure as competitors copy the product and invest in design. Diamond Rio, the pioneer of digital music player industry, learned a hard lesson that way.
When design is bad, and the product is irrelevant, it's possible it will never even come out in the market. Adaptive Path's own example of KeyboardCo wanting to implement a downloadable music service right on the keyboard is a good example of this.
Overall the book is informative and inspirational, albeit a bit dry. Chapter 7, dedicated to describing agile approach in software development, seems to be out of place. Maybe it's because I am a software engineer, and have familiarized myself on various development methodologies, the chapter was old news to me, or maybe it's the idea that you're being sold one specific methodology, instead of implementing dozens of small improvements within the product development process, that threw me off.
On page 162 the authors claim "Google and Yahoo!, once technology companies, are now media players, and their advertising-based business models mean they compete more with Los Angeles and New York than their Silicon Valley brethren." Now, I don't see how being a media company leads one to compete with a US municipality. Maybe they meant "New York [Times|Post] and Los Angeles [Times]", in which case it's time to look for another proofreader. But to be fair, I haven't noticed any glaring errors or omissions in the title.
Subject to Change is a good book to read if you're into product development or design. If you're staying abreast of the industry trends, most of it is probably not going to be big news to you, nevertheless, it's a good collection of case studies and a summary of rules relevant for modern-day product development.
You can purchase Subject to Change from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
and their advertising-based business models mean they compete more with Los Angeles and New York than their Silicon Valley brethren
People often use "Silicon Valley" to mean "technology companies," and you have no trouble understanding that they mean the latter as opposed to some geographical region. The same is true of New York and Los Angeles in the above. "New York" alludes to big business (think: New York Stock Exchange), and Los Angeles to big media (think: Hollywood).
No offense, but you shouldn't be writing book reviews if you can't parse the writing.
its called dilbert.
Good people go to bed earlier.
I think product teams tend to have an inferiority complex that is fed by the worst marketing invention ever: the feature matrix on the back of the box. Not enough product teams care about anything else.
"Now, I don't see how being a media company leads one to compete with a US municipality. Maybe they meant "New York [Times|Post] and Los Angeles [Times]"
perhaps they are referring to the fact that NYC and LA are the centers of the advertising and media industries.
Sounds like somebody has gotten through their first year of business school, and is on a high where they think they know stuff that others don't.
-fb Everything not expressly forbidden is now mandatory.
A lot of what a consultant says is Obvious. But coming from an Expert will be listened to when coming from an employee it won't.
It's the nature of how people filter information, if it comes from an authority they will give it greater value, regardless of it's inherent value.
The buzzword of the day for business school crowd, guess it's catching up with "leadership" - the vague, abstract, nebulous, infinitely debatable notions that the intellectually weak and dishonest obsess over. Ok, I'll stop the rant here.
How about scratching the itches and fixing the bugs? Just by doing these you may come across many small but significant enlightenments, instead of trying to "think out of the box" and to "innovate". This bit is a suggestion, not a rant.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
"When design is great, and product is relevant, market success is a given."
Whoa. Is that why Windows took over the world? I'm sure there are thousands of great, relevant products that did not see the light of day because the creators/distributors of those products did not have good market access; whether it be financial where-with-all to promote a product, entrenched competition, monopolies or what-not.
"Build it and they will come" usually fails. 9/10 companies fail. I'm sure this applies to products, that je ne sais quoi about a great product that you really need but just don't want it enough.
Saying Rio made the market and iPod took it because of the design obviates the incredible marketting campaign Apple had that still sticks in people's memory (siloutted dancing headphone
/\/\icro/\/\uncher
Most executives that I've met have only a tenuous grasp of the obvious.
Separate research and development departments? And then there's customer engineering, maintenance, etc., etc.
The successful firms I've worked for rotated everyone through these tasks. Some of us had multiple responsibilities at one time. That way, new technologies, customer requirements, bug fixes and everything had an equal probability of propagating through the design/build cycle.
Woe to the pure research geeks who tossed an incomplete idea over the wall and figured that tech support would deal with its shortcomings. Odds are next week, they'd be handling the irate customers. And we had no time for an engineer who didn't want to go down to the shop or out in the field with a construction crew to solve a problem.
Have gnu, will travel.