Feature Creep Isn’t the Real Problem

When you open HubSpot’s dashboard you’re hit with a ton of stuff:

Critics think HubSpot has succumbed to feature creep. But, HubSpot’s product is intentionally robust; it promises to be the one-stop shop for all of your marketing and sales needs. The complexity of the product isn’t a vice or something to streamline. Quite the opposite: HubSpot’s product delivers on the value it promises to customers.

“Feature creep” has become one of the dirtiest terms in the product management world. When companies notice that they’ve added a ton of features to their product over time, they automatically wonder if they’ve fallen victim to feature creep.

Sometimes, products become more complex out of necessity. But if you suspect your company really is struggling with feature creep, then here’s what you need to know: it’s not the root problem, but rather, a symptom. When you’ve got a bunch of features that don’t improve your product’s value, dig beyond the concept of feature creep to figure out why.

The myth of feature creep disguises the real problem: the inability to execute on the core value of your product.

Diagnose the real problems beneath feature creep

A simple product isn’t always the way to deliver your value. On the other hand, fixing a confusing product isn’t always as straightforward as cutting out features. Instead, you have to look at what drives a company to keep adding to the product without subtracting what doesn’t work.

Why do companies end up building unnecessary features in the first place? Over time product organizations grow more complex with different teams and stakeholders, which makes product management more difficult. Your customer base also evolves, which means you constantly have to think about how you’re executing on value for customers.

When you think you have feature creep, you’re really experiencing the manifestation of a few root problems:

1. A team can’t execute on delivering its core value to its target market. The customer segment demands value that the team isn’t capable of delivering. As a result, they build things that aren’t aligned with what customers actually need, and instead accumulate useless features.
2. A team builds their product via development by committee. Everyone has a little bit of input, but incentives for individuals and teams are misaligned and not related to customers’ needs. This leads to a collection of features that aren’t tightly tied to helping customers achieve their goals.

Let’s take a closer look at the underlying problems that are often mistaken for feature creep—as well as a few solutions. We’ll explore how you can execute on delivering your product’s core value to different customer segments, as well as how you can organize your team around customer-focused incentives to avoid development by committee.

Build for different customer segments while delivering on product vision

“Product vision is the dream. It’s how your company changes the world…It’s the state of having solved a problem for a user or providing an experience for a user.” – Tom Tunguz, VC at Redpoint Capital

If your company is building unnecessary features, it may be because you don’t know what your market demands.

Product vision should push you to build around what customers need to accomplish their goals. But what makes this challenging is that as you grow, you gain customer segments—startup, SMB, and enterprise—with different needs. You may even have different teams building for each segment.

It’s easy to build out a couple of useful features for each segment that aren’t relevant to the overarching product vision and the customers as a whole. Simply tacking ad hoc features on in this way can create product bloat. Instead, if you strategically target different customer segments who can benefit from your product’s core value, you can conscientiously and deliberately evolve your product’s offerings to meet those demands.

If many customer segments show a need for your core value, thoughtful expansion can really help you grow. For many companies, not expanding to support new customer segments can actually be harmful. To understand this, just compare Trello and JIRA.

JIRA began as a simple bug tracking tool for developers.

 From an early version of the Atlassian site for JIRA.

Over the past 15 years, JIRA has evolved into a packed product management suite. The company has built out a variety of features that add value for different segments, but all of them ultimately tie back to the product vision of tracking and managing teamwork.

JIRA has evolved to create a cohesive product with specific plans for teams of all sizes.For example, JIRA includes features like:

• The ability to distribute specific tasks and track individuals’ work, which is really useful for very small teams
• Disaster recovery features and fully-fleshed security permissions, which are critical to large enterprise teams
• The option to customize workflows, which is valuable to teams of any size

Contrast JIRA’s growth with Trello’s development. As JIRA became more complex, Trello emerged as a lightweight alternative. But, the company failed to develop for different use cases and couldn’t figure out how to deliver a cohesive product vision for different segments. Trello wasn’t growing as quickly as they wanted to, and they were eventually acquired.

In comparison to Trello’s simplicity, it looks like JIRA fell prey to supposed feature creep. But it did quite the opposite—the team identified use cases they could monetize while delivering on the same product vision to every segment.

To avoid accumulating irrelevant features, be clear on what your product is and how to best deliver it to a particular segment. Here are three ways to make sure you’re doing that:

1. Use an empirical litmus test for features. This test should be a framework for determining how relevant a feature is and how well it helps a user in a given customer segment accomplish the goal of your product vision. A framework like Google’s HEART test works well for this. It encourages you to measure users’ Happiness, Engagement, Adoption, Retention, and Task Success as it relates to a particular feature. These measurements force you to think critically about whether a feature is relevant and helpful to your target customer segment(s).
2. Deny feature requests. Not all of them, but some of them. For example, Basecamp openly denied adding Gantt charts to their product, even after a user wrote an angry blog post, because founder Jason Fried believed that he and the user had “different opinions of what is required for good project management.” Staying focused on your product vision means scrutinizing every feature request (internally and externally) to decide whether it adheres to your company’s ideology around product development.
3. Don’t assume feature creep if you promise benefits from a robust set of features. Consider two API companies, Clearbit and ipinfo, that have very different promises to customers and consequently very different offerings. ipinfo promises users the ability “to quickly and simply integrate IP geolocation into your script or website.” As a result, it offers a single API that does just that. On the other hand, Clearbit’s promise to customers is “to build business intelligence APIs.” Its current collection of APIs for markets, salespeople, and developers don’t indicate product bloat—rather, they indicate delivery on a different promise.

