作为产品经理，我们努力的方向究竟对不对？

作者：谭小超

全文共 3915 字，阅读需要 6 分钟

—— BEGIN ——

最近接到了很多同学的困惑：

• 有的是应届毕业生，希望毕业之后从事产品岗位，但是不知道从何下手；

• 有的是想由别的岗位转岗到产品岗，但是不知道从何学起；

• 有的是已经在产品岗有过几年经验的产品汪，但是慢慢的发现摸到了天花板，卡在了职业发展的瓶颈处，不知道应该何去何从。

接下来，我们以几个常见问题为切入点，聊一聊在产品经理这个岗位上，我们努力的方向到底在哪儿?

产品经理需不需要非常精通原型工具？

有些同学跟我说，自己刚刚转行产品经理，正在自学 Axure 与墨刀。我问，为什么要同时学习两个工具？

很多刚刚入行的产品经理并不知道产品经理这个岗位的核心价值与核心竞争力是什么，因此不知从何处下手开始学习，只是知道产品经理会用到原型工具。

显然，工具类的技能学习，是入门最简单的，也是最没有门槛的，于是很多同学们抓住了这根救命稻草，找到了唯一可见的一个努力方向，拼命的学习了起来。

网上搜各种教程、各种书籍、各种贴吧、求助各种大神，耗费了巨大的精力去学习动态面板甚至是中继器这样的比较晦涩难懂的高阶组件。但是现在学完了之后，发现在实际的产品设计的过程中，输出原型的效率依然很低。

今天我们不谈论如何提高 Axure 使用效率与高阶使用技巧，既然很多人如此的执着于 Axure 高阶使用技巧，我们就要先知道：原型图真正的作用是什么？

原型图在产品研发的过程中，是用来与研发同学进行需求评审与沟通用的，是用来给 UI 同学提供高保真输出的基本参照的。

那么，研发与设计师这二位同学需不需要一个精度极高、添加了所有复杂交互的原型呢？

答案是，都不需要。

研发同学的需求是：在需求评审的时候，能够看明白你这个页面有哪些字段、元素，这些字段与元素有哪些状态，页面哪些地方是热区，点击热区之后激发的下一步相应是什么，页面与页面之间的跳转逻辑是什么，这些能够讲清楚，就足够了。

而 UI 同学的需求更简单：能按照原型图的样式输出高保真设计稿，就可以了。

在高保真的设计过程中，UI 同学是有一定的自主权的，往往不会严格按照原型图的样式进行设计，甚至有的时候跟原型图的出入还会比较大。因此，即使你输出的是“像素级”的原型图，在 UI 同学眼里，只是一个样式而已。

当然，显而易见的是：一份清晰、整洁、条理清晰的原型图，是一定能够加分的。毕竟，向往美好是所有人的本能。

原型工具，说白了只是一个工具而已。对很多人来讲，花 20% 的精力就可以学会 Axure 80% 的功能，而这些功能，在实际应用中就足够了。但是花费 180% 的精力不一定能够学会 Axure 剩下的 20% 功能，而往往剩下的 20% 的功能在真正的产品设计的过程中完全用不上。

互联网本身就是快速迭代的领域，上线速度的快慢往往就是生与死的差别，等你刚刚出完原型并用中继器加上了所有的高阶交互的时候，扭过头一看，隔壁友商已经上线了，这时候你猜大领导会不会让你去财务室领这个月的工资？

你想完全驾驭 Axure 这个工具，醉心于把 Axure 十八般高阶组件全都耍的有模有样，但是在这个过程中之中，你其实已经被 Axure 所控制。跟各位同学分享一句话：

产品经理需不需要懂技术

有一位转行没多久同学跟我说，他刚刚入行产品经理，正在自学 Python ，很显然这位同学是认同这个观点的。我问他你为什么要自学 Python ，是想转研发吗？这位同学同学的回答也许道出了很对产品同学的心声：

产品经理需不需要懂技术，其实这个问题很笼统很模糊；要回答好这个问题，就需要定义好什么叫“懂技术”。懂多少算懂？只有明晰了这个边界，这个问题才有意义。

接下来，我们用一个具体案例去明确这个懂与不懂的边界到底在哪里。

案例：你设计了一套会员体系，有 M 个会员，每一个会员的标签或者维度有 N 个，需要研发同学在数据库中进行数据存储，那么对于数据库的同学来讲复杂度是以乘积的形式增长的，即 M*N 。

数据库同学可能会跟你吐槽：

听到这里你可能已经一脸绝望了，脸皮厚点的可能会问下开发，什么是笛卡尔积、 CDN 、分布式存储？脸皮要是薄一点可能直接就捂脸跑开了。

