Product Management - Art or Science?


Is product management more of an art or a science?
26th Sep 2017

Image courtesy of Mar Tech Today

We are told that as product managers, we need to be always data-driven. Data-driven in the sense that we need to make sense of the world through quantitative and qualitative data. We are expected to come up with hypotheses, perform all kinds of experiments to get results that will point us in a certain direction, and talk to customers to find out what they want and why.

All this is what I consider as the science of product management (you may have your own definition) - approaching problems with the eyes of a scientist - using experiments and customer feedback to determine where we should go next.

Image courtesy of Mozilla Blog

This is all well and good in many situations, where the job of the PM is to solve optimization problems. The company has achieved product-market fit, and the PM is hired to allow the founder to focus on other pressing company issues. The founder deals with fundraising, recruitment, culture and high-level company vision, while driving the long-term product strategy with the PM. The PM also takes over day-to-day tactical strategies, while making sure that product-market fit is not lost and that the company is able to scale efficiently to get dominant market share.

The founder had acted as Product Manager Zero to lead the product vision, solving the 0-1 problem which is escaping the valley of product death. A PM comes in as Product Manager One and so on, solving the 1-100 problem which is achieving scale and growth, while the founder learns to fire himself/herself as the sole PM within the company and keeps abreast of the product strategy 10,000 feet above the ground.

The challenge arises when a PM is hired to solve the 0-1 problem, or what I call the problem to achieve product-market fit in order to escape the valley of product death.

Image courtesy of Physics World

This problem usually requires a great deal of courage, forward-thinking, vision and most importantly, persistence. Why?

Imagine that you do not have enough data to support a product decision. The data you collected is statistically-insignificant (not enough data points) or non-conclusive (split in half). This is especially true in the case of products in startups or new products in large companies. How are you going to convince your stakeholders that this is something worth pursuing?

Maybe you should wrangle your data in such a way that supports your argument. I've certainly heard that bankers and management consultants are highly-skilled in this area - just manipulate some numbers here and there, and the next thing you know, the management is nodding their heads in agreement. Or worse, your management tells you to manipulate the numbers - they need to answer to their shareholders.

There is also the over-reliance on data, as attributed by the McNamara fallacy, named after Robert McNamara for his stint as the U.S. Secretary of Defense during the Vietnam War. This involves making a decision based solely on quantitative observations (or metrics) and ignoring all others. The reason given is often that these other observations cannot be proven.

Image courtesy of Acting Man

I quote Daniel Yankelovich's view on the McNamara Fallacy in Corporate Priorities: A continuing study of the new demands on business. (1972)

"The first step is to measure whatever can be easily measured. This is OK as far as it goes.

The second step is to disregard that which can't be easily measured or to give it an arbitrary quantitative value. This is artificial and misleading.

The third step is to presume that what can't be measured easily really isn't important. This is blindness.

The fourth step is to say that what can't be easily measured really doesn't exist. This is suicide."

How do you know that your product is not going to make it? When is a good time to give up?

For a startup founder: if Brian Chesky decided that Airbnb wasn't worth pursuing just because he only had a handful of customers when first launching (and relaunching) his product the first few times, then I would not be able to book a lovely Airbnb home for my upcoming Korea trip today.

For a product manager: if Sundar Pichai decided that his idea for a new browser wasn't worth pursuing just because Google CEO Eric Schmidt opposed the development of an independent web browser for 6 years, then Google would not have a leading web browser in Google Chrome today.

Besides, the majority of new products are attacking well-defined market problems and just approaching them at different angles. In the instance that you are creating a totally new market or redefining it, where are you going to get the data you need? The future does not exist yet, so asking customers what they want may lead nowhere because they don't know what they cannot see.

As Henry Ford once said, "If I had asked people what they wanted, they would have said faster horses."

This is where I think the art of product management arises.

The Art of Product Management

