Why the best product managers don't build the feature their users ask for

For as long as I can remember, the masses were begging, screaming and pleading for a Facebook dislike button. Whether it was for disliking obnoxious political posts, showing disapproval at lame videos, or showing sadness at tragedies, everyone wanted a dislike button.

Due to the extremely strong and explicit user demand for the dislike button, it felt like only a matter of time before Facebook would release it. After all, how tough would it be for one of the foremost tech companies on the planet to just plonk a thumbs down button next to the like button and ship it.

Curiously enough, the dislike button never shipped. The product team at Facebook knew better than to accept a feature request from users at face value and implement it in a jiffy (Developing user-requested features are standard practice at any other friendly neighbourhood tech company).

Ignoring the feature request, the product team dug deeper to uncover the real pain-point behind the vocal demand for a dislike button from the users.

They discovered that the real issue plaguing the user wasn’t the lack of a dislike button, but the simple truth that not everything in life is likable.

Mimicking real life, users wanted the ability to react differently to different posts.

Hence, Facebook Reactions!

Customer-orientation > product-orientation

One of the fathers of modern marketing and renowned Harvard professor, Theodore Levitt, argued way back in 1960, that “businesses should stop defining themselves by what they produced and instead define themselves by customer needs, desires and problems.”

In his now classic paper ‘Marketing Myopia’, he argued how the railroads in the US served as an example of an industry whose failure to grow was due to a limited market view. Those behind the railroads were in trouble not because the need for passenger transportation had declined.

Rather, the industry failed because those behind it assumed they were in the railroad business rather than the customer transportation business.

They failed because they were product-oriented instead of being customer-oriented.

A company isn’t a product-creating and product-enhancing establishment, but rather a customer-creating and customer-retaining establishment.

Similarly, Nokia, once the undisputed leader in the mobile phone business, ultimately died as a phone company not because the demand for mobile phones as a product went down but because they didn’t understand the needs of their customers as well as their competitors did.

Forget features and product enhancements, understand customer needs and pain-points:

HBS professor and disruptive innovation expert Clay Christensen shares the story of a fast-food restaurant chain that wanted to improve its milkshake sales.

The company did what any self-respecting product company would do: Build better features in terms of what it saw as the ideal product. In this case, they made the milkshakes even yummier after inquiring about their customer demographics’ taste buds. But alas, milkshake sales did not improve.

The company then enlisted the help of one of Christensen’s fellow researchers, who approached the situation by trying to deduce the “job” that customers were “hiring” a milkshake to do; the ‘pain-point’ users were seeking to solve by buying the milkshake.

He personally interviewed all the customers and discovered that 40 percent of the milkshakes were purchased first thing in the morning, by commuters who ordered them to go.

“Most of them, it turned out, bought [the milkshake] to do a similar job,” he writes. “They faced a long, boring commute and needed something to keep that extra hand busy and to make the commute more interesting. And they faced constraints: They were in a hurry, they were wearing work clothes, and they had (at most) one free hand.”

The milkshake was hired in lieu of a bagel or doughnut because it was relatively tidy and appetite-quenching, and because trying to suck a thick liquid through a thin straw gave customers something to do with their boring commute.

Understanding the job to be done/specific need of the user, the company could then respond by creating a morning milkshake that was even thicker (to last through a long commute) and more interesting (with chunks of fruit) than its predecessor.

Inevitably, this led to a rapid increase in sales.

Netflix founder and CEO, Reed Hastings, famously told his product team how Netflix wasn’t actually competing against other streaming services, but with work, wine, outdoor sports and other solutions people tried, to pass a boring evening at home .

This kind of thinking outside of your own product and from the customer’s point of view is what separates great product leaders from the merely good; and it is little wonder then that, with such customer orientation, Netflix is one of the most innovative companies on the planet.

Great PMs vs Good PMs:

The only companies who succeed over the long-term will be those who define themselves based on their customers’ needs and desires and not those who bank on the presumed longevity of their products.

Usually, PMs can become so focused on continually shipping features on time and delivering the next great product, that they may neglect to take the time to speak to actual users and fully understand the implications of their last product launch.

The thing is that the real difference between a good and a great Product manager may take years to reflect in terms of impact on the market.

It’s easy to be a good PM in the shorter term by shipping a number of features and enhancements than a great PM who takes time off to figure out ‘what to build’ that actually solves the real user problem before rushing to build it. Good PMs keep shipping, whereas great PMs go back to the user every time they ship something.

I personally know tons of people who’ve built their own apps and web products or are working on one right now. But the reason very few actually succeed is because as engineers, coders and makers, it’s way easier for us to rush through the intangibles of actually talking to our users and getting to really understand them ,and get down to doing the ‘real’, tangible work of writing code.

Every tech company worth it’s salt today has great talent available in it’s engineering armada, itching to build whatever is it that you need built.

Building is the easy part. What to build is the real million dollar question.

There were many dating apps before Tinder but no-one really ‘got’ that the main pain-point of the user was the rejection that they faced (men) and the continual messages that women got from men they weren’t interested in (women). When surveyed, men said that they wanted more women on dating apps whereas women wanted a better selection of men. Tinder solved both user problems with a double opt-in and created a multi-billion dollar market in the process.

Nobody gives a fuck about your shiny new feature or product! Customers buy benefits or expected outcomes! They buy solutions to their problems.

Users tend to frame their problems in the form of pre-existing solutions. As product managers, it’s our job to dig deep, keep asking ‘why’ and uncover the real problem before deciding on what to build.

PMs that take the time to do this will grow beyond knowing what their customers want and will eventually develop an understanding of why customers want whatever they’re asking for. This distinction’s importance cannot be overstated. Usually when a customer asks for something, their request reflects an underlying need that can be better addressed by a solution the customer hasn’t thought of yet.

Because at it’s core, the fundamental responsibility of a product manager is not to be the company’s leading expert on the product but to be the company’s leading expert on the customer.

At a fundamental level, product management deals with the most difficult problem in human experience: how to see things from other people’s point of view.

Building products for others to use is ultimately an act of empathy. Every decision made about how a thing is built and how it should be used comes from the worldview of the maker. How well they can see things through the user’s eyes determines the value of their work. No one person can see the world through another’s eyes. It’s all approximation and guesswork.

The only way is to consistently talk to and ask your customers.

Two years ago, Groove CEO Alex Turnbull noticed a spike in churn and wanted to go beyond the data he was seeing to try and figure out why. So he cut right to the chase: he emailed every single customer and asked for just 10 minutes of their time to talk. As a result, he spent more than 100 hours talking to 500 Groove customers and ended up with feedback that helped him right the ship and save the company.

In some movies, top military commanders have phones that they only pick up when things start to go wrong.

They’ll usually see that an issue is getting out of hand, and they’ll grab the phone (without dialing, of course), yelling something dramatic like “get me the President!”

While I have no idea if this emergency phone exists, I do believe that something similar exists for startup founders, product managers and designers alike.

The hypothetical “red phone” that always seems to help us the most connects directly to our customers.

The best way to get to know your customer is by talking to them and putting yourself in their shoes. And if you have a mobile app, there’s no better solution to talk directly to your customers than with the in-app chat Hotline.

If you’re finally ready to pick up the hotline and talk directly with your customers, right from inside your mobile app without any additional effort whatsoever, try out Hotline.

It’s easy to setup, free to begin with and is currently being used by over 500 apps globally. You can signup for a trial here.