A Pre-Transition Self-Reflection

When I first graduated, I was genuinely passionate about frontend development.

Back then, I cared about code quality and thought deeply about how to make a feature more complete. Could the page be smoother? Could the components be broken down more clearly? Were there any edge cases in the interaction logic? These tasks were meticulous, but finishing them gave me a small sense of accomplishment.

Over time, that feeling gradually faded.

On one hand, the business itself posed fewer technical challenges. On the other, project timelines became increasingly tight. At first, everyone seriously discussed code quality, but later it often turned into “ship it first, fix it later.” I understand the compromise—the business needs to run, projects need to be delivered, and it’s impossible to always follow the ideal. But understanding doesn’t make it easier. In the long run, this rhythm slowly wears down your passion.

On top of that, as AI coding tools become more mature, I started to realize one thing: relying solely on “being able to write code” to build career security is likely to become harder and harder.

So I began to think: if I keep moving forward, should I shift my focus from hands-on coding toward requirement analysis, communication and collaboration, and result delivery?

Let me start with the conclusion.

What I truly want to transition to is not a specific job title, but a position closer to requirement analysis, communication and collaboration, and result delivery. Product manager, project manager, and system operations are the three directions that, from my current perspective, are closest to my frontend experience.

Why I Started Thinking About This

Frontend development is certainly not without value.

A well-designed page, a stable business workflow, and a maintainable component system all rely on engineering expertise. But in recent years, I’ve increasingly felt that much of the daily work has become repetitive execution: taking requirements, building pages, integrating APIs, fixing styles, handling compatibility issues, and troubleshooting various anomalies.

Moreover, with AI’s impact on the industry, what used to require manually writing every line of code can now be quickly generated into a roughly functional version by AI. It may not be entirely correct, nor can it take full responsibility, but it has indeed made some coding tasks cheaper. And the reality is that many companies are laying off employees as a result.

It was from this point that a thought gradually took root in my mind: maybe I should explore other directions.

I First Distinguished Between Product Manager and Project Manager

At first, I was a bit confused myself.

Especially in small companies or small teams, product, project, testing, and even some operational work often falls on the same person. You could call them a product manager or a project manager—either way, they ultimately have to drive things forward.

But if you break down the responsibilities, product managers and project managers focus on different things.

Product managers are more concerned with: what to build, why to build it, and who it creates value for. In other words, they need to turn vague user needs, business goals, and market judgments into a product direction that the team can understand and execute.

Project managers are more concerned with: how to organize resources, how to control progress, how to handle risks, and how to ensure timely delivery. Compared to “should this product be built,” project managers focus more on “how to make this project happen.”

This distinction appears repeatedly in several job analysis articles: product managers lean more toward product definition and user value, while project managers lean more toward planning, resources, progress, and delivery management. In practice, the two roles work closely together, and in small to medium teams, they are often handled by the same person. lylmwt’s article and 欧维Ove’s article both mention a similar division of labor.

那系统运维呢

除了产品和项目，系统运维也是我现在会认真考虑的方向。

如果说产品经理更关心“做什么”，项目经理更关心“怎么把事情做成”，那系统运维更关心的是：系统上线之后能不能稳定运行，出了问题能不能及时发现、定位和恢复。

产品和项目更像是从需求、流程和协作里延伸出来的，而系统运维更像是从上线、部署、故障处理和系统稳定性里延伸出来的。以前做前端时，我也会接触到这些事情，比如打包发布、联调环境、线上问题排查、静态资源缓存、回滚和日志查看。

只是这些工作以前更多是作为开发流程里的一个环节出现，并没有被我当成一个独立方向去理解。

现在回头看，系统运维更强调稳定性和整体视角。一个功能不是写完、测完、上线就结束了，它还要在真实环境里长期运行。访问量上来会不会出问题，服务异常能不能快速发现，部署流程能不能自动化，故障之后能不能复盘，这些事情都决定了系统是不是真的可靠。

Why These Three Directions Are Not Far From Frontend

The reason I first thought of product, project, and system operations is not because they sound easier.

Quite the opposite—none of these three directions is easy. Product managers face uncertainty, project managers deal with schedules, resources, and risks, and system operations handle stability, failures, and online pressure. However, they all have natural connections to frontend work.

Frontend is inherently close to both users and business processes.

