An overly general design says to the world “We do not know who our customer is and how they will use this product.” Rather than doing the hard work of experimenting and making a choice when instead gave the customer many choices. Over generalizing makes your product both muddy and overly complicated. A friend of mine, Chris White, used to call overly general products an “Amorphous Morass of Human Insensitivity.” Have you ever used a product that was “powerful” but doing anything with it was very “complicated?” I mean so complicated that it hurt your brain? That product was an Amorphous Morass of Human Insensitivity.
Note that generalization is not bad thing it’s just that you need the right amount. A platform, programming language, or automation tool clearly needs to be more general than a photo sharing app. You will know you are crossing the line when you make simple task a little more cumbersome for a specific user in order to allow more fringe use cases that “might appeal to a larger set of users.” You might say “While 80% of our customers use workflow A we have a significant 20% of customers that use workflow B and C.” So your answer to this issue is to make your product model ALL workflows. How cool is that? It is totally customizable. No not really cool. You just made life more difficult for the 80% that use workflow A. You could have made something very intuitive and amazing for that 80%, but instead you chose to make something that is just kind of okay for everyone.
Over generalizing can also lead to feature bloat where you have many ways to do the same thing. This leaves your user wondering which way is the appropriate way to carry out a task. Now they have to think, do I use approach A or approach B, C, or D? Don’t give them lots of ways to do the same thing, invest in finding out the most intuitive way and give them that. Give them the right way to do things.
What is my product’s special purpose?
As an old-school object oriented programmer I always wanted to make my architectures as generalized as possible. If I was building an application for categorizing music I could see that I could build it in a way that allowed the application to categorize pretty much anything. Once you fall down this rabbit hole you start doing all kinds of crazy things. For example, you might make the workflow around categorizing music just a little more cumbersome so that it could also be applied to images or documents or “Hey, man” pretty much anything else you might want to categorize! How cool is that?!?” Not really that cool at all. “This architecture is so cool you can pretty much do anything you want to with it!” No, the architecture is sad. Very sad for those customers who wanted an innovative and intuitive way to categorize music.
Product designers and developers do this when they do not understand the unique purpose of the application they are creating. They don’t have 100% certainty that they have a good value and how to deliver that value. So they start adding in a bunch of unnecessary and overly general stuff. Creating few very well defined personae and context scenarios solves this problem. The culture should be that if a use case does not serve an agreed upon persona then it is not added and if a use case is not present it is not considered. If you have a compelling new use case that does not have a persona then you have a business decision to make. You are making a decision to appeal to a new customer or user. You are essentially going into a new market. Don’t do everything you “could” do. Find your special purpose but don’t be a feature slut.
You have to make choices
Let’s say that you have a systems management tool. You know that your users need a better way to manage their nodes. So you hypothesize that you should have a node tagging feature. Great. So far so good. While validating this hypothesis you find that one or two high profile customers really prefer hierarchical grouping for organizing their nodes. What should you do? If your answer is to add the ability to do both then you have answered incorrectly. Answering YES is a step towards creating an Amorphous Morass of Human Insensitivity. New users will wonder, should I use groups or tags? Every feature that targets nodes will need to be done with both “grouping” and “tagging” features. Not being able to say no is a lack of commitment that impacts your customers as well as your development effort. Now you’ve confused your primary customer and you have twice as much code for your developers to maintain. Forget about grouping and deliver a kick-ass tagging feature.
Product Managers love to add features when they don’t want to do the hard work of finding a specific and powerful value for their product. It’s much easier to create a backlog with a bunch of customer requests for “additional features” than it is to figure out the single strategic value and then put all the wood behind that arrow. In music it’s easier to riff on a theme than it is to create a new theme from nothing. But adding too many riffs or layers on a theme will eventually kill it. If you keeping adding features to your product you will eventually ruin it.
You Aren’t Gonna Need It and MVP
YAGNI (You Aren’t Gonna Need It) is a programming concept from XP that is just as important for Product Managers especially when trying to define your Minimal Viable Product. The more features you add without validation the more legacy features you will introduce into your product. The more features you add the longer it will take to release. The more features you add the more muddy you will make your value proposition. Pair down your backlog to just essential features and then take even more features out.
The famous example here is the iPhone. Remember that the first version of the iPhone did not even support cut and paste. As a product manager or owner, how many of you would have made that decision? I think very few. But as a result the iPhone came out quickly and THEN due to customer feedback the feature was added. Determine the features you need for an MVP and then take one away. Not having the so-called essential feature of cut and paste did not prevent the iPhone from being successful.
The first Kodak camera was created for one reason, to sell more Kodak film. However this camera was so simple that it caught on like crazy and transformed Kodak’s business. It was nothing compared to other cameras available at that time. All you could do was point it at something and click a picture. Then you sent the film into Kodak and they developed it for you. There was no F-stop, zoom, flash, etc. Sometimes fewer features give you a more powerful value. Always keep Instagram in mind. This product with very few bells and whistles beyond its primary value proposition sold for a freakin’ billion dollars. Holy shit! Some would even argue that it didn’t have enough features for its value proposition. Find out what features you absolutely need for an MVP and then take some away.
When you find yourself thinking that a product launch was not successful because some essential feature was missing remember the iPhone, Kodak camera, and Instagram. You are really just trying to make yourself feel better for not finding your product’s special purpose. It was not the lack of features that kept your product from achieving revenue goals. It was that you did not find a winning value proposition. Value, not features.
When you don’t have a clear value you need all the features in the world. When you have a well defined value you hardly need any features. If you find yourself adding a bunch of essential features consider if you really have figured out your value.