If you want to be a bad product manager, make sure your product has lots of options. Some users might want to use keyboard shortcuts, others might want to use just the mouse, and some might want a command line interface. How can you possibly pick one that works best for everyone? You can’t! So, put all of those options in your product. Better to give customers choices than to possibly leave out someone an important customer might request.
If you want to be a good product manager, make decisions for your users rather than giving them too many choices. As much as you want to be focused on the needs of your users, there’s a point where it’s just going too far. Is your target market really going to want a command line interface? How many options do users really need for personalizing their account? Do you really need 15 different ways to turn your computer off?
Every additional choice you push to the user is one additional feature that needs to be developed — requirements written, specifications created, designs produced, code engineered, testing completed. Choices are often added not because they are deemed appropriate based on knowledge of the market and the customers, but because the product development team doesn’t know enough about the market and the customers to make a decision themselves, so they figure they’ll just let the user decide. Next time you want to add a few choices for users, ask yourself if it’s because there is an identified need that this option is solving, or if it’s because you don’t know your customers well enough to know what they would prefer.
Yes, there are times when there are legitimate reasons to provide options to customers, but by taking a close look at why you’re providing those options, you’ll be less likely to add unnecessary work and complexity for both your product development team and your customers and end users.
Is this the reason why linux desktop can’t fly like windows? Linux have a lot of redundant programs sometime it takes a lot of time and headache choosing which email client, browser, or desktop (gnome or KDE or a lot more) is better. It is all there!
Thank you for lots of useful inputs. The articles here are very interesting. Now all I have to do is to become a product manager. 🙂
Good thoughts, Jeff. In my experience product teams can get caught up in design for boundary cases. We’ll include product capability for every conceivable situation no matter how rare. I’ve heard of features being used more internally during our testing phases than in live products. But there they are – features that no one needs in our products.
At a previous company we had threshholds for things like browsers and plugins. It was around 94% (or 96%?). So if 94% of our target population had Flash x.x installed, we could design for that version of Flash. In my current position, we design to any thresh hold, even for fractions of a percent.
There has been some good research recently on the number of features to include. Just Google “feature fatigue.” Basically, more features help sales, but hurt long term usability and product satisfaction.