Feature vs. Benefit. Tell the difference.

This experience blew my mind. It brings a completely new light towards building software. However, it sets software in a new context that few developers might appreciate.

I remember the first time I created a business model canvas at university. All the boxes seemed intuitive. I thought about it and filled it. It was nice to have everything put on paper. But nothing more. I shrugged and went back to building software.

Some years later, I worked on a different piece of software. I struggled with the feature scope and whether users would use it. Finally, I approached my product coach colleagues and asked them for their advice. After all, they have product in their title, and I'm trying to build one. Let's see what they got.

They asked me why don't you go for a business model canvas. Aww, cute. I already did that and have it in my head. But surely I can put it onto paper, and we can talk about it, no problem. Boy, I was so wrong.

I created the desired document, and we (Mathias and I) discussed it. Most boxes were okay-ish. They align to some levels with similar business models and ideas. Then we came to the centre, the most important piece: value proposition. I explained what great features it has. Many visualisations and insights are based on the data. But somehow, he wasn't satisfied with my answer. He kept asking what he could do with it. And I'm like, obviously, you see more. Don't you see how nice they are and how they look? Mathias: Yeah, that's nice, but what can I do with it?

It felt like I was standing in front of a wall. He said you have to go five more meters. And I'm like, no way, don't you see the wall?! Him again: five more meters, please.

Finally, he approached his point from a different angle: As a user, what do I want to achieve? How does it change my current workflow? How is it better than before? What is the current problem that makes it difficult for me? How does your proposed solution solve it? And why do you think your proposed solution is the best fit?

Uhm. Good questions. I never thought about it this way. Indeed, I thought about these points, but my gut told me it would work. Or logically thinking it through just made sense. So, I proceeded to see if I was right.

But here is the bummer: Answering the questions above is key to product adoption. Without a clear and validated concept, you just have a coding exercise. But no digital product.

It's like my parent's generation doing crossword puzzles. It entertains, and you might learn something. But the execution won't bring you any further in a business context.

Returning to my insightful conversation with Mathias, he asked me further: How did you validate the data you wrote there?
Me: Wait, what? Validation? Surely, I know what I’m doing.
Mathias: But how do you know that users will use it?
Me: Oh, great question, thank you for asking. Something I’ve always asked myself and struggled with.

I only knew if the product worked when I invested a lot of time building and shipping the software. Mathias helped me understand: There are many approaches to validate ideas before you invest time in software. Again, it was very eye-opening. But I’ll keep this for next time. Let me know if you’re interested: [email protected].

Feature or benefit? #

My problem resided in a subtle but significant difference. As engineers, we think in features. We figure out solutions and consider how to build something. But do we know their benefits?

Here is an example differentiating between a feature and a benefit of a rain jacket:

• Feature: Waterproof material with a hydrostatic head rating
• Benefit: Walk through the rain for three hours. Stay dry and comfortable.

Another famous example is the iPod:

• Feature: 5 GB storage capacity, unique scroll wheel controller (Source)
• Benefit: 1,000 songs in your pocket.

From these examples, we learn:

Features are the characteristics or functionalities of a product. They describe what the product can do or what it is made of.

On the other hand, benefits refer to the value that users derive from those features. They answer the question, "What's in it for me?"

In essence, features are what the product has, while benefits are what the user gains from those features.

Ok, got it. But why bother about benefits?
Coming back to our rain jacket example: You can achieve the same benefit with other things than a jacket. Like a rain poncho or umbrella. You could use a different waterproof material. All of those are features. Some features might work better than others.
But in the end, users care about the benefits they receive. Your product competes against others with the same benefits, no matter the features.

Value proposition in a nutshell #

The difference between features and benefits is crucial for the value proposition:

A value proposition articulates which customer needs a product fulfils better than the available alternatives.

In other words, it highlights the key benefits for users.

A famous example is Amazon. They aim to be the best in these trades:

• low prices,
• large product selection,
• fast delivery,
• convenience.

These are the things customers look for when purchasing goods. Compared to alternatives like brick-and-mortar stores, customers can

• enjoy the convenience of shopping from the comfort of their homes,
• access a vast array of products,
• find better deals than traditional retail options,
• get products delivered to their doorstep within short timeframes.

Benefit misconceptions everywhere #

Why do I tell you that? Due to my work, I'm often faced with new projects. It turns out they have business model canvases, too. Great, let me see them. Looking at it, what do I see? Features in the value proposition, damn.

On top of that, it often results from a brainstorming session (like I did). So, no validation happened yet. Using this idea as an investment baseline for software is risky.

I learned from my experiences (as the one above): Think of your ideas as a hypothesis. Validate this hypothesis with easy-to-set-up experiments. Keep them as simple, fast and cheap as possible. The data you gain shows if the hypothesis is correct. This approach provides earlier customer feedback and reduces investment risk.

Uncover benefits of running software #

When jumping into a new project, I often face already-running systems. As a newcomer, I want to know why some components exist. It helps me to

• understand and focus on customer and business value. A prerequisite for being effective.
• understand the benefits. It offers an infinite space for solutions. A prerequisite for creativity and innovation.

When I ask engineers what their system is used for, they talk for ages about what it does. But these are the features. How can I get them to talk about the value users receive? And this without explaining the concept or making them read my article first?

John suggests to ask engineers: Why don't we shut the component down? Or at least consider what would happen if we did: Who would this harm? What would be the problem for the business? What problems would we need to solve another way?

Talking about these questions shifts the conversation from features to benefits. It helps to understand what value a component adds.

Your engineering career depends on it #

I assume you earn your money with software engineering. You are interested in progressing your career and tackling more interesting technical issues.

Keep in mind: You could build the best piece of software. When nobody uses it, it holds no value for the company and drives no revenue. You might be surprised when someone with sloppy software gets promoted over you. This person increases the company's value by delivering customers the desired benefits. If you don't understand your product's value proposition, your promotion to the next level depends on the people around you or luck.

Imagine your skillset is a megaphone. The people who hear the message from it might react, not care, or, worse, be mad at you. If you don't care about the message, your career could head in a direction you don't intend. You focus on reinforcing the message, which may make things worse. On the other hand, you can check that the message resonates with people. You own your career. All it takes is some basic knowledge and an interest in product management. If you do your job well, you will progress and take on more exciting challenges.

Conclusion #

There is a difference between features and benefits. Features are the functionalities of a product. Benefits refer to the value users receive.

For humans, software is a feature, not a benefit. Therefore, it is a means to an end. It might help you to get the value you want. But remember, users always ask what they gain, no matter the features.

When you need clarification about the benefits, ask product managers. Figuring out what to build that brings users value is product discovery. It's their area of expertise.

To understand more about product management, look at the Product Map.