How to Avoid a Feature Factory Mindset And Become a Successful PM

‘Feature factory’ is not exactly a positive term, especially if you’re aspiring to be a product-led SaaS product management team.

This article explores what the ‘feature factory’ mindset is and what the signs you might be working in such a company are. We also look at what product managers can do to avoid falling into the trap.

Ready to dive in? Let’s get to it.

What is a feature factory?

‘Feature factory’ is a pejorative term referring to an organization whose main focus is on shipping features and products without ensuring they satisfy genuine user needs.

Instead of focusing on adding value to the product, such companies prioritize generating hype through new releases, no matter how short-lived it is.

Where does the term feature factory come from?

The metaphor ‘feature factory’ was coined by John Cutler.

It was inspired by his software developer friend venting off his frustrations with the processes at his company.

He compared it to an assembly line whose sole objective was to churn out copious amounts of code without caring about product innovation or solving user problems.

Signs you’re falling into the feature factory trap

What are the warning signs your organization might be falling into the feature factory trap?

Feature factories focus on quantitative outputs vs qualitative outcomes

The first indication might be excessive focus on delivering quantitative outputs over qualitative outcomes.

In many software companies, the product development process is organized around delivering as many features as possible. Measuring a team’s performance in such a way means they stop caring about improving users’ lives.

As a result, testing, feedback collection, or incremental innovation, which are the foundation of product-led growth, end up on the back burner.

Obsessing over key performance indicators vs value delivery

Feature factories share another characteristic: they pay too little attention to delivering value and too much attention to their chosen key performance indicator.

Obsessing over KPIs has the same psychological foundation as feature obsession.

It’s relatively easy to put together a fancy product dashboard to track all the imaginable metrics we believe to be important. It gives us a sense of control and allows us to show quick progress.

Not validating and prioritizing customer requests

There is a misconception that it’s necessary to give customers whatever they wish to keep them satisfied.

All you have to do is gather user feedback and requests and deliver whatever feature they wish.

Doing so without understanding what user pain points the feature solves or without validating whether there’s actually enough demand for the requested functionality is a recipe for disaster.

How a feature factory mindset hurts products

Allowing your SaaS to fall into the trap will usually come back to bite you. If not immediately, then definitely in the long run.

Minimum overall value delivery capabilities

To satisfy user needs, we first need to analyze them and then iterate extensively to find the right solutions.

This takes time that many feature factories are unwilling to invest because it slows down the shipping.

However, this is a very short-sighted strategy.

Initially, customers may get excited by the shiny features but if the product offers no value, the customer satisfaction metrics won’t stay high for long and they will eventually churn.

Product parity trap and no product differentiation

It’s easy to build features but it’s equally easy for your competitors to copy them.

Whether you copy your competitors’ features or they copy yours, the result is the same: a parity product that doesn’t stand out from similar offerings on the market.

And if all products are the same, price becomes the only differentiator. This is a war that’s very hard to win because even if you manage to undercut your competitors, the damage to your revenue can make it unsustainable.

Poorly implemented features are the main outcome of feature factories

Another consequence of the feature factory mindset is badly implemented and buggy products with lots of UX debt.

Rushing to meet the deadline, sometimes agreed upon arbitrarily by the sales team, doesn’t leave enough time for quality assurance.

This is particularly difficult if there are a number of features developed in parallel and stretching the organization’s resources.

Product bloat and UI/UX friction

Building too many features leads to product bloat.

Bloated products can potentially solve lots of problems, but none of them well enough to be competitive and that’s the first issue.

What’s even worse, such products are complex to use because we need to squeeze all the features into the UI which makes it cluttered and difficult to navigate.

This creates friction, which increases the time to value, and has a negative impact on user success and satisfaction. Just the opposite of what we aspire to.

How to shift from a feature factory and build better products

How can you avoid turning your business into a feature factory with all its nasty consequences?

Prioritize product vision

A good product management team builds features that follow the product vision.

Having a clear idea of where the product is heading gives a clear focus.

This means we’re more likely to prioritize features that help us achieve our goals and less likely to be distracted by motions that are not aligned with them.

