The Feature-Benefit-Value Conundrum

Are we actually creating value? Or are we simply building features? Are the benefits arising from these features actually valuable for our users?

I have spent the last 8+ years building one of the largest communities of teachers anywhere in the world. The last 4 of these 8 have heavily focused on creating a product that can help bring this community together and make their learning experience more meaningful. One principle that I have always held close to my heart is the principle of “Creating Value”. The concept of value is pervasive — it cuts across verticals, products, and industries. You might be building anything — a pencil, a notebook, an app, a website, a house, or even an aircraft — unless the actual consumers of the product find “value” in what you have created, it will be almost impossible for the product to take off.

What is value though? Is it the same as features that you and your engineering team have so diligently built? Is it the same as the benefits that your marketing collateral outlines for the product? Let’s break this down…

Features: Facts. Yes, if there is one word that could describe features, it is facts — real, concrete facts. Features are the results of your ideation, creation of PRDs, discussions with engineering teams, developments, UAT sessions, sprints, releases, and so on. To put it simply, features are the components or attributes of your product. It is not difficult to share features — a simple document will suffice for you to convey your feature lists and pipeline plans to others.

But are features enough for a product to sell? If it was, you wouldn’t need a sales or marketing team, right? The engineers and PMs could double up as the sales and people would start buying, wouldn’t they? Alas, that is not true…Unless you start assigning “benefits” to your features, they won’t sell — in fact, in a lot of cases, in the absence of a “proposed benefit” your users might end up assigning, in their own minds, a very different interpretation to a feature and trust me it happens more often than you think.

Example: A services company that employs say 50,000 employees and works across all major timezones. The fact that the company has 50,000 employees and works across time zones is a feature or an attribute of the company. When a company pushes this fact across, the company leadership would assume that prospective customer firms will be impressed by the size and scale. However, what could very well happen is that a not-so-big prospective customer might think that given the size, the service company is too big for them and if they do end up taking their services, there will be little room for any customizations/ dedicated support, etc.

Benefits: Benefits are what can help your users accomplish from the features you have built. You might have added a community “feature” in your app and your users can avail the “benefit” of interacting with other users using this feature. Or say you might have manufactured a pen — the benefit that your users will get from it is that they can write using the pen. As you can see from the services company example above, it is extremely important for you to list out the benefits that your features can deliver to your customers. Also, in case your product has a set of benefits, it is extremely important to have them all detailed out fully and this is typically done by the sales and marketing teams and ends up on the collaterals, emailers, and adverts.

Value: Value takes the concept of benefits a notch further. It is based on the alignment and the fit of your product’s benefits with their broader aspirations and goals. Different users might derive a different set of values from the same product and the same set of outlined benefits. Let’s take an example — sneakers — specifically Nike sneakers which use the Air Max technology. Since the concept of using air cushioning technology in a sneaker was introduced around half a century ago, Nike has churned out different silhouettes and consumers have just embraced them — some wear it for the sheer nostalgia, and some for the sheer comfort — that’s how people derive a different set of values from the same product.

Similarly, the community feature shared above, if built into a travel planning app may be used by a certain set of users to derive the value of discussing their travel plans to a certain destination that other members of the app might have already been to; for others, it may be an ideal place to post the photo dump of their last vacation and derive the value of getting attention in a peer group that shares similar interests.

Each individual has a set of different objectives and the value they hope to derive from a product is dependent on this set of objectives.

The relationship as we saw is in some ways progressive — features create a set of benefits which in turn creates value. However, a lot of us are often guilty of building features and then thinking of the benefits or value that users could derive from them. What can end up happening is a “bloated” product with lots of features but with little to no takers. It is important for us to understand the values that we would want consumers to derive and then based on that create a set of functionalities and features. Once you have zeroed in on the value you will aim at creating, you can then prioritize features using any of the popular frameworks out there (such as MoSCoW [my personal favourite], RICE, Kano Model, etc.).