Thoughts on the Product Manager Role
The Difference From a Backlog Manager
The PM (Product Manager) role is truly fascinating. Even if we limit it to the IT sector, the description of the PM role varies wildly from one service to another. Some companies even have POs (Product Owners) instead of PMs (Toss is a prime example). The discourse around "what on earth is the difference between a PO and a PM" is another interesting topic in itself. I'll save that for next time and focus on the PM role today. It's been exactly three weeks since I joined DelightRoom. In an organization where the "excellence of the product itself" drives revenue and growth, the definition of a PM was quite different from the one I had known. Actually, it was very different. The perspective I had held on the PM role up until now might have been just a different perspective, or perhaps it was altogether wrong. Let's explore how the PM role stands out in an organization that prioritizes the product itself over the business.
When asked what the essential skill for a PM is, many in the industry—myself included—would answer "communication skills" without a moment's hesitation. It's not wrong: a PM has to mediate between the business and product divisions, lead various engineers and designers within the product division, and achieve a single goal. It's true that you can't perform the PM role without communication skills. But if you ask whether that's a sufficient condition, the answer is no. Until now, many people, including myself, had been confusing a Backlog Manager with a Product Manager.
Product divisions typically run their collaboration processes on a cycle called a Sprint. It's akin to operating a conveyor belt, often referred to as a pipeline. Deciding what engineering tasks to put on this pipeline is one of the PM's roles, and those candidates are called Backlogs (meaning a "pile of work stacked up behind"). As a Backlog Manager, the PM periodically audits these backlogs, deletes what isn't immediately necessary, estimates the expected impact and engineering effort for each, and decides which sprint to slot them into. Then, they communicate with the assignees (engineers or designers) to deliver the work according to the target timeline. Since the performance of the product team varies greatly depending on how accurately the Backlog Manager prioritizes, how well they sync with the assignees on the task, and how promptly and precisely they handle the back-and-forth communication during the process, it's no wonder it feels like communication skills are everything. However, what I've discussed so far is limited to just one of a PM's many roles: Backlog Managing. I belatedly realized that a Product Manager is a role that requires skills beyond those of a Backlog Manager.
Now, let's briefly summarize the difference between a Product Manager and a Backlog Manager, and consider why so many organizations demand the skills of a Backlog Manager while claiming to hire a Product Manager.
Backlog Manager
1. Source of backlogs: A passive setup where countless backlogs are already given.
Acts dependently on other departments.
Requests pouring in from business departments: "This needs to be launched by next month." "Please process this as a priority." There might be a "priority triage" process for critical acceptance, but usually, the tasks pushed the hardest get done first. There's a risk of being reduced to an in-house SI (System Integration) agency.
Direct-from-the-source requests handed down from executives: "Treat this as the highest priority." This seems like a situation you'd only find in large tech corporations, but surprisingly, it's quite common in startups too.
A Backlog Manager always has a mountain of tasks piled up in front of them, so simply knocking out given tasks without a hitch is considered a great feat. Thus, the following skills are required:
2. Core skill: The ability to prioritize a flood of tasks and complete them within a deadline.
Quick mind: A sharp brain that can grasp the high-level context of given tasks (the Why) and break them down into chunky tasks for planning.
Quick hands and feet: The agility to create audiovisual materials for effective communication, document past work for easy maintenance, and execute polished communication without hesitation.
In reality, it's hard enough to find someone with just these skills. When you tackle a flood of work based on these capabilities, your main starting point for thinking about your job becomes the following:
3. Starting point of thought: Primarily focused on what needs to be done (the What and How).
Obsession with the solution: Approaching things in terms of the solution (what to do)—"how" to solve the given problem, or "what" task to execute.
Efficient, creative approach: Exceptional competence is usually judged by how efficiently a problem was solved or how creatively someone thought "out of the box."
These traits are often substituted for the traits of a Product Manager in average organizations. But more accurately, they are the traits of a Backlog Manager. The traits of Product Managers who go beyond this are as follows:
Product Manager
1. Source of backlogs: Proactively observes occurring phenomena, judges whether there is a problem, and goes further to independently investigate the root cause.
Monitoring phenomena: Checking the current state of the product through incoming VoC (Voice of Customer) and quantitative product data metrics.
Identifying problems: Determining whether anomalies spotted through monitoring are actual problems.
Identifying causes: Distinguishing the occurring phenomenon from the cause of the problem, digging deeper into "Why" this phenomenon occurred.
Even in this case, PMs always have a mountain of tasks piled up in front of them. However, the required skills change because these tasks aren't handed down by other departments but must be unearthed by the PM themselves, and the solution and its impact vary wildly depending on whether the root cause was diagnosed correctly.
2. Core skill: The insight to capture the essence of a problem (= opportunity) within a phenomenon, and the ability to define the problem.
Insight to see the essence: The ability to catch what others just pass by. The ability to discover areas people don't even consider problematic.
The cognitive ability to dig appropriately yet deeply: Why is this a problem? What is the cause? The ability to clearly, not vaguely, identify the cause.
In the fable of "The Tortoise and the Hare," the hare lost. Why did he lose? Thinking "because he slept" is accepting the phenomenon exactly as it is. Why did he sleep? If you dig one level deeper, the answer is "because he was overconfident." If your thinking stops at "because he slept," your "things to do" become "buy the hare a coffee" or "tell the hare to sleep early the night before." Would the hare stay awake during the race then? Even if he doesn't sleep, he might just lie down to rest and still lose. When the thought process continues to "because he was overconfident," the "things to do" evolve into "inform the hare that the tortoise is incredibly skilled" or "teach the hare the virtue of humility." If measures are taken to prevent him from being overconfident, he would absolutely never take a break in the middle, even if he had stayed up all night the day before. However, if you dig one step deeper here and wonder why the hare got overconfident, you might conclude "the early childhood character education system in the hare world is flawed," which results in an incorrect diagnosis of the problem's root cause. The moment you define the arrogance of a single hare as a systemic educational problem of the entire hare world, it leads to a wasteful drain of resources. That's why the ability to dig appropriately deep is crucial.
3. Starting point of thought: Primarily focused on the Why rather than what needs to be done (the What and How).
How sharply is the problem defined?: Based on the aforementioned skills, have you extracted the essence of the problem clearly enough from the occurring phenomenon? Are there still vague parts, or have you over-interpreted it? It's common to meticulously ask questions over and over. As seen in the "Tortoise and the Hare" example, a solution usually emerges naturally once the problem is defined. That's why much more time is invested in defining the problem than discussing the solution.
What is the impact of the problem's essence?: Calculating the potential impact when the sharpened problems are solved. Considering the potential impact of the problem's essence rather than the novelty of the solution.
Obviously, since a PM also serves as a Backlog Manager, they can be asked for the traits of a Backlog Manager—processing given backlogs with a quick mind, hands, and feet, and devising novel and efficient solutions. However, not many companies demand the more fundamental traits of a Product Manager mentioned above: proactively finding and defining the root causes of problems from phenomena, and selecting the most impactful problems.
Why is that? If we treat this too as a "phenomenon," we can easily examine the essence of the problem through the question "Why?".
1. [The source of money] The product is merely a means for the business, not the essence of the business
In many cases, a product is just a business tool to make money, not a goose that lays golden eggs itself. Travel agency apps, commerce apps, accommodation apps—most of the money comes from business partnerships and selling goods. A revenue model that already makes money exists, and the app was just built later as one of several channels. There aren't many apps that make money purely through the quality of the product. Even if you count them, it's pretty much just YouTube and Instagram. In Korea, apps like Daangn, Qanda, and Banksalad are pioneering product quality, but their revenue models have yet to fully settle. Looking at the recent trend of IT products becoming essential goods in daily life, I hope that within the next five years, products can take center stage as the essence of the business, but for now, it's bound to be rare.
2. [The product takes a backseat] The product becomes broad and complex
Because it's treated as a means to an end, requests from various business departments are accepted indiscriminately, and as a result, the product's complexity increases exponentially. Forget about new features; they're at the point where they need to trim existing ones. KakaoTalk, which used to stick purely to chatting, somehow added ads, a content feed, and a store. Judging whether there's a problem amidst the countless phenomena occurring in such a complex product is unreasonable in itself. There are too many product metrics to monitor, and thousands of VoCs pour in every day. Considering the average tenure of IT product division personnel, it's hard for more than two people to understand all that complexity, and it's common to hire a relatively insufficient number of PMs compared to the breadth of the product. The moment the scope of the product is split up and managed by multiple PMs, there's no way an individual can accurately diagnose the cause of a problem occurring somewhere.
3. [Culture] Corporate mindset
When a boss asks, "What did everyone do today?", how many organizations would allow you to answer, "I just pondered over what the real problem is"? It's said that famous PMs around the world spend 75% of their time defining the problem, and the remaining 25% executing the solution that naturally deduced itself. There just aren't many organizations where those masters can belong. Let's say you're given a mission to chop down 10,000 trees along with a dull axe. Most organizations would calculate how many trees to chop per day and immediately jump into action. Great PMs would want to spend ample time sharpening the axe blade. The problem is that no organization will sit idly by while they spend over two days just sharpening the axe.
In addition to this, due to various realistic reasons, it's practically difficult to establish an environment where you can agonize over the essence of a problem. In a situation where immediate revenue is urgent, it's more efficient to make decisions with minimal rational thought and move straight to action. Each organization builds its job structure according to its situation, it's just that there aren't many organizations in a situation suited for a Product Manager to perform their fundamental role.
DelightRoom definitively wakes up over 2 million users every day with "Alarmy," a mission-based alarm app, and even helps them build morning habits. Without any separate side businesses, it has secured loyal users purely through outstanding product quality, and is raking in exceptional revenue by showing them ads or charging subscription fees. Because the product itself is the essence of the business, unlike other organizations, it strongly demands the traits of a Product Manager mentioned above. Before discussing what needs to be done, we take more time to separate problem phenomena from causes and agonize over the Why. Rather than obsessing over data itself, we use it as a phenomenon to refine the essence of the problem underlying it, and we debate the impact each will have.
This resonated deeply with me, someone who had faithfully performed the PM role as a Backlog Manager until now. It taught me that communication skills, which I had honed as my own strong weapon, are not a sufficient condition for an outstanding PM; that to go from Good to Great, one must possess the discernment to distinguish phenomena from problems, and the insight to pierce through to the essence; and that I still have a long way to go.
I just wanted to be a PM for a Product-Oriented product, not a Business-Oriented one, but I'm experiencing a completely different definition of a PM. Since I know an environment where I can agonize over the essence of a product is a very rare opportunity, I want to steadily build my discernment and capture problems that can create a massive impact in the near future. How proud would I be if I designed and ran an experiment that naturally derived from thorough problem definition, and pulled out the results I expected? Hoping the day comes soon when I can capture that series of experiences in writing, I wrap up this post with a hard-hitting quote for PMs who fail to see the essence of a problem.
Stephan can think that way, but PM Stephan shouldn't do that.
mail : stephan@delightroom.com
instagram : @seosinghan