Many requirements ultimately land on pages, interactions, and workflows. Where to place a button, how to phrase a prompt, whether to show a certain state—these are not purely technical issues.

After working on the frontend for a while, you naturally encounter many product judgments. For example:

What task does the user actually need to accomplish?
Why does the current workflow cause friction?
Does this interaction shift complexity to the user?
Which requirements only seem reasonable but actually complicate the system?
Which problems should not be solved with frontend patches but should be revisited in the business process?

If you trace these questions further, they go beyond “how to write the page” and move toward what product managers care about: “what to build, why build it, and who it benefits.”

Frontend also easily touches project collaboration. Requirement reviews, scheduling, integration testing, deployment, go-live, and rollback—these stages almost always involve the frontend. Even if you are not a project manager, you are pushed along by the project rhythm. Over time, you realize that successful delivery depends not only on how fast someone writes code but also on whether information is aligned, risks are surfaced early, and consensus is built across roles.

The connection to system operations comes later. It may not appear at the front of requirement discussions, but it emerges once features are actually running. Packaging and releasing, environment configuration, API anomalies, static resource caching, log investigation, and rollback handling—frontend developers encounter these to some extent. I used to see them merely as hassles in the deployment process, but now I recognize they correspond to another question: after a system goes live, can it run stably, controllably, and recoverably?

So for me, these three directions are not entirely unfamiliar new territories but three branching paths extending from frontend work: product is closer to value judgment, project is closer to delivery execution, and system operations is closer to stable operation. A feature moving from an idea to a real, usable system essentially cannot do without these three things.

小团队经历带给了我什么

回看自己的经历，我基本都在小开发团队里工作。

小团队的特点是边界没那么清楚。很多时候不是“这个只归谁负责”，而是事情来了，总要有人先接住。前端也不只是写页面，也要一起讨论需求，补充交互细节，跟后端对接口，自己测一遍流程，有时候还要参与部署、看日志、确认上线后的反馈。

这种环境有好处。它会逼着你看到一个产品从零到一，再到上线运行的完整过程。

从前期需求调研，到功能设计，再到开发、测试、部署、上线、运维，中间每一步都有现实限制。需求不可能永远清楚，排期不可能永远宽松，资源也不可能永远够用。

以前我可能只觉得这些事情很烦。现在回头看，它们其实都在训练一些可迁移的能力：

把模糊需求拆成可以落地的功能
在时间有限的情况下判断优先级
理解技术实现会怎样影响产品体验
在开发、设计、测试和业务之间同步信息
发现风险后尽早沟通，而不是等上线前爆炸
上线后关注异常反馈，确认功能是不是真的稳定运行

这些能力放到不同方向里，会呈现出不一样的侧重点。

放到产品方向，它们对应的是理解需求、判断价值、把模糊想法整理成可执行方案。

放到项目方向，它们对应的是拆解任务、同步信息、识别风险、推动事情按节奏往前走。

放到系统运维方向，它们对应的是部署意识、环境意识、问题排查意识，以及对系统稳定性的敏感度。比如一个功能上线后，如果用户反馈页面打不开、接口报错、资源加载异常，前端不能只看自己代码有没有写错，也要顺着环境、网络、接口、缓存和日志去排查问题。虽然这些不等于完整的运维能力，但至少让我知道：系统不是上线那一刻就结束了，真正的考验往往发生在它开始被使用之后。

这也是我觉得自己可以先往产品、项目、运维方向看的原因。不是因为我已经准备好了，而是因为过去的工作并没有和这三个方向完全断开。

我现在更倾向怎么判断

Transitioning from frontend to product, project management, or system operations comes with both strengths and clear weaknesses.

My strength is that I understand technology a bit—I know what happens on the development side when a requirement lands, and I understand why many seemingly simple features become complex. My frontend experience also gives me practical insight into user experience, business processes, integration testing, go-live, and production issues. These experiences are not entirely useless in any of the three directions.

But the weaknesses are also obvious.

If I switch to product, I need to build up product methodology, user research, business analysis, and requirement judgment skills.

If I switch to project management, I need to strengthen project management methods, resource coordination, risk control, and more systematic communication skills.

If I switch to system operations, I need to build up infrastructure capabilities like operating systems, monitoring and alerting, automation, and stability assurance.

Things won’t happen overnight. I will gradually explore and learn these skills over time.