今天的二面，让我感触很深。

面试官是一位老大哥，他也是从技术转向产品，再走向管理。我们聊到转型时，他说的一段话让我印象特别深。按我的理解，大概是：

从技术转产品，是因为发现有些用户的问题，单靠技术解决不了。

从产品转管理，是因为发现个人的能力和资源有限，需要组织一个团队，一起解决问题。

围绕的始终是同一件事：怎么把用户的问题解决。

这些话让我重新看了一遍自己的工作经历。

过去介绍自己，我习惯讲做过哪些系统、写过哪些模块、处理过哪些故障。今天我开始意识到，这些经历还可以从另一个角度理解：这些年，我究竟在解决什么问题？又为什么一步步走到了现在？

从把功能做出来开始

2018 年，我开始接触数字货币交易所业务，在 BNZ 做的第一个项目是 OTC 法币交易。

项目从 3 月开始，到 5 月 14 日上线。上线后的表现不错，我拿到了一万多元的项目奖金。金额不算特别大，但当时是真的开心，因为自己的能力和付出得到了认可。

那时的成就感很直接：把东西做出来，顺利上线，有人使用，也得到认可。

之后，公司开始重构老系统，采用 PHP 加 Swoole 的架构。我主要负责 OTC 部分，重写了撮合，也做了资产中台，希望将同一用户的相关请求集中到同一个进程处理，减少并发带来的死锁问题。

期间，还参与了从 AWS 到阿里云的服务器迁移，以及性能测试。

这一阶段，我更多是在回答技术问题：功能怎么实现，系统怎么运行，出现并发问题怎么处理。

做出来以后，还要看它能不能跑得下去

2019 年，我开始负责做市。

从现货铺单，到对冲、对账，再到理解平台流动性如何形成，我面对的问题开始发生变化。

程序能正常运行，只是起点。订单铺出去以后，有没有流动性？成交以后怎么对冲？成本能不能覆盖？有用户和没有用户时，平台的运行状态有什么区别？这些都需要继续往下看。

后来，公司并入了外部的合约业务，对方负责业务系统，我负责做市和对冲。

我们尝试过用现货对冲合约，也尝试过杠杆方案，但成本一直是问题。直到后来接入 BN 的永续合约，对冲方案才逐渐找到更合适的方式，报价和对冲的配合也不断调整。

这段时间经历过亏损，也经历了逐步改善、走向持续盈利的过程。

回头看，那时我已经开始越过代码，思考业务本身。一个方案即使技术上成立，如果成本承受不了，业务也跑不下去。

从零建设，也在不断补齐对业务的理解

2020 年初，我跟随之前的技术负责人跳槽出海，加入新的公司，一切从零开始。

法币、现货、高倍杠杆、小合约，还有聊天室、行情、WebSocket 等配套能力，都在这一阶段陆续建设。

2023 年，我开始重构永续合约。通过研究交易规则和相关公式，向其他同学请教，再不断开发、验证，大约用了半年时间，在当年完成上线。

按我目前了解的情况，后续版本仍然基于当时的初版框架继续迭代，逐步增加了跟单、冰山委托等功能，基本框架没有发生大的变化，也没有出现过代码层面的重大事故。

这件事让我有成就感。但合约上线以后，问题并没有结束。

我还需要继续负责做市和对冲。最初采用净头寸对冲，后来因为缓存延迟导致头寸计算不准确，出现重复对冲，造成亏损。之后调整为逐笔对冲，又遇到了跟单场景下集中成交、对冲量放大和滑点的问题，需要继续优化。

赠金规则也改过很多轮：亏损时怎样扣减用户资金与平台赠金，满足什么条件可以释放，释放后如何成为可用的真实资金。

这些经历让我越来越清楚：一条看起来简单的产品规则，背后会影响资金、风险、成本和用户行为。把规则写进程序之前，需要先想清楚它会带来什么结果。

转产品，要把代码里的经验拿出来

后来，我又参与了理财重构、汇兑，以及 2024—2025 年的 Launchpad、Launchpool 等业务。2025 年开始做金融卡，包括三方、四方相关接入，一直维护到现在。

做金融卡时，我也会去看流水、收益和成本。功能接通以后，业务是否挣钱，最低消费等成本是否会造成持续亏损，同样需要有人关注。

这些年积累下来的东西，有相当一部分一直藏在代码里。

为什么这样设计资产处理？为什么选择这种对冲方式？为什么赠金要设置释放条件？为什么跟单需要额外考虑滑点？过去，我习惯用实现来回答这些问题。

今天这场面试让我意识到，转产品以后，不应该丢掉技术，而应该把原来写在代码里的判断，脱离代码表达出来。

把它变成别人能看懂的业务规则、产品流程和方案，也把背后的理由讲清楚：

这个问题为什么要解决？影响谁？有哪些选择？为什么采用当前方案？上线以后，怎样判断它有没有起作用？

技术经历是我的基础。它让我知道，一条规则落到系统里，会牵动哪些环节，会在哪里出问题，又需要付出什么代价。

我接下来需要加强的，是让这些经验能够被开发、测试、运营和风控共同理解，让大家在动手之前，就能围绕同一个问题讨论。

一个人解决不了，就需要团队

过去很多项目，核心开发只有一两个人，测试和产品资源也很有限。除了开发和业务工作，我还会协助风控抓取外部账号数据、做统计，支持对冲账号、业务账号和做市账号的相关工作。

小团队让我接触了很多环节，也让我体会到个人能力的边界。

一个人能多写一些代码，多承担一些事情，但时间和精力始终有限。项目多了，涉及的人和业务多了，仅靠自己继续扛，很难把所有问题都处理好。

所以，当老大哥讲到从产品走向管理，是为了组织团队一起解决问题时，我很有共鸣。

我还需要继续积累这方面的能力。但这次交流让我理解了，走向管理的理由可以很具体：有些问题已经看到了，也知道需要做什么，只是必须让不同专业的人共同参与，才能解决。

感谢这次交流，让我更有信心往前走

以前谈转型，我会有犹豫。做了这么多年技术，转产品是不是意味着要重新开始？过去的经历，该怎样表达，才能让别人理解它的价值？

今天，我对这条路更有信心了。

从 OTC、撮合和资产中台，到做市、对冲、永续合约，再到理财和金融卡，我一直在接触新的问题，也在补齐解决这些问题所需要的能力。现在，我需要进一步整理这些经历，让自己能够从用户和业务的角度，把问题、判断和方案讲清楚。

有些用户问题，代码写得再好也解决不了，所以我需要走向产品。即使知道怎么解决，靠一个人也做不到，就需要学会组织团队。

这次面试最后能不能成，现在还不知道。但不管结果如何，我都想感谢这位老大哥。

他愿意分享自己的经历，也给了我继续转型的信心，让我对专职做产品这条路有了更清楚的认识。

接下来，我想带着这些年做技术的积累，认真把产品这条路走下去。