Building the right feature attract more users, create stickiness, and increase retention. However, the most simple and most difficult feature tends to kill the product. We often overly add simple features and over-complicate difficult features.

"If this is simple, let's just build it".

There are always overflowing feature wishlists, scope, story, and tickets. Whatever your company calls it. We spent the bulk amount of our time discussing the toughest feature that can bring the most value. On the simple one, we tend to let it slip through without much thinking.

You surely heard from management, PM, Sales, or whoever that is requesting the feature: "how difficult is this?" If the reply is: "simple/easy", this comes next: "Well, if this is simple let's just build it!".

As a product manager, we kept saying "no". When it comes to the easy feature, we think less about it. Our social capital also means we have a limited number of "no" to use. We want to keep it to the really tough one.

Is it right?


I am guilty of that too. The easy feature requires less time, ship faster, and potentially help users do their job better. Even if it didn't work, we only spent little resources on it. It is tough to argue on this standpoint.

However, as time passes by, these "easy features" add up. It multiplies. The number of users who use this feature are fewer than expected, but they use it. Then someday, like all software, bugs happen. Engineers have to spend more time to fix it. Eventually, it reaches a point where we have to rethink about those features.

Should we continue to support it? If we don't, we piss off the small group of users who likes it. If we do, we need to spend more time maintaining it for a small group of users. When we reach this stage, it becomes a double edge sword.

The best way to solve it; prevent it from reaching this stage. We have to continue building easy features to test out its potential and user liking. However, we should not keep adding it without removing it.

We can set targets and do A/B testing with our users. Launch it as a beta. Monitor it with a group of beta users. Did it reach our goal of usage? Does the majority of the testing group use it? If they do, we can open up to everyone as a new feature. If they don't, we kill it. This way, we don't waste unnecessary resources and no longer risk disappointing the small group of users who develop a liking down the road.

"Let's just start working on it first"

The most challenging feature that brings the most value always gets the most discussion. After a few lengthy discussions that bear no fruit, someone bound to say: "Let's just start working on it first".

I love the challenging feature. It usually led to a breakthrough that delights the users. However, we cannot jump in blindly.

Why? If it is something that is not fully thought out, how can the engineers build it? How can the designer design it?

But on the other hand, if we don't start working on it, we will still be going on discussing it in circles.

So, what should we do?

In cases like this, I tend to separate what we agree on with what is being disagreed on. We pick up the agreed item and break it down to smaller tasks. The majority often agree with the problem but have different solutions in mind. So, be explicit about this.

Realign the stakeholders that our final goal is to allow users to do X but we are not sure which of A/B/C solution is the best. So we going to start with the groundwork for the common point. Then, pick one to tackle first.

This way, the designer can focus on an agreed solution. We can then prototype the different solutions that we have in mind. Iterate in the design, prototype, and user testing phase. Then finally bring it back to the table for discussion again.

Once we have it, we can start the engineering works. Commonly, we don't have the right solution from the start. So, we need iterate as early as possible, especially for large challenging features that take up the most resources.

Thanks for reading! If you like it, please subscribe!

I send out 2 Pointers Tuesday newsletter every week dedicated to product management. From the perspective of a former engineer who spent 8 years in coding, I discuss common problems that you will encounter in product management and share my experience and solution.

Please follow me on twitter!