One of the things that makes me nuts is when a product gets the default settings wrong and makes me do work to make it do the right thing.
This happens more often than you’d think. Example 1: the stereo in my new car. I love the GTI for a lot of things, including the ride and the compactness of it. But I am really growing to dislike the way they did the stereo. Why? The default behavior when I turn on the car. It should remember that when I turned it off I was listening to music through the phone (either Bluetooth or the dock connector) and go back to that channel. But it doesn’t. Instead, its logic seems to be:
- There’s nothing on the dock connector!
- There’s nothing on Bluetooth!
- So let’s go back to the other thing we were listening to–the satellite radio.
Except, the reason there’s nothing on Bluetooth is that it takes about 30–45 seconds to pair a phone with the car, and the designers surely knew that. So why wouldn’t they just have step 2 wait for a while? That way I wouldn’t have to fiddle with the settings every time I get in the car.
(Why don’t I just plug the phone into the dock connector before I start the car? That works for about 30–45 seconds; then when the Bluetooth connection is established, the phone gets confused and stops playing back through the dock connector!)
The problem with this scenario is that it’s not obvious when you look at any of these pieces that they’re wrong. When you consider the component level, any of a number of choices look like they could be the right one. It’s only when you stitch them all together, and think about how the user would use them, that the right behavior becomes apparent.
I’m pretty sure there’s a product management law that describes this principle, something like don’t make me do more work than I have to. But it’s astonishing to me how often people, and products, get it wrong.
I think its more than defaulting to the right thing, its about thinking of the right details in the first place. The devils are always in the details and when you look at the success or failure of a product it’s always because of the little things. The only time the little things don’t matter is when the product has a monopoly or is uncontested, but poll the users of that product and they will likely tell you they hate it but don’t have any choice.
Now the reason I believe a lot of complicated products, like a car (or enterprise software 🙂 are cursed to get the details wrong is because they don’t focus on the whole system. They divide and conquer to design the whole thing but they fail to develop use cases that cut across team lines, instead they develop interfaces across those lines and then fail to test the system, vs just making sure the interfaces work.
But how do you make sure you are dealing with the detail devil? Often companies might put this responsibility on the shoulders of their most OCD individual and then hope for the best. But a more objective way to ensure you are handling the details might be to track the number of system use cases that cut across team and component lines and make sure you test the right ratio of feature vs system use cases with every release.
Who knows what would have happened if VW had use cases like ‘driver wants to listen to music on their iPhone via Bluetooth every morning on way to work’ instead of ‘radio must support Bluetooth for wireless audio’.
Hi Erik!
I agree that use cases help–God knows the one you called out probably would have helped in the GTI. And they’re probably required to help a product scale. But I don’t think you can make this totally objective. You still need people who are looking at the whole system.
And yes, I see the irony in this conversation. Rewriting the agenda as I speak…