40多岁不懂技术，转行做产品经理可行吗？

编辑导语：年龄在职场上是一个很敏感的话题，很多职业都与年龄相关。提到转行，首先不得不考虑年纪的问题，其次就要考虑自己是否具备另一个行业相关的能力要求。接下来，本文作者围绕着“40多岁不懂技术，转行做产品经理可行吗”这个问题，为我们展开了他的分析。

前两天，“人人都是产品经理”10周年庆上，最后一个提问者的压轴问题是问：“40多岁，不懂技术，是否可以转行做产品经理？”

场上大咖给到答案基本都是肯定的。

年龄这个问题，似乎没有阻碍到这位40多岁的提问者，让他觉得不安的，是自己不懂技术这件事。

在对这位提问者敬意的同时，也如嘉宾所反问的：产品经理为什么要和“懂技术”这件事挂钩呢？

笔者看来，开发人员之于产品经理，好似“乙方”之于“甲方”，而“懂技术”这个筹码，就成了乙方“套路”甲方的独家秘诀。

因此，当开发告诉你“这个需求实现不了”、“起码要开发一个月”、“you can you up”的时候，掌握了对技术边界的了解、客观分析的能力、以及理性沟通的诚意，就成了继续推进项目前进的关键。

一、从一个案例说起

曾经，有个商品管理后台。

在商品列表里，有库存和价格，可以分别被锁定。锁定库存或价格后，就不被下游的WMS系统更新。该功能在操作界面上，库存和价格的锁定按钮是在一起的，如图：

1. 需求

为锁定操作增加记录：当锁定状态变化的时候，记录变动的信息。

要求库存和价格的锁定记录，分开展示，即：用户点击库存列的数值，显示库存的锁定记录；点击价格列的价格值，显示价格的锁定记录。

然而，开发说不好实现。并补充说：库存和价格两项的锁定状态变更，只能放一起展示，不能分开展示。

事实上产品经理要求各自展示锁定记录，是有原因的：

1. 场景：通常用户要追查价格或库存的变更时候，都是目标性比较强比如发现价格不对；
2. 交互：价格和库存本身就是两列，独立的数据，分别下**到自己的详情记录也符合用户心理；
3. 频率：价格的改动频率低，若放在一起，那么**出现一些行，价格始终没变，只是跟着空跑，无效信息。

所以双方进一步讨论，后来发现开发的障碍来自表结构：价格和库存的锁定状态，是放在一个表字段了。

表结构是这样：

因此，若是实现起来，就要对这四个状态id进行解析（比如状态1解析为：库存锁定，价格不锁定），还要计算从一个状态到另一个状态的种类组合（12种）。

略懂技术的人都看得，这个表结构设计得是不符合第一范式：两个可再分的属性（库存和价格），为什么放在一个字段里？

2. 正确的设计应该是这样的

但开发说是前任的锅，现在改不动……巴拉巴拉。

后续的处理办法就不细说，但从这个简单的案例看出：

1. 若产品经理不追查到底，那么就不**知道实现困难的原因；
2. 若底层代码这么不规范，就**影响后面其他功能；
3. 如果这个开发就这么摞代码下去，那么很明显代码**很大冗余；
4. 同时也说明了，开发说难实现的原因，并不一定是真的难实现，而是各有各的无奈。

二、哪些情况是真的实现不了

从这个案例看出，开发说难实现的原因，并不一定是真的难实现。万物皆来于创造，程序本身就是一种创造体。如果开发说实现不了，作为产品经理，得了解大概都是哪些原因，比如：

1. 软件的瓶颈所限

计算机能解决的问是有边界的：

比如，屏幕颜色随手机壳变化，现阶段让做出来，可能还是**被打。

2. 缺少底层的软硬件支持

这种情况表现在性能（安全性、稳定性、可用性、可靠性等）不能满足。进而用户体验糟糕，直接面对用户“疾风”的还是产品经理。

但实际的解决，不是一两个月的代码就可以的，而是要加硬件或者改底层结构。

3. 实现起来复杂

绕一大圈，做一个功能，只解决个**豆大小的问题，或者用户使用频次少，都属于低ROI的需求。

这类问题，建议找替代方案，否则开发不愿意做也是正常的。

4. 原代码设不合理导致改不动

重构是开发的梦想，但是真正重构的并没有几个人，比如下图这个发誓再也不为 Oracle工作的程序员：

5. 没想清楚怎么写逻辑

有一个需求是：多组重量区间之间，不能有交叉，开发想了很久不知道怎么用代码表达……