Use the North Star Framework

Using the North Star framework will help you select that one single metric that will measure the effectiveness of your team in realizing organizational goals.

What metric you choose will depend on the product and the stage of its lifecycle. This could your revenue growth (Notion) or the number of collaborative whiteboards created by users (Miro).

Whatever the metric is, it plays an important role. Just like product vision, it guides the team and gives the focus necessary to develop the product and drive customer value consistently.

Practice continuous discovery

Continuous product discovery and tools like opportunity solution trees allow the team to ensure that they are constantly working on solving genuine user problems.

If the customer needs change, so does the focus of the team.

What’s more, the approach helps keep the problems, solutions, and organizational goals aligned.

Use product usage data to guide decisions

Tracking product usage data helps us look at customer feedback and requests more objectively, and validate them.

As we are looking at user behavior patterns, we may be able to use that users are asking for features because they don’t know how to take advantage of the existing functionality.

This means we should focus on onboarding and improving usability instead of developing new features.

Tracking which features are most popular with certain user segments also helps teams make prioritization decisions. By looking at product usage heatmaps, like the one below, we can see which features deliver the most value and focus on developing them in the future.

Focus on incremental innovation

Once we know which features we need to develop, we should try to improve them in small increments and frequently.

After every release, we should collect more data, and use it to inform future iterations. By proceeding in such a way, we’ll be able to quickly assess the impact of changes and deliver noticeable improvements.

This is just the opposite of what happens in feature factories, where big batches of features are released at long intervals without any customer input in the meantime.

When customers finally see the product they often realize that it’s not exactly what they need which leads to further delays and costs.

Test before you build

Before committing to build a feature, validate the idea. This will reduce the risk of building unwanted features that nobody will use. It will also improve the quality of the solution you develop.

You can validate initial ideas by reaching out to your networks and assessing their response or start a crowdfunding campaign to see if people would be ready to invest in the product.

If this is the case, you can move on to build prototypes, starting with low-fidelity ones, like fake door tests.

Even high-fidelity prototypes shouldn’t cost a lot. Trying to leverage existing solutions and hack them to deliver the functionality you’re planning to develop is one way to do it.

Each iteration of tests is a great opportunity to learn and improve the feature. As result, we increase the chances of launching an attractive product.

Test before you launch

Robust features are beta tested. This is for two reasons.

First, it allows teams to identify all the bugs that can sneak through the sieve of their QA.

What’s more, it reduces the risk if things go really wrong. That’s because we expose our product to a fairly small number of users. And if we target the innovator and early adopter groups, they are way more forgiving than the general public.

Having said that, it’s important to use beta testers that are a representative sample of the target user segment for the feature. Otherwise, we may get a very different response from users once we launch.

Make customer satisfaction metrics a must

As soon as the product is out, we need to start collecting data on its performance. Our ultimate goal is to bring a positive change to users’ lives, so our focus should be on customer satisfaction metrics.

Our objective is to compare expected benefits to how the customers actually feel about the product.

What tools do we have at our disposal to measure customer satisfaction? Customer Satisfaction Score (CSAT), Net Promoter Score (NPS) and Customer Effort Score (CES) surveys are the classics. They each measure user satisfaction from a different angle, so it’s best to use a combination of them.

Sunset features when needed

If we made solid data-driven decisions to guide feature development, there’s a chance that the feature will keep bringing a lot of value to our users.

However, no matter how successful the feature is, there may come a time when we need to sunset it.

What are some common reasons for that?

Dramatic market and customer need shifts are one. Or we may simply have a better solution available and the old one becomes redundant.

Whatever the reasons, our job is not to miss the right moment to do. By pulling the plug at the right time, we can divert the resources to motions that will drive more value for the customer and the business.

Conclusion

Feature factory-style development of large numbers of features without ensuring they serve a purpose doesn’t drive product-led growth.

To build a product that speaks for itself we need to focus on delivering functionality that satisfies user needs and solves their problems. This needs to be based on robust product and customer discovery and empirical evidence.

If you want to see how Userpilot can help you avoid falling into the trap and build a product that really makes a difference, book the demo!