Product owners: don't make feature decisions.
Let’s have a talk about features of software products within enterprise organizations, and how product decision makers should define and decide on products not as features, but as user scenarios.
First, a bit of psychology.
Our brains are flawed, and flaws drive our behavior.
When someone, like a customer, communicates an idea to you, like a feature, it’s mentally and psychologically hard to let go of it.
This is because the human brain chemically and electrically operates to remember things in easy ways. It takes the idea, makes an icon of it, and that becomes the manifestation of your learning.
This is directly seen in how people draw. Often, people draw icons of what they have learned. In contrast, artists have trained themselves to actually draw what they see.
This remember-things-as-icons has benefits like making it easier to communicate, but it’s flawed because it leaves a desire to appreciate it as a piece of art. The icon isn’t beautiful, and lacks in depth and appeal of interest. Just look at the eyeballs.
The bottom line is that a tangible idea, this feature you’ve been taught, becomes part of your mental lexicon as an icon.
This is dangerous.
This is dangerous because these features (icons) are something you brain now uses to drive your behavior.
Yes, your ideas drive your behavior.
Pretty straightforward so far, right? Buy why’s all this psychological crap important? Let’s play this out some more…
From psychology to product-ology…
Your behavior has now been primed on a specific feature (icon) that you’ve learned. Let’s say the features (icons) are tables with filtering and searching capabilities. That means you are going to communicate to others via this feature (icon).
- Every product pitch that you give will include some ad-hoc image of a table with filter and search mechanics. In the eyes of people who you report to, you’ve now promised those features (icons).
- Every product demo you give will include some ad-hoc image of a table with filter and search mechanics. In the eyes of customers, you’ve now taught them to expect these features (icons).
- Every product story written will include some ad-hoc image of a table with filter and search mechanics. In the eyes of people who build the product, you have just defined the features (icons).
You’ve now taught all of these people, and likely your organization, how to think and behave in a feature (icon) focused way.
The Harsh (Un)Truth
It’s then a user experience (UX) professional walks in the room and tells you it’s better to think of the purpose and intent behind the feature, because there are other feature possibilities that may more effectively fulfill the user’s purpose and intent.
The UX professional has just told you that your icon (feature) is not artistic. It’s not beautiful. It lacks in depth.
Your whole mental lexicon castle is under siege.
You become defensive.
You’ve spent (how many?) hours pouring your soul into this feature.
It’s been woven into the language of customers.
It’s been woven into the fabric of your business case.
It’s been woven into the fabric of your product team.
It’s been woven into the fabric of your development team.
It’s now part of your reputation.
It’s your mental lexicon.
It’s your icon.
It’s your truth.
It’s hard to unlearn your truth.
It’s hard to unlearn the set of features (icons) that equates to your product.
It’s exponentially harder to teach someone else to unlearn these features.
(This is the job of a UX professional.)
“Why unlearn? I’ve got it right! My icons are beautiful!”
You’re in a role that makes decisions about what goes in a product. Great! Product teams need those people.
It’s your job to decide what is in or out of a product. User experience professionals, if they know better, will never challenge that. Your responsibility is to make decisions on what is in or out of a product, yes, confirmed, agreed, peace sign, champagne.
*But nobody said that it had to be features that are decided on.
(Actually, your organizational culture implied it through their implicit social norms, but that’s another story.)
This* is a nuance that your friendly, local UX professional should be talking to you about. It’s not that they’re challenging your position of decision making for what is in or out of a product. It is that they are telling you that there is a delegation of decision types that needs to take place for everybody to work happily together.
The bottom line: UX professionals don’t want you do define features (icons).
Seasoned UX professionals know that features (icons) are flawed. Features are not the foundation of great products. Understanding people is the foundation of great products.
It’s the job of the UX professional to help you, the product decision maker, to understand users, their purpose, and their context (UPC). Then, and only then, can you both take that information and find the best features to fulfill the purpose of the user given their context. A product is defined by those three things; not features.
The UX professional also needs to define the UPC so well that they can communicate this to all the people involved in making a product successful. They need to do this so well that you, a product decision maker, can easily decide on what users, purposes, and contexts are in a product, and which are out.
Here’s the plea from UX professionals to you product decision makers:
Don’t decide on features. Decide on user scenarios.
Switching your decisions away from features and to scenarios enables UX professionals to do what they do best: use their expertise to drive a divergent-to-convergent creative process, supported by user research evidence, that will identify the most effective feature(s) for any given scenario.
This is like taking the realm of billions of feature ideas and finding the precious few that will make your organization the most money, be grounded in what your development teams can implement, and also be the most desirable for people to use.
This is what everybody on your team wants.