在这个案例当中，产品与研发两位同学明显就是因为领域认知差异而导致了沟通障碍。

研发同学这种一言不合就甩专业名词的行为，有可能是因为研发同学深谙沟通技巧与心理博弈技巧，希望通过这种甩对方不懂的专业名词的方式，来建立沟通优势与心理优势，以便最大程度的争取后续沟通的主动性；

也有可能单纯的研发同学只是想炫一下自己的专业性，看着产品经理同学的完全听不同的样子，小小的虚荣心得到了满足；

也有可能研发同学只是形成了口语习惯，顺口就说出来了。

总而言之，如果说是一位完全不懂技术的产品同学，那么在此次沟通中就已经处于劣势了，后续的沟通就可能比预想中困难，需要调整、甚至推翻之前的整个方案。

如果说这是一位懂技术的产品同学，就可以直接回应：

当这位懂技术的产品同学说出这样一番话之后，原本已经倾斜的沟通天平指针，就已经被产品同学成功的拉回来了。

说让产品经理懂技术，并不是要求产品经理能够亲力亲为的写代码，而是要懂得产品设计上某些功能的实现逻辑是什么，以便在最初的产品设计中就能够站在研发同学的立场去考虑产品；能够在与研发同学沟通的过程中处于平等的位置，以便双方沟通没有大的障碍，保证高效顺畅的进行。

那么在这个案例里面，需要产品经理懂的，就是：

• 会员体系的存储方式是什么

• 笛卡尔表是什么

• 分布式存储是什么

• 分布式存储的前置条件是什么

不需要产品经理懂的，就是：

• 笛卡尔表在 SQL 中如何实现

• 每一个字段如何存储

• 分布式存储在服务器上如何实现

• 调取数据的实现逻辑是什么

当然，这个边界有可能会随着不同的公司、不同地团队而略有调整，需要每一位产品同学在日常工作中与研发同学不断相互适应、相互磨合，才能够找到产品 & 研发这两只刺猬之间的最佳距离。

笛卡尔积在SQL中示意

分布式管理：是将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

CDN 的全称是 Content Delivery Network ，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。

属于产品经理的“工匠精神”

最后要跟大家分享的，是这几年一直很火的一个词，叫做“工匠精神”。那么，什么是属于产品经理的工匠精神？

接下来，还是拿一个案例来解释，而这次的案例，是我的亲身经历。

那是 N 年前，在我刚刚开始做产品不久的一次产品评审会议上，公司的 CEO 参加了这此评审。当时有一个功能是：用户提交给运营后台审核，要显示一个倒计时。

在倒计时的时间设置上，我当时没有进行过多的思考，直接设置成了 48 小时。

这时 CEO 直接问我：

这一连串的问题问下来，问我的哑口无言。接着 CEO 又说：

案例结束。

诚然，运营部门处理用户的流程也许确实不应该由产品经理来定，应该由运营部门内部去制定，而且倒计时的时间也不会真的苛刻到精确到秒。但是这种凡事追求极致的思路，极其深刻的影响着我之后所有的产品设计工作。

比如，我设计的 toast 提示，无特殊情况的话， toast 显示时间都定为 1.5 秒，需求评审时，部分研发同学可能会问（但是不问的占大多数），为什么是 1.5 秒？这个时候我可以告诉研发同学：

（toast显示时间可以随着toast实际应用场景的变化而相应调整，这里指讨论最常见的场景）

视觉暂留效应与时间关系图

仅作为示意，在视觉暂留效应实际强化过程为非线性。

再举几个小例子：

• 电商产品中，商品名称的字数上限阈值，如果你定了 30 个字，问问自己， 29 个字行不行？ 31 个字行不行？为什么偏偏是 30 ？（要结合字号大小与页面展示效果考虑）

• 购物车中每一个 SKU 可添加进购物车的数量上限阈值，如果你定了 99个，问问自己， 98 个行不行， 100 个行不行？为什么偏偏是 99 ？（要结合后台数据考虑）

• UGC 社区限制用户每天最多发帖量上限阈值，如果定了是 3 篇，问问自己， 2 篇行不行？4 篇行不行？为什么偏偏是 3 篇？（要结合后台数据考虑）

如果你问自己的那些问题，自己也模棱两可，觉得加一、减一好像都可以接受，没有想清楚就给一个大约的数据，觉得“差不多”就可以了，那么你的方案就是经不起推敲的，其实是不负责任的表现。那么，我把我老领导的那句话送给你：

思考：

为什么新浪微博发文字微博的时候字数设定的是 140 字？ 139 字行不行？141 字行不行？

—— END ——

作者：谭小超 ，北大心理学硕士，擅长心理分析&电商领域

本文由 @谭小超 原创发布