The term “product feature” can be used in many ways, but ultimately describes the characteristics a product has, what the product does, or may be used in the context of the product backlog.
For example, this post was written on a MacBook pro with the following features:
For example this post was written using Google Docs, which has the following features:
There are features that show up on your backlog. When the term “features” is used in the context of the backlog, it refers to placeholders that represent the work needed to add features as described above to your product.
With this in mind, it’s important to be clear about what you mean when you say “product feature”. To help bring clarity, here’s a look at what product features are, how they tie in with benefits, how you represent features, and how you incorporate features into product planning.
Dan Shewan defined product features as “A feature is something your product has or is… this is typically functionality offered by a software program that enables users to do something.’
The list of features for the MacBook Pro and Google Docs above match this definition. Features used in this way describe your product and help your customers decide whether they want to buy the product in the first place. You can look at the list of features for Productboard to decide whether it will help you with your particular product management challenges.
If you provide different versions of your product, you can use lists of product features to differentiate them. You can use varying lists of features for different versions to explain what each version does and does not have.
When you use features in this manner, you help customers who have already decided to buy your product decide which version they are going to buy.
You structure your decisions around features. You decide which features to offer, which features to no longer offer, and the order in which you provide or remove those features. When you make decisions about what to include, take out, or leave out of your product you think in terms of features, but you make those decisions based on benefits.
When your customers make decisions about whether to buy your product, they may look at the features, but they are really trying to decide what problems your product will help them solve. They’re trying to determine the outcome they’ll get from using your product. They want to understand the benefits they’ll receive.
Benefits are the outcomes or results that users experience by using your product or service.
Features represent outputs. They are things your team delivers in order to help your customers or stakeholders realize a specific outcome.
Start by building an understanding of the benefits your customers seek. Then identify the features your product needs and does not need in order to help your customers experience those benefits. Success comes when you express benefits in terms that your customers understand, and ties your product’s features to those benefits.
Productboard has identified these benefits that we believe potential customers are looking for. Our customers want to:
Based on that understanding, Productboard offers the features listed on our features page. As we describe those features, we indicate how they help our customers experience the benefits we identified. For example:
Understand what users need
Use the insights board to consolidate user research, feature requests, and user feedback streaming in from a number of sources. Spot trends and identify patterns that will help you prioritize what to build next and build it in the right way.
It’s helpful to keep this relationship between benefits and features in mind when you decide what features to deliver and in what order. The nature of the relationship between features and benefits helps you determine how to represent features.
The way you represent features depends on if you already know what you need to deliver the desired benefits, or if you are still trying to figure out the best way to provide benefits.
Sometimes you know what to deliver to provide your customers with the benefits they seek. Your product may be mature and you’re adding a feature that many of your customers have requested. Or you’re adding a feature to fill a gap with your competitors. You may be working on a B2B product that needs to have specific capabilities in order to be useful.
In those cases, the simplest thing is to represent your feature as it would be described on your features page. For example, you may explicitly call out PDF Export or Prioritization Matrix as features that you’re working on.
When you represent features as a solution, it’s easier to build a shared understanding of what the team is going to produce, and you have a concise label for the team to reference things in a discussion.
Unfortunately, representing features as a solution can lock your team into a specific solution. That might lead to solving a need that users don’t really have, or missing out on an even better solution to the real underlying problem
You’re never really sure of the best way to solve a problem when you first start out, so it’s best to represent features as needs.
When you express features as needs, you don’t describe how you’re going to accomplish an outcome, you identify what you want to accomplish. Instead of describing the feature as PDF Export, you describe it as I need to be able to share data with my boss.
When you describe the feature as a need, you leave your options open for how you’ll satisfy that need. You increase the chances for an innovative solution and your team is more engaged in delivering that solution because they have a say.
The downside to expressing features as needs is that it can be more difficult to establish a shared understanding about the features you’re working on. You may experience more uncertainty within your team as you try to come up with the right solution.
You may be best served by using both approaches. When you have a clear idea of the solution and it doesn’t make sense to do more exploration, define the feature as a solution. When discovery is warranted, describe your features in terms of needs.
When you are trying to decide what to include in your product and what to leave out, start with the outcomes you’re trying to realize. Use your organization’s strategy to filter the features you deliver. Communicate the results of your decisions on your roadmap.
Make sure you and your team clearly understand the benefits you aim to provide to your customers and then identify the minimal set of features to deliver to realize those benefits.
When you get a request from your customers for a specific feature, dig deeper to understand why. What problem will that feature help them solve? What benefit will that feature provide for them?
When you understand what your customers are really looking for and why, you can determine if the solution makes sense or if you need to explore further to find a better solution.
Just because you have customers asking you to satisfy a particular need, it doesn’t mean that it makes sense for your product or your organization.
You need to understand your organization’s strategy. Use that strategy as a filter to determine which needs to satisfy and which to ignore. Use that strategy as a filter to decide which features to deliver and which ones to ignore. Your organization’s strategy should be a north star for your product decisions.
Once you’ve decided to deliver a feature, it’s time to put it on your roadmap. This is your way to communicate the features you plan to work on and when you’re going to work on them.
Does that mean that your roadmap should be feature-driven? Not necessarily.
You should organize your roadmap around outcomes rather than outputs. Describe the benefits you want to provide to your customers rather than the features you’re going to use to provide those benefits.
If you drive your roadmap by features, you communicate specifics about what you’re going to deliver. This may be accurate in the short-term but could be far off in the long-term. If you want to avoid setting unreasonable expectations, you’re better off expressing the outcomes you plan to address in specific time frames without explicitly stating what features you’ll deliver to provide those benefits.
You may have specific features listed on your roadmap, especially in the near-term. The key is setting expectations at the proper level of certainty in each situation.
. . .
Productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, Productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a free trial of Productboard today.
