Feature Work

The type of work that most product managers think about is feature work. Once a product reaches initial product-market fit, feature work creates and captures value by extending a product’s functionality and market into incremental and adjacent areas. But there are some common core mistakes.

EVERY FEATURE CASTS A SHADOW

Shipping features is not the job. Once a feature is shipped, there are always follow on costs. These costs cast a “feature shadow.” There are a few different types of shadow costs:

1. Maintenance Costs – There is no such thing as zero maintenance. Features must be constantly maintained, evolved, and supported no matter how much usage they are getting.

2. User Costs – Every feature creates cognitive complexity across the user base. That cognitive friction impacts users in different ways depending on where they are in the lifecycle, and it can negatively impact things like feature discovery, new user onboarding, and more.

At Pinterest, we were getting a lot of feedback that new users had a hard time understanding the product. One thing users were confused about was should they be Pinning or Liking? So, we tested removing Likes from the product, and it didn’t impact retention at all. So we sunset that feature.” – Casey Winters, CPO at Eventbrite

3. Killing Costs – “We can always kill the feature if it isn’t popular.” This is far harder said than done. Killing a feature has costs associated with customer satisfaction and time and resources to deprecate. These costs mean that most product orgs don’t kill as many features as though they should.

“At one point we tried killing the “/me” feature in Slack. It ended up creating a ton of backlash among users and we ended up undoing the decision. One thing I learned is that there are no dark corners of your product that are easy to kill.” – Fareed Mosavat, former Director of Product at Slack

“The people using features on the periphery of a product are often the power users—they have the cognitive capacity and the genuine need to early adopt new features. This makes killing underused features even more complicated and costly. Feature churn impacts your power users disproportionately.” – Ravi Mehta, former CPO at Tinder, Product at Facebook, Tripadvisor

Shadow costs are often heavily underestimated. If you look at most product roadmaps, you see feature after feature with no time for follow-on work allotted. The follow-on work then gets skipped because it is hard to justify when you’ve already committed your team to the next thing. You need to leave buffer space for the true shadow that every feature casts.

THE FEATURE SHADOW, WHEN IGNORED, CREATES ISSUES

If you don’t roadmap the follow-on work, you end up with a variety of issues.

1. Distractions and Thrashing – The team ends up thrashing between initiatives as follow-on work pulls from the initially planned strategic initiatives. This becomes extra work for the team with the constant context switching and lack of focus.

2. Product Complexity – Product complexity begins to add up, which complicates engineering. If ignored for long enough, it can lead to your entire business being disrupted.

“Left unchecked, product complexity leads to disruption. The history of tech is littered with companies that got disrupted by more streamlined products (Yahoo -> Google, MySpace -> Facebook, SharePoint -> Slack, Match -> Tinder, etc).” – Ravi Mehta, former CPO at Tinder, Product at Facebook, Tripadvisor

3. Friction for Users – It gets harder for new users to adopt and use the product. Since there is no such thing as zero maintenance, a lot of feature work is not in building new features but consistently evaluating existing features. This evaluation informs the follow-on work that is needed to achieve Feature-Product fit while increasing feature adoption, retention, or virality.

“At one point at Pinterest, we showed what user Pinned the image and to what board. This confused new users. They didn’t even understand where Pins came from and what boards were yet. So we tested deleting attribution of Pins to users and boards, and activation rate went up because new users focused on the content which made it more likely they would find something interesting to them.” – Casey Winters, CPO at Eventbrite

WHEN YOU DO BUILD NEW FEATURES, WHAT IS THE COHESIVE STORY?

When Apple launched Touch ID, it seemed weird to a lot of people. But they sequenced the features of Wallet, Touch ID, and NFC-enabled phones, which added up to Apple Pay (which is the real story). Done well, your features should sequence into a more cohesive story that ladders up to a bigger picture where 1+1 = 3. If you aren’t able to tell that story, you need to be asking the question: should we be building the feature in the first place?

Sequencing is especially important for new use cases that require large behavioral change from your customers. You can’t expect people to make massive behavior changes instantly. Humans don’t work that way. You need to bring them along on the journey vs. plopping it in their lap all at once.

