Product Management by Popularity is a Terrible Approach

Gear Fisher
4 min readAug 18, 2020

Software product management shouldn’t be about prioritizing work based on how many people will use a feature, instead, prioritize it by value.

In this installment of ‘product management guided by painful experience’, I’d like to touch on a pet-peeve I developed during my 20 year (and still going) software career. Something I heard a lot of in the past was “why are we bothering with that, it will only affect, like, 7% of users”. The idea that in order to align a team around delivering a feature, they had to know that the feature was going to be used by tons of customers. That it would be hugely popular and because of that, the ROI on the effort would be off the charts and everyone would feel great because what got built got used.

I beg to differ. Using none other than years and years of customer interviews, hands-on experience and zero TechCrunch articles, what I saw actually create engagement and drive product traction were features that were so damn handy, that when called upon, brought smiles to customers faces. As your team grows, the scrutiny to put that team to work on a particular feature also grows. So, when an idea was floated for development, it always faced the popularity test: “yeah that’d be cool, but, how many people are gonna’ use it?”. Arguments start, and the spiral of debate crushes yet another brilliant idea…

Sound familiar? It’s really not a bad question to ask though, and it’s an obvious one so it’s worth consideration. It’s definitely important but I don’t think it’s the MOST important question to ask. You need to go deeper, what does the feature/function do? What problem does it solve? Does it make something that was a pain in the ass 1-click easy? Here’s a few examples: mail merge anyone? When was the last time you used that? I bet it’s been months or even years, but wow, when you needed it, it saved you so much time. How about the solver in Excel? Pivot tables? Rounded text in PowerPoint? So handy when called upon.

Let me hedge that too, coming up with the world’s greatest solution to no known problem does absolutely no good. So take this advice in a balanced approach to your product development.

But I digress, lets go another step further. Lets think about a car and how they are sold compared to software. The idea that “if needed, I could plow through a river or snow bank” sells a helluva lot of SUV’s. How often do you actually use your four-wheel drive? I’ll wager hardly ever. Can you imagine that product management stand-up meeting at the Land Rover factory? “Hey boss, I think we should deprecate four-wheel drive, only 2.8% of people use it on a monthly basis, think of the money we could save if we didn’t have to support that stupid feature! Clearly, nobody buys a Land Rover because it has four wheel drive. Lets kill it!”

Oh, you use your all-wheel drive system all the time? Yeah right. How about the back seat of your car? The sunroof? Spare tire? The trunk? …Get my point? We add features because when called upon, they are so useful and so handy, it makes the overall experience joyful. That is the key point. When you DO ACTUALLY GET STUCK IN A SNOWBANK, four-wheel drive pulls you right out, and you swear you’ll never buy a car without four wheel drive again. These are the things that stick in people’s minds.

Challenge your product team to come up with those features. The ones that make your customers grin even if it’s only once in a while. They’ll appreciate it. I’ve learned that the notion of ‘just in case’ is often all it takes to make a sale and to keep your customers happy. Hell, the entire insurance industry is based on this single principle. It solves for both conversion and churn, a true win-win. Of course, you better take care of the basics and keep the main engine running by doing the maintenance required too, because your customers just expect that stuff to work. But don’t let popularity guide your product development. Differentiation happens when real value is created for your customers, even if it’s only once-in a while. Trust me, they’ll love it, and so will your company.

Cheers,
Gear

--

--

Gear Fisher

Dad. Husband and hobby farmer. Co-Founder of TrainingPeaks and Peaksware, now, starting something new, it’s called OnForm. https://www.getonform.com