A Primer to Feature / Product Fit
As a product manager, you need to ensure that your features don’t just move their own metrics; instead, you need to ensure that your features fit into the broader value proposition of your core product offering.
And, as a leader of product managers, you need to ensure that your PMs are building for broader business impact - not just within the area that you govern, but across the entire portfolio of products that your company provides to customers.
The way to ensure that our features actually provide value to our products is to use the concept of “feature / product fit” to evaluate whether we’re investing our time and effort into the right initiatives.
We’ve created a three-part guide to feature / product fit. In this first part, we define what feature / product fit is, and the consequences for what happens when product teams fail to take feature / product fit into account.
In our second part, we’ll then discuss how product managers can prioritize initiatives with feature / product fit in mind, and we’ll also share techniques for finding and measuring this fit.
In our third and final part, we’ll conclude by sharing two real-world examples to help illustrate the concepts of feature / product fit.
So, let’s start by defining what “feature / product fit” means.
The definition of feature / product fit
What exactly is feature / product fit? Well, here’s an excellent definition for the concept of “feature / product fit” by Casey Winters, Chief Product Officer at Eventbrite:
“The feature has to retain users for that specific feature, the feature has to have a scalable way to drive its own adoption, and the feature has to improve retention, engagement, and/or monetization for the core product.”
That is, there are three core aspects to feature / product fit:
The feature must be able to gain users on its own
The feature must retain users on its own
The feature must drive business value for the broader product
The best product teams evaluate their initiatives on all three aspects, and they won’t hesitate to terminate features that do not drive value for the broader product.
As a rule of thumb, you can qualitatively determine whether or not the feature fits the product by considering the feature’s value proposition vs. the product’s value proposition.
If you have a feature that actively negates the product’s value proposition, you’ll confuse your customers and end users (even if it’s a good feature on its own). Therefore, features that don’t align with their products don’t demonstrate feature / product fit.
As a reminder, value propositions are a bundle of benefits and costs targeted at a specific audience. Your feature’s value proposition is not necessarily the same as your product’s value proposition, and so you need to ensure that you have alignment between the two.
Here’s an example of conflicting value propositions. Let’s pretend that our product is a CRM that serves for-profit companies.
If you launch a new non-profit module in your CRM to help manage donors, you don’t want to pitch that non-profit module to for-profit companies.
For-profit companies don’t need to manage donors. Pitching this new module to them will cause them to question your expertise in the for-profit CRM space.
So remember: just because you can pitch a new feature to all of your current customers doesn’t mean that you should do so! Rather, you need to consider how the feature fits the product, and use that knowledge to position your feature accordingly.
The symptoms of feature / product mismatch
What happens when we ship a feature that doesn’t have feature / product fit?
Well, it’s quite possible that the feature itself has really excellent feature metrics, such as retention, engagement, referral, and monetization.
In fact, this feature might even have rave reviews from customers and have excellent media coverage!
But, when a feature doesn’t line up with its product, it will cause the product to actually wind up losing value in a couple of ways:
This feature could be cannibalizing value from the broader product, or
This feature’s value proposition conflicts with the broader product’s value proposition, causing confusion and lack of adoption of the broader product
A feature that is misaligned with the broader product will drive a negative correlation in success metrics. As the feature becomes more successful, the overall product becomes less successful.
While this concept may seem like common sense, many product teams wind up failing to meet the three criteria of feature / product fit when it comes to shipping new functionality.
Why is that?
Well, this problem happens when product teams have devolved into “feature teams,” where they’ve lost sight of the broader business objective and have focused too much on their own immediate metrics.
When product teams turn into feature teams, the company suffers. Let’s walk through this phenomenon in more detail.
The problem with feature teams
Every product created by a for-profit business needs to serve a business purpose. Therefore, every feature built within a product must also serve a business purpose.
Features typically contribute to the business in 4 different ways:
Create business value for new kinds of customers (business line launch)
Create net-new business value for existing customers (new feature launch)
Improve the current business value for existing customers (product optimization)
Increase the number of customers who receive the current business value (growth)
No matter what, your initiatives must move business metrics forward.
But, many times, product teams focus too much on their own individual metrics and lose sight of the broader business.
I’ve seen this phenomenon happen at companies of all sizes, ranging from scrappy startups to multinational giants.
When product teams forget to build their features around the broader product portfolio and the business, they devolve into feature teams. They solely focus on their own self-defined metrics without aligning their work against the company’s mission.
The worst part? In the short run, working in a feature team is quite fun.
You get to set your own metrics without considering broader business constraints, and you get to build all sorts of exciting functionality that make sense within your scope.
You don’t need to worry about coordinating across other feature teams, because their metrics don’t matter to your metrics.
Product leaders will typically see that morale sharply increases in the short run when product teams turn into feature teams, because it’s so much “easier” to get things done.
The problem? The things that are getting done don’t actually matter to the company.
Over the long run, feature teams start to hollow out the value of the broader product.
As each feature team builds in a silo, the overall product becomes more fractured and disorganized over time. This leads to an overall loss in retention and monetization for your company.
As the company struggles, it invests further into feature teams that are masquerading in name as “product teams.” These feature teams then cause further value destruction and ultimately lead to the company losing its leadership position in the market.
How do we know when product teams have turned into feature teams? We can look at the following problems that arise when product teams are operating as feature teams.
If we find the problems below occurring, then it’s a good signal that we’ve strayed away from product management and towards feature management.
Common pitfalls for feature teams
You’ll remember above that we identified three core aspects that features need to have to demonstrate feature / product fit:
The feature must be able to gain users on its own
The feature must retain users on its own
The feature must drive business value for the broader product
By considering the flip side of these aspects, we can quickly see that there are three common pitfalls that feature teams run into:
The feature steals users from the broader product
The feature forces retention from the broader product
The feature fails to provide business value for the broader product
Let’s talk about these three pitfalls in more detail.
1) The feature steals users from the broader product
In this failure mode, feature teams maximize the inbound traffic to their feature by cannibalizing traffic from the broader product.
They might send notifications to all users that this new feature has been released, without any context about how this feature helps make the broader product experience more valuable.
Or, they might pop up a modal on user login that forces the user to look at the feature, interrupting the original workflow that the user was going to take in the broader product.
As you can imagine, in this failure mode the feature team will quickly see an increase in its own user base, whereas the broader product will start to suffer in terms of user engagement because users are confused by this new feature.
To be clear, notifications are valuable for product teams. The problem is when users are simply notified that “a new feature exists” without clearly demonstrating the feature’s value within the broader product portfolio.
2) The feature forces retention from the broader product
In this failure mode, feature teams maximize their own feature’s retention (e.g. weekly active users) by using the broader product as a crutch.
As an example, they might bake the feature into a core workflow within the broader product, which then “looks like retention” but is actually creating noise for the broader product and decreases the product’s overall retention.
An excellent real-world example of this is Pinterest’s “like” button. At one point in time, they had both a “like” button and a “save” button.
Pinterest “like” button (Vox, 2017)
Of course users would try the “like” button! After all, it’s the first button they see on the left-hand side.
But it decreased the product’s overall retention because “it created confusion and clutter in the product” (Casey Winters). That’s why this feature had to be deprecated, because it was destroying value in the broader Pinterest product.
Another problematic setup that feature teams might use is that they set up the feature as “opt-out” where all users must work with this new feature unless they disable it.
But, when they set up this opt-out feature, they fail to onboard the user onto “why this feature will make the broader product experience more valuable.”
In this second failure mode, they will see lots of “short-run retention” for their functionality and declare victory. But, what they’ll fail to see is that the broader product is now losing retention because users are being forced into features involuntarily, where they didn’t have the time to internalize the value of the new feature.
Again, the point here is not that “opt-out functionality” is always bad. There are many excellent scenarios for using opt-out paradigms for releasing features within products.
Rather, the point here is that we shouldn’t force features onto users without clearly educating them on two key points: 1) how the functionality works, and 2) how this feature creates net-new value for them within the broader product.
If the feature is just cannibalizing value from the broader product, then it’s just not the right thing to ship.
We should aim to maximize ROI from our initiatives. We don’t create new value in the world by simply moving value out of the product into our own features and declaring victory in our own metrics.
3) The feature fails to provide business value for the broader product
In this failure mode, feature teams simply maximize their own metrics and fail to ladder their initiatives back into business value.
Too frequently, I see feature teams set up north star metrics that have no real impact on the business. Instead, they’re focused solely on the feature set itself without any broader implications on how it drives forward the company’s core value generation hypothesis.
For example, say that a feature team aims to maximize “time spent on platform” by trying to digitize every possible workflow that a customer has within a particular problem area.
But maybe your company’s value proposition is not “a mile wide and an inch deep.” In other words, maybe your company’s position in the marketplace is that it has deep expertise in a narrow area.
Perhaps your leadership team has already set the value proposition of the product to be “an inch wide and a mile deep,” with strong integrations into the products of partner companies.
When you try to maximize your north star metric of “time spent on platform” by rebuilding everything in house, your company starts to look unfocused.
Your partners will be alarmed that you’re trying to push them out of the ecosystem, and your customers will lose confidence in your company’s ability to specialize and delegate.
So, we can now clearly see the kinds of behaviors that feature teams might engage in, and why product teams should ensure that they don’t fall into the trap of becoming a conglomerate of unrelated feature teams.
On that note: if you’re looking for targeted, personalized advice on how to pivot away from feature management, consider booking time with our PM career coaches.
Turning feature teams back into product teams
The way to fix this problem is not to hire more engineers and designers, nor is it to hire more product managers or product leaders. After all, building more features doesn’t help to defragment the overall product offering.
Rather, the way to fix it is to retrain and realign all feature teams back into a product team mindset: to focus on shipping high ROI initiatives for the business that are well-aligned with one another.
While it takes more overhead and coordination in the short run, it drives more sustainable value in the long run. And, using the criteria of “feature / product fit” will help us get there.
In our second part of this guide, we’ll share exactly how product managers can pursue this fit in their processes - ranging from prioritization to user research to measurement.
Thank you to Pauli Bielewicz, Siamak Khorrami, Goutham Budati, Markus Seebauer, Juliet Chuang, and Kendra Ritterhern for making this guide possible.