三、“实现不了”背后深意是什么

最快的摆脱一件事情的方式就是否定它，比如：“不知道”、“没见过”、“没有”、“不行”等。

因此，开发说“实现不了”可能只是个表层信号。如果你确定这需求站得住脚，势在必行，那么就要想办法找到本质，而问题本质可能是这样的：

1. 短期内技术天花板所限

技术之外的人来看技术，都**产生一种错觉，觉得一段自然语言能够描述的功能实现起来的难度就和这段自然语言的长度差不多。

自动赚钱程序、输入错误自动纠正的功能、分析图**内容的功能、自动决策功能、滚动播放弹幕不要遮挡正在说话的人、把抓取的图**中的水印去掉……

这些真要实现起来，可要费好大劲了。但是，从提需求的角度来说，真的就是一句话，所以容易造成错觉。要知道，程序连个单细胞生物的自动功能都实现不了，如繁殖下一代、进食补充能量、敌我模式识别等。

2. “待遇”实现不了

一个月开5000，说实现不了；一个月开1万，那就说研究一下；一个月2万，那就做一下试试；一个月5万**说应该可以；一个月10万，那就说通一个月宵也帮你搞出来。

天下没有实现不了的需求，有，那就是钱不够。

3. 这是拍脑袋定的吧，不想做

很多公司都被产品经理（老板）天马行空的想法玩死的。想象力是好事，但要考虑成本。

比如为了一个像素，你可以推来翻去折磨程序员，而用这个产品的受众呢？

——最多不**过两百人。时间也是钱，试错有成本。

4. 资源不够

抄大厂的产品，看着简单，可能人家背后是由几百个人、几年时间才做成现在这个样子的。并且人家后端开发完的程序都部署在linux机器，负载均衡一般至少三台机器。

而自己的老板，为了省钱，为了所谓的私有部署，要求客户可以傻瓜式点击exe在window上部署。

这情况下，早上让程序员优化，下午就问为什么不能用，怎么可能？

——程序员卒。

四、产品经理当如何应对

1. 产品经理要懂实现原理

相比于各种细分产品经理，后端产品经理对技术的要求是普遍的。不仅逻辑思维强，而且起码要懂一些技术块，比如数据库、接口、页面机制等。

因为，如果做前端产品还好：直接整一个UI原型，而且抄的大公司的就可以；但是后端的需求，可能别人家的产品你看都看不到，所有逻辑、机制、风险、性能等问题，都需要产品和开发合力完成的。

对于技术的了解，只要懂共性的原理就可以了。

2. 寻找其他途径继续推进

如果开发能够了解你的需求，说明真的可能是有难度。

那么就和开发绑定为一个共同体（参考SCRUM团队），可以尝试：

1. 让开发定方案；
2. 让开发评估时间；
3. 与开发协调，确定是否实现？是否延期？是否推到下个版本？
4. 尊重人，不要动不动就用下面的话怼开发：“我不要你觉得，我要我觉得；你做不了吗，很难吗，那别人怎么能做出来；你是不是技术不行；你和老板说，我不管；你们就按最简单的方式做就行了，你们怎么方便怎么来；怼，只**激怒partener。
5. 不加班，即使加班你也要跟着一起加。还有一定要让开发参与产品研讨，挑明技术难点，评估开发时间。

五、总结

1. 产品经理无所谓必须要懂，或者不需懂技术：因为他要和各个职位打交道，你能说他不需要了解运营、了解用户、了解UI吗？同理，对技术的了解业是一样。
2. 因为开发是整个功能实现的核心，所有开发若说实现不了，那么产品经理需要了解为什么，避免错失合理的需求。
3. 开发坚持说实现不了的时候，产品经理要试着去了解他的画外音是什么？以便协助，和开发绑成共同体，继续想办法推进项目。
4. 笔者认为，产品经理不用写代码，但要懂技术实现的共性原理，否则，“鸡同鸭讲”效率太低。

事实只要和开发共事久了，潜移默化得到的技术知识，基本就够用了。

六、写在最后：了解一点技术共性

笔者新书《后端产品经理宝典》，从产品经理角度，整理了共性的技术实现原理，推荐学习下。

了解技术原理后的好处，能看透技术的套路，被质疑的时候，不再心虚，甚至提出自己的建议，同时也**被开发信任。

购买链接：http://996.pm/MEyRg

#专栏作家#

唧唧歪歪PM，公众号：唧唧歪歪PM（ID：jjyypm），人人都是产品经理专栏作家，2019年年度作者。《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交APP。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议