最近接到了很多同学的困惑：有的是应届毕业生，希望毕业之后从事产品岗位，但是不知道从何下手；有的是想由别的岗位转岗到产品岗，但是不知道从何学起；有的是已经在产品岗有过几年经验的产品汪，但是慢慢的发现摸到了天花板，卡在了职业发展的瓶颈处，不知道应该何去何从。接下来，我们以几个常见问题为切入点，聊一聊在产品经理这个岗位上，我们努力的方向到底在哪儿?
产品经理需不需要非常精通原型工具？
有些同学跟我说，自己刚刚转行产品经理，正在自学axure与墨刀。我问，为什么要同时学习两个工具？
很多刚刚入行的产品经理并不知道产品经理这个岗位的核心价值与核心竞争力是什么，因此不知从何处下手开始学习，只是知道产品经理会用到原型工具。
显然，工具类的技能学习，是入门最简单的，也是最没有门槛的，于是很多同学们抓住了这根救命稻草，找到了唯一可见的一个努力方向，拼命的学习了起来。网上搜各种教程、各种书籍、各种贴吧、求助各种大神，耗费了巨大的精力去学习动态面板甚至是中继器这样的比较晦涩难懂的高阶组件。但是现在学完了之后，发现在实际的产品设计的过程中，输出原型的效率依然很低。
今天我们不谈论如何提高Axure使用效率与高阶使用技巧，既然很多人如此的执着于Axure高阶使用技巧，我们就要先知道，原型图真正的作用是什么？
原型图在产品研发的过程中，是用来与研发同学进行需求评审与沟通用的，是用来给UI同学提供高保真输出的基本参照的。
那么，研发与设计师这二位同学需不需要一个精度极高、添加了所有复杂交互的原型呢？
答案是，都不需要。
研发同学的需求是：在需求评审的时候，能够看明白你这个页面有哪些字段、元素，这些字段与元素有哪些状态，页面哪些地方是热区，点击热区之后激发的下一步相应是什么，页面与页面之间的跳转逻辑是什么，能够这些讲清楚，就足够了。
而UI 同学的需求更简单：能按照原型图的样式输出高保真设计稿，就可以了。
在高保真的设计过程中，UI同学是有一定的自主权的，往往不会严格按照原型图的样式进行设计，甚至有的时候跟原型图的出入还会比较大。因此，即使你输出的是“像素级”的原型图，在UI同学眼里，只是一个样式而已。当然，显而易见的是：一份清晰、整洁、条理清晰的原型图，是一定能够加分的。毕竟，向往美好是所有人的本能。
原型工具，说白了只是一个工具而已。对很多人来讲，花20%的精力就可以学会Axure80%的功能，而这些功能，在实际应用中就足够了。但是花费180%的精力不一定能够学会Axure剩下的20%功能，而往往剩下的20%的功能在真正的产品设计的过程中完全用不上。因为互联网本身就是快速迭代的领域，上线速度的快慢往往就是生与死的差别，等你刚刚出完原型并用中继器加上了所有的高阶交互的时候，扭过头一看，隔壁友商已经上线了，这时候你猜大领导会不会让你去财务室领这个月的工资？
你想完全驾驭Axure这个工具，醉心于把Axure十八般高阶组件全都耍的有模有样，但是在这个过程中之中，你其实已经被Axure所控制。跟各位同学分享一句话：
你想控制的，最后往往都控制了你。
产品经理需不需要懂技术
有一位转行没多久同学跟我说，他刚刚入行产品经理，正在自学Python，很显然这位同学是认同这个观点的。我问他你为什么要自学Python，是想转研发吗？这位同学同学的回答也许道出了很对产品同学的心声：
我学技术是为了能更好的跟研发沟通啊。
产品经理需不需要懂技术，其实这个问题很笼统很模糊；要回答好这个问题，就需要定义好什么叫“懂技术”。懂多少算懂？只有明晰了这个边界，这个问题才有意义。
接下来，我们用一个具体案例去明确这个懂与不懂的边界到底在哪里。
案例：你设计了一套会员体系，有M个会员，每一个会员的标签或者维度有N个，需要研发同学在数据库中进行数据存储，那么对于数据库的同学来讲复杂度是以乘积的形式增长的，即M*N。
数据库同学可能会跟你吐槽：你知不知道什么是笛卡尔积啊？那么大的数据量要不要用CDN？要不要做分布式存储呢？听到这里你可能已经一脸绝望了，脸皮厚点的可能会问下开发，什么是笛卡尔积、CDN、分布式存储？脸皮要是薄一点可能直接就捂脸跑开了。
在这个案例当中，产品与研发两位同学明显就是因为领域认知差异而导致了沟通障碍。研发同学这种一言不合就甩专业名词的行为，有可能是因为研发同学深谙沟通技巧与心理博弈技巧，希望通过这种甩对方不懂的专业名词的方式，来建立沟通优势与心理优势，以便最大程度的争取后续沟通的主动性；也有可能单纯的研发同学只是想炫一下自己的专业性，看着产品经理同学的完全听不同的样子，小小的虚荣心得到了满足；也有可能研发同学只是形成了口语习惯，顺口就说出来了。总而言之，如果说是一位完全不懂技术的产品同学，那么在此次沟通中就已经处于劣势了，后续的沟通就可能比预想中困难，需要调整、甚至推翻之前的整个方案。如果说这是一位懂技术的产品同学，就可以直接回应：
我最初已经考虑过SQL中笛卡尔积表的这个问题了，因此在最初进行标签选择的过程中，已经进行了最大程度的标签删减，既能够满足需求，又能够给你们减轻工作量。会员体系的存储就采用分布式存储，已经确认过公司现有服务器的数量，完全可以支撑此次分布式存储的需求。
当这位懂技术的产品同学说出这样一番话之后，原本已经倾斜的沟通天平指针，就已经被产品同学成功的拉回来了。
说让产品经理懂技术，并不是要求产品经理能够亲力亲为的写代码，而是要懂得产品设计上某些功能的实现逻辑是什么，以便在最初的产品设计中就能够站在研发同学的立场去考虑产品；能够在与研发同学沟通的过程中处于平等的位置，以便双方沟通没有大的障碍，保证高效顺畅的进行。
那么在这个案例里面，需要产品经理懂的，就是会员体系的存储方式是什么，笛卡尔表是什么，分布式存储是什么，分布式存储的前置条件是什么；不需要产品经理懂的，就是笛卡尔表在SQL中如何实现，每一个字段如何存储，分布式存储在服务器上如何实现，调取数据的实现逻辑是什么。当然，这个边界有可能会随着不同的公司、不同地团队而略有调整，需要每一位产品同学在日常工作中与研发同学不断相互适应、相互磨合，才能够找到产品&研发这两只刺猬之间的最佳距离。
笛卡尔积在SQL中示意
分布式管理：是将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。
属于产品经理的“工匠精神”
最后要跟大家分享的，是这几年一直很火的一个词，叫做工匠精神。那么，什么是属于产品经理的工匠精神？
接下来，还是拿一个案例来解释，而这次的案例，是我的亲身经历。
那是N年前，在我刚刚开始做产品不久的一次产品评审会议上，公司的CEO参加了这此评审。当时有一个功能是：用户提交给运营后台审核，要显示一个倒计时。
在倒计时的时间设置上，我当时没有进行过多的思考，直接设置成了48小时。
这时CEO直接问我：为什么是48小时？我问你，47小时可不可以？49小时可不可以？差1分钟48小时可不可以？48小时零1分钟可不可以？
这一连串的问题问下来，问我的哑口无言。接着CEO又说：你有没有考虑过用户提交运营审核的流程是什么？我们内部审核的流程是什么？你没有想清楚整个流程，所以你的倒计时时间就的制定就是没有依据的。
案例结束。
诚然，运营部门处理用户的流程也许确实不应该由产品经理来定，应该由运营部门内部去制定，而且倒计时的时间也不会真的苛刻到精确到秒。但是这种凡事追求极致的思路，极其深刻的影响着我之后所有的产品设计工作。
比如，我设计的toast提示，无特殊情况的话，toast显示时间都定为1.5秒，需求评审时，部分研发同学可能会问(但是不问的占大多数)，为什么是1.5秒？这个时候我可以告诉研发同学：
1.5秒是人眼视觉暂留达到最大效应的最短时间，即：0秒—1.4秒这一段时间视觉暂留效应会随着时间的增加而增加，并在1.5秒达到顶峰，从1.6秒往后视觉暂留效应不会随着显示时间的延长而增加，并且如果时间再长，toast就会打扰用户操作。少0.1秒还未达到最佳提示效果，多0.1秒会打扰用户操作，1.5秒，是这么来的。
（toast显示时间可以随着toast实际应用场景的变化而相应调整，这里指讨论最常见的场景）
视觉暂留效应与时间关系图 仅作为示意，在视觉暂留效应实际强化过程为非线性。
再举几个小例子：
- 电商产品中，商品名称的字数上限阈值，如果你定了30个字，问问自己，29个字行不行？31个字行不行？为什么偏偏是30？（要结合字号大小与页面展示效果考虑）
- 购物车中每一个SKU可添加进购物车的数量上限阈值，如果你定了99个，问问自己，98个行不行，100个行不行？为什么偏偏是99？（要结合后台数据考虑）
- UGC社区限制用户每天最多发帖量上限阈值，如果定了是3篇，问问自己，2篇行不行？4篇行不行？为什么偏偏是3篇？（要结合后台数据考虑）
如果你问自己的那些问题，自己也模棱两可，觉得加一、减一好像都可以接受，没有想清楚就给一个大约的数据，觉得“差不多”就可以了，那么你的方案就是经不起推敲的，其实是不负责任的表现。那么，我把我老领导的那句话送给你：
你就是没有想清楚。