Talking about this reminds me of a funny story. A schoolmate of mine who quit studying art and went into accounting told me that when she was in art school, she spent a lot of time studying the different methodologies of painting with precision and worked really hard.

However, she complained that her peers who spent less time still got awarded better marks. They were able to explain their imperfect art with ablomb, demonstrating their inspirations and why their messy art was worth it. Looking back, it seems to me that her approach to art was almost scientific, while her peers were learning about art in a more philosophical albeitly messy way.

Image courtesy of Pinterest

In Ken Norton's classic essay on hiring product managers, the notion of product instincts seems close to what the art of product management is. It's considered highly-subjective and not easy to evaluate. He also believes that it is something innate that can be tuned, but not learnt.

To a certain extent, I agree, but I think it has more to do with the kind of diverse life experiences that one has rather than being born with it. There is no better way to understand this than look at the greatest PM of all time, Steve Jobs. He believed that his product instincts weren't inherited, but taught to him by experiencing the diversity of life.

Walter Isaacson writes in Steve's biography, "He called it experiential wisdom."

Steve believed that everything from his Buddhist training to his recreational use of LSD contributed to this sixth sense, forming certain patterns and values that he have to be attuned to. Isaacson says that these intuition-powered decisions might mean that Steve wouldn’t be able to explain why he needed a handle on top of the desktop iMac or why he needed the certain curve on the bottom of the iPad, but he trusted his artistic intuition as much as he trusted rational thinking.

Without the luxury of hard data to defend one's viewpoint, PMs have to resort to gut, or what we call product instinct, to make decisions. These are in fact patterns that they have observed in the past, and some people constantly seek new experiences to expose themselves to more patterns. These patterns may be drawn from a diverse set of seemingly-unrelated experiences or observations. Analogies may be used to make a connection, and then utilised to educate others on why the PM's views make sense. Some others may also call this a product philosophy, product mission or product story.

While helping his father build a fence around his Los Altos home, Steve’s father told him they’re going to make the back of the fence just as beautiful as the front. Confused, Steve asked why he should bother, saying nobody would know the difference. "You’d know", his father told him. Taking this to heart, Steve obsessed over every detail of the first Macintosh computer. The casing, the colors and even the circuit boards were designed to look beautiful, even though it was unlikely anyone would see them. It eventually proved useful when the first iMac emerged with a translucent design, showing off the beauty inside.

Image courtesy of Extreme Tech

Steve also kept insisting that the iMac should look friendly. As a result, it evolved to resemble a human face. The patent for the design of the Apple case was issued in the name of Steve Jobs as well as Manock and Oyama. “Even though Steve did not draw any of the lines, his ideas and inspiration made the design what it is,” Oyama later said. "To be honest, we didn’t know what it meant for a computer to be 'friendly' until Steve told us."

Another example that I would like to mention is what I learnt during an event organized by Intercom for their Inside Intercom World Tour. Their Group Product Manager, Brian Donohue, told the audience that a good product story will inform behaviour and help people make the right choices as the company grows.

The story of Intercom was to make business personal again, and to achieve that, they had to make customer support agents happy, as most of them had a really tough job and were miserable. Based on this story, they released 2 features that took a long time to come to fruition from the backlog as there wasn't much data to support them: emojis for agent ratings and confetti showers when viewing positive feedback. This release is based fundamentally off a product mission/story/philosophy, and what I would constitute the art of product management.

At the end of the day, there needs to be a balance of being data-driven (science), instinct-driven and philosophy-driven (art). Let's also not forget that in the course of a product's life cycle, there are always competing priorities vying for your attention. The best product-driven companies combine all these elements in order to drive their product management function, while keeping a pulse on their short/long-term strategic and tactical goals.

How can we achieve the perfect balance? This is a question that is definitely worth exploring.

Leave me a message

Leave me a message to comment about this blog post!

Other blog posts

What I learnt at film school about making good products

Understand SaaS, PaaS, IaaS, CaaS and FaaS in Cloud Computing