This kind of building process may result in many features—or it may result in few features. The number doesn’t matter. What’s important isn’t quantity, but relevance and effectiveness for different segments, as well as for your overall customer base.

Organize your team around customer-related incentives

If, when looking at your product, you see a mess of unhelpful features, think about who is contributing. You’re doing more harm than good by letting everyone have a say.

On a team of any size, it’s common for a lot of people to have different opinions about the direction of the product. There may be pressure from several directions, such as:

• External demand from investors and stakeholders to make additions that have a good chance of being lucrative for the business
• Individuals on marketing and sales teams who want to work towards quarterly revenue goals under the direction of their managers
• Designers and developers who are listening to customer feedback and trying to build a solution for every single customer request and complaint
• Individuals who are more focused on their own vision of the product, rather than what would be most helpful to the customer

All of the differing opinions can quickly drive a team crazy. One team may be working on a document editor because the stakeholders wanted it, while another is working on a search function because their manager wanted it, but neither knows what the other is doing—or why they’re doing it. As a result, product development slows and stalls because no one is in sync.

I’ve personally experienced the harm that design by committee can cause. My Crazy Egg co-founder Neil Patel and I took a million-dollar hit because we built something based on “design by committee.”

After building Crazy Egg, we tried to create a shared hosting platform similar to Media Temple’s Grid System that we called Vision Web Hosting.

Too many cooks with different motivations plagued product development from the beginning. Building progress was slow and launches kept getting delayed because everyone wanted a say. We struggled to build a lot of features that didn’t directly relate to making shared hosting easier for our customers.

This eventually took a toll on the product and the team. The product never got a chance to see the light of day. We were forced to shut down the project after two years and ended up losing over $1 million in the process.

Vision Web Hosting was a team of five, including Neil and myself. I learned that even a handful of conflicting opinions are too many. In bigger organizations, it’s even harder to structure and align product incentives unless you make a dedicated effort. It’s easier to let organizational discipline fall by the wayside. Here are three ways you can ensure your team is aligned, no matter the size:

1. Set goals at different levels, and make sure they line up to an overarching product vision. Google has an internal grading system in which team members set individual OKRs, while the CEO sets OKRs for the entire team. Team members set a big picture goal for their own work and identify quantifiable results that will build towards that goal, and the CEO sets goals and quantifiable results for the whole company. Team members are then evaluated on how they complete the steps, while management is evaluated on how well the team does. This provides alignment across the team and sets clear accountability and ownership in place for different tasks.
2. Make sure everyone has the same understanding of what you’re building. Even if you set common goals, all team members should understand why they’re working toward those goals, and how each of them will make the product better. This requires that everyone has a common understanding of how the product works—and you can’t assume everyone is already on the same page. Instead, lay out the internal mechanisms of the product in a way that is accessible the the whole team, like Intercom did for their message delivery system. A deep, shared understanding of the product helps team members connect their goals with creating a better product that actually helps the customer.

Make your roadmapping process transparent. The entire team should be able to see what’s coming down the pipeline so they can use it to inform their work. At the same time, having a concrete and transparent plan protects against ad hoc changes that slow development. You can use a tool like Asana to communicate clear incentives across the team that will inform the product roadmap. You can also use a tool like Airtable to map out your development pipeline.

It’s unlikely that you’re going to completely eliminate external pressures. But you can control what drives product development within your team and make sure everyone is working on discrete but cohesive tasks. You need to structure your team so that everyone has common incentives, and evaluate each individual and team on how well they make progress toward those goals.

Strong vision and the structure to execute

To build a relevant product for your users, you don’t have to “manage feature creep.” That’s like saying to avoid getting sick, you should manage your runny nose. The problem already exists. Feature creep is just a symptom.

Instead, get to the root of feature creep by managing and solving the deeper problems your company is likely running into.

The first step is to make sure your product executes on value for a given customer segment—this is your product-market fit. I recently conducted a sample product-market fit analysis for Slack to show companies how to survey their own customers for fit.

This survey, based on Sean Ellis’s definition of product-market fit, is a good place to start when you want to make sure your product is providing customers with the value they want and need. In Slack’s case, the words that customers most used to describe Slack’s value in open-ended responses were “communication” and “team.” These both tie back to Slack’s promised value to customers—to “bring all the pieces and people you need together so you can actually get things done.” It demonstrates good product-market fit and delivery on core value.

Here are some next steps for executing on your product’s value: 

• Understand which customer segments could benefit from your product’s core value, and how their demands fit into your product’s overall goal.
• Use a consistent and stringent framework to evaluate new features for all customer segments. This will prevent you from creating a bunch of unrelated features.
• Make sure your team has shared customer-centric goals, and is structured in a way that incentivizes the people who directly impact product development.
• Make your product roadmap accessible to the whole team so everyone understands why you’re working towards those common goals

You won’t win by obsessing over feature creep—you’ll win by addressing the real underlying problems. When you’re focusing on doing everything necessary to deliver value to your customers, you won’t have to worry about creating an unfocused and overpacked product over time.