Sometimes, I deeply feel that the role of a Product Manager (PM) is akin to an icebreaker—either forging a path through a dense, blinding fog where nothing is visible, or forcefully shattering a solidly frozen wall of ambiguity to move forward.
Looking back, the paths that a product design could take have always been near infinite. Standing before countless branching roads stretching out in all directions, one is granted the freedom to move anywhere. Yet, paradoxically, there was never a signpost anywhere that clearly pointed out which path would be the most effective and correct direction from the very beginning. Within an endless cycle of choices, a PM must navigate a foggy labyrinth of uncertainty at every single moment, where no definitive right answer exists.
This holds true for me as well, as I spend my days clearing the fog of scattered thoughts among design, engineering, and business, communicating through "words and writings." Having navigated numerous product requirements and various fast-paced project environments, there are lessons I have carefully observed and absorbed. From my own personal perspective, I would like to calmly outline the four survival instincts that I must continuously hone on the fiercely frozen front lines of practical execution.
1. Obsessing Over the "Real Problem" Rather Than a "Better Solution"
Reflecting on why many projects fail, I often realize it is rarely due to a lack of features, but rather because the team was busy solving the completely wrong problem. When business units or clients demand, "We need this specific feature," simply taking it down word-for-word can make a PM feel less like a product strategist and more like a mere stenographer.
In fact, early in my career, I was preoccupied with transcribing on-site demands in their rawest form. Without conducting deep case studies or engaging in rigorous critical thinking about why the problem occurred or how it was solved elsewhere, I would simply transfer those requirements directly onto screens and hand them over to designers and developers. However, the scene I encountered in the meeting room was entirely unexpected. They continuously brought forward countless approaches and far more efficient solutions that had never even crossed my mind. Confronting those sharp methodologies, a heavy wave of self-reproach and embarrassment washed over me: "Why didn't I, the product planner, fiercely deliberate over these infinite alternatives first?"
- Action Strategy: I intend to ask myself a few more times internally, "Why did they say that?" I want to make my primary weapon the structural ability to define problems—unearthing the real pain points hidden within the user journey, identifying contradictions pointed out by data, and sharply refining them into the language of business and technology (PRD).
2. The Power to Clear the Fog: Structuring Ambiguity
In the initial stages of product design, ideas usually feel as vague as grasping at floating clouds. I believe a PM's core competency lies in transforming these scattered, smoke-like thoughts into a solid, structured framework that developers and designers can easily comprehend.
Looking back, I recall colleagues and mentors telling me, "Anyone can do product planning if they know how to talk. But absolutely no one can deliver 'exceptional product planning' effortlessly." As I execute diverse projects, confront various industries, and accumulate years of experience, the weight of that blunt piece of advice resonates in my heart with growing significance.
Paradoxically, with each passing day, product management feels increasingly difficult. This is because minor exceptional flows, invisible organic relationships between data points, and the technical risks that a single line of a requirement might entail—things I used to overlook past blindly—now catch my eye with striking clarity as experience builds. Ultimately, gaining experience meant that the horizon of dilemmas I must define and take responsibility for is expanding endlessly. Having to think more deeply because I know more might make the job harder, but it is also a rewarding sign that I am becoming a more grounded professional.
- Action Strategy: When requirements flow in, rather than blindly wireframing screens right away, I will focus my logical thinking on meticulously defining the final state of data structures, mapping out entities, and establishing airtight product policies that account for edge cases. As my deliberations deepen, I will establish a solid routine of clarifying information hierarchies and synchronizing them through Notion or Figma so that anyone can understand them intuitively.
3. The Ambidextrous PM: Balancing Technology and Business
Even if we cannot write flawless code like an engineer or push pixels with the artistic flair of a designer, the role of a "translator" who understands their languages is absolutely vital. A PM must hold the reality of business in one hand and technical feasibility in the other, constantly maintaining a steady equilibrium.
During my junior years, I learned the hard way just how challenging this translator role truly is. In the middle of a fast-moving project, when a designer discussed layouts using terms like "padding" and "margin," I was so bewildered by my inability to comprehend that I irresponsibly asked the designer to communicate with the client directly. And what about engineering meetings? When developers unleashed feedback completely composed of code-centric jargon, a deep sense of alienation and self-doubt crept in: "Are we even speaking the same language?" This became a turning point for me to deeply empathize with how incredibly high and solid the communication wall must be for business clients or non-tech colleagues if even a PM felt this stranded.
Fortunately, we now live in an era where product planners do not have to feel defeated by the barriers of technical expertise. With the spectacular advancement of AI technology, simply keeping thorough meeting minutes or history logs allows me to reliably comprehend over 90% of highly sophisticated technical and design conversations, absorbing them into my own knowledge base. As technology bridges the communication gap, PMs can focus more intensely on their inherent sense of balance.
- Action Strategy: Backed by AI as a dependable co-pilot, I plan to aggressively learn system architectures, including API concepts, database schemas, data flows, and Role-Based Access Control (RBAC). I believe this is the only way to fully internalize my teammates' languages and drive realistic product initiatives at a "deployable level." Concurrently, I will realistically assess resource constraints (timeline, budget, manpower) without losing the business acumen required to scope out a Minimum Viable Product (MVP).
4. Sharing Context, Not Just "Features"
A PM’s greatest asset and ultimate weapon is, after all, "words and writings." When you simply dump the final output of a feature onto team members, you often hit an invisible wall. A product is born much more seamlessly when the entire team syncs on the "Why" behind it, rather than through a PM’s one-sided directives.
Admittedly, there was a time when I did not acutely realize the vital importance of sharing context. However, the colleagues I collaborate with at my current company possess an extraordinary level of ownership and pride in the services they build. Moving beyond merely engineering and designing according to given screens, they want to clearly grasp the core essence of the service and derive the most concrete, flawless execution paths themselves.
Consequently, whenever I walk into a kickoff meeting with unorganized logic or a loose product brief, I sweat profusely under the barrage of sharp questions from my team. Facing their relentless, product-focused feedback—such as "This part doesn't align logically" or "The edge-case handling here is too weak"—serves as a powerful wake-up call. Ironically, my colleagues' genuine affection for the product acts as a rewarding driving force that pushes me to prepare a much more granular and perfect context.
- Action Strategy: Moving forward, when requesting collaboration from designers and developers, I will never just toss over the "What" of a deliverable. Instead, I will foremost share a clear context regarding the value and impact this task will bring to the user—the "Why." By preparing a solid context that matches my colleagues' fierce dedication, I want to become a trusted leader who stays grounded amidst the numerous variables that arise during a project, communicates flexibly, and seamlessly maintains balance among stakeholders.