I am sure this subject is like opening a can of flaming hot worms – there really is no one answer to it.

I stumbled across this today:
http://steveblank.com/2013/11/21/when-product-features-disappear-amazon-apple-and-tesla-and-troubled-future-of-21st-century-consumers/

The downside is when companies unilaterally remove features from their products without asking their customers permission and/or remove consumers’ ability to use the previous versions. Products can just as easily be downgraded as upgraded.

Steve makes some fair points but as a PM myself I grapple with this concept all the time. Do we have some contract with the users that we must keep everything we have ever put in the product alive? Steve almost alludes to that but I know he is just trying to make the point – especially as compared to what has happened lately with products like the Apple iWork suite.

Huge backlash over the new completely rewritten stack losing some key features but with Apple slowly pouring them back in on a new code base. The premise is that Apple rewrote the iWork suite to make it function across iOS, web and OSX. Now that the rewrite happened they are adding some, but not all, of the features back in. Seems logical but as a user you might still hate it since you still lose the feature and running old version is hard to do these days.

Latest on the iWork shuffle:
http://www.macrumors.com/2013/11/21/iwork-for-for-ios-and-mac-updated-keynote-gains-with-new-transitions/

We experienced some of this at Spuul as we moved over to our new API stack, brought to you by the code magicians at Spuul, since we pretty much rewrote everything from the ground up to accommodate more clients and features. This also meant looking at our current feature usage and deciding what features might stay and which ones might hit the bit bucket. Did I ask users about this? No. Mostly cause the data largely answered the questions for us – we could see what was being used and what wasn’t. We could also look at our help queries and the customers emails that I save. All of these made up a nice view that for the most part gave us a clear indication of what to do. Then we added in some ideas of our own and logical guesses to decide what to throw out and what to save.

Some of the goals were the same as Apple really. Build from a new more agile base, simplify, and then work our way back up. We are just not as big so the impact isn’t the same. With Apple – they are so big that practically anything they do will affect someone in some way. I don’t know if Apple handled it right- most of the cuts haven’t affected me but I assume they affected someone. Could Apple have polled everyone? Maybe but the poll would have created a funnel for people to complain and then even more press about it. I am not sure anyone wins at this. Expectations are just so high that everyone expects to be pleased in their own way setting up an impossible user contract.

Steve Blank uses other examples like Tesla and Google to prove his point. The Tesla one is the most interesting cause it is a software update that changes the car – something very tangible. I think Tesla should have been upfront about it and stated that for the safety of the occupants in their vehicles they felt this is the best way to handle it until they come up with more data or options. Just doing it without telling folks seems sly – in a bad way even if the goal is for good.

Steve closes out with user contract idea of some sorts:

A 21st Century Bill of Consumer Product Rights

For books/texts/video/music:

For software/hardware:

This is interesting but in the world of App Stores this is tough to manage with all the auto-updating and no ability to roll back. So for any of this to happen the folks like Apple, Google and MSFT would have to allow the developers to manage stuff like this. Today it is not really clear how one would do that.

Great topic to think about but a tough one to really have a definitive answer for.