“When people say a product was ‘ahead of its time,’ what they really mean is that the product didn’t do enough to lead people through the behavioral change necessary to get value from the product.” – Ravi Mehta, former CPO at Tinder, Product at Facebook, Tripadvisor

Growth Work

Before a feature is built, you should be asking the question: “How are users going to find out about and build a habit around this feature?” This is where growth product work comes in. Growth product work creates and captures value by capturing more of the existing market. You are typically connecting customers to the value that already exists in the product, rather than creating new value.

The area of work known as “growth” has been on a rollercoaster since the inception of the growth team at Facebook. This has led to a lot of misbeliefs.

GROWTH IS PRODUCT’S JOB

The oldest misbelief is some form of “We build the product, but getting more users and customers using the product is someone else’s (marketing, sales, etc.) job.” A lot of orgs still operate this way when you look at a team’s goals and incentives.

Growth is driven by three primary inputs: Retention, Acquisition, and Monetization. These three things work as a cohesive system, not as silos. Product sits at the center of this system, and influences each of these inputs. Product plays a role in growth for every type of product, from B2C social apps and bottoms-up SaaS plays to even enterprise software. How and where product drives growth is what differs. The misbelief that growth is not product’s job primarily stems from not understanding how product actually influences and drives growth.

BUT GROWTH WORK IS NOT ABOUT MORE FEATURES

Growth is part of product work, but it is not about more features. The second oldest belief is “If we aren’t growing, the solution is to create x feature.” A new feature could be the answer, but often isn’t. The core cause is that most product teams know how to develop features, but don’t understand the other levers that drive growth. Understanding how your features fit into the core growth loops for your product and company overall will help you develop more successful features.

GROWTH IS ALSO NOT ABOUT RUTHLESS OPTIMIZATION

When growth teams started to take hold across tech companies, the misbelief of more growth = more features, quickly turned into: “To grow, we just need to optimize.” This has led teams down a path of local maximums, dark patterns, making decisions exclusively with quantitative data, and bad experimentation systems.

As we discuss in both the Growth Series and Advanced Growth Strategy, there are a lot of different methods to addressing a growth constraint. Optimizing by removing friction or creating a feature are just two of those many methods.

GROWTH WORK BEGINS WITH A CLEAR UNDERSTANDING OF YOUR GROWTH MODEL

So, everything drives growth? No. “Everything drives growth” is a statement typically used by team members or organizations as a way to deflect from the realization that they don’t know the difference between efforts that directly impact growth and those that indirectly impact it.

When doing product work on growth problems, you need to understand how the system of acquisition, retention, and monetization works by answering the fundamental question: how does your product grow? The answer to that question is your growth model.

Once a team understands that, they can begin the journey of identifying where the largest constraint in the system is, what type of constraint it is, what method to use to solve the constraint, and then using experiments to understand if the method actually improves growth metrics.

Scaling Work

As a product continues to accelerate its growth, new bottlenecks occur that slow down or inhibit the team’s ability to ship new features and move quickly. This is where scaling work comes into play. Scaling is important because it ensures that the product team maintains the ability to ship new things across feature, growth, and product-market fit expansion work.

NO RECOGNITION WHEN YOU DO, BAD RECOGNITION WHEN YOU DON’T

Let’s be honest. Scaling work isn’t the shiniest, sexiest, or most visible thing internally and externally. In most orgs, when you do scaling work you don’t get recognized for it in the same way as launching a new feature. This leads individual PMs and PM orgs to a mentality that scaling work isn’t real product work. The reality is: you don’t get recognized for doing scaling work, but when you don’t do it, you will get recognized in a very negative way.

“One small way Facebook rewards scaling work is by featuring a ‘Fix of the Week.’ Every week, Mark invites someone to discuss an important fix at the all-hands meeting which gives the company an opportunity to celebrate the critical, necessary work that often goes under-appreciated.” – Ravi Mehta, former CPO at Tinder, Product at Facebook, Tripadvisor

Rather than viewing scaling work as getting in the way of product work, it needs to be viewed as an enabler of product work. In a healthy product team, scaling is part of the overall portfolio because it drives long-term returns on both speed and product value.

Zoom is a good example here. They pride themselves on their ability to scale. In 2018, their CFO was quoted on how they always keep an extra 50% capacity available at all times for scaling work. It’s one of the reasons they were able to scale during COVID and capture demand that could have easily gone to Google or others.

SCALING WORK IS MORE THAN JUST TECHNICAL ISSUES

Scaling is often characterized as a series of technical issues. But you also need to scale systems and tools to be more effective. Great teams invest in great tooling. Viewing scaling just as tech can lead to PMs thinking its an “engineering problem” and not viewed as part of product thinking.

There are a few categories of scaling work:

1. Technical Scaling

Technical scaling is what most people think of in this category. These are things that help the team handle a higher volume of users and use cases. It could include infrastructure work, managing eng, design debt, and more.

2. Process Scaling

Process scaling overcomes internal challenges by continuing to create, deliver, and grow a product over time. There tends to be increasing organizational complexity of multiple teams coordinating and aligning on product work, which requires new org processes and redesign.

3. User Scaling

User scaling overcomes external challenges that emerge when usage of a product scales to a broader group of users and you start to experience unintended consequences. Fraud detection, spam filtering, security, and more.

EXECUTING SCALING WORK – NOT TOO LATE, NOT TOO EARLY

The art of scaling work follows the Goldilocks rule. On the one hand, if you are late, it becomes a roadblock to opportunities, but if you are too early, you spend limited resources on scaling when they could be better spent on the other types of product work.

“Scott Tong, our Head of Design at Pinterest, used to say ‘design the right thing, then design it right.’ We worked a lot on process to make sure were were designing/building the right thing. Once we verified that we did design/build the right thing, we’d talk about the tech and design debt we created to verify that, and what we need to do address that debt. It’s almost a zero tolerance policy for new tech and design debt.” – Casey Winters, CPO at Eventbrite

Timing scaling work tends to be the most difficult part. You are living in the future, but not too far in the future. You scale the team to take on a new threshold of feature and growth work. So you need to understand what that threshold is.

A few questions to ask when evaluating scaling work:

1. How much of what you work on is unplanned? Putting out fires?

2. What set of opportunities are you not doing because they are too hard to implement?

3. Which set of priorities didn’t get done on time because of engineering debt?

4. Where does the team need more leverage on its time?

If you can’t get your roadmap done because you are buried in support, bugs, or other issues, then you are too late to scaling work. On the other hand, if you are using limited resources to scale something when it isn’t the next weak link in the chain, then efforts go to waste.

“I like to think about process scaling work as a team trading upfront engineering time for long-term operational time. Content moderation systems are one good example — manual moderation is fine (and preferable) in the beginning as the team is learning about the problem at hand, but automated and scaleable moderation becomes critical once it becomes cost prohibitive to manually moderate.” – Ravi Mehta, former CPO at Tinder, Product at Facebook, Tripadvisor

Scaling work focuses on anticipating these bottlenecks to ensure the team can continue to move forward on the other types of work. The ROI of your initiatives is measured based on the impact it has across your entire roadmap vs. a single experiment or initiative.

Product-Market Fit Expansion

A product will hit initial product-market fit. Then, through feature work, growth work, and scaling work, the team works hard to fulfill and incrementally expand the potential of the initial product-market fit. But at some point growth of the product slows down as it hits some type of saturation.

To continue to fuel growth of the organization, product-market fit needs to be expanded in a non-incremental way. Product-market fit expansion is not about iteration – it’s about creating more value by significantly expanding into adjacent products or markets by taking larger bets.

PRODUCT-MARKET FIT IS NOT STATIC

Product-Market Fit is a key milestone to reach, but it’s often misinterpreted as being a static moment in time. The reality is that your customer base is always changing and consumer expectations are always growing. Once you get initial product-market fit, you not only have to keep it, but also expand it.

The visual below explains this. At the beginning of the product lifecycle, it does not have product-market fit. As it gets closer to product-market fit, performance increases and crosses the threshold of product-market fit, but the threshold of product-market fit continues to increase, vs. staying flat, because consumer expectations are constantly growing.