说大道理谁都知道，说设计流程、说工具使用，百度或者谷歌一下搜索一下也能告诉我们答案。但是工作中的细节，因为每个人碰到的情况不一样，而这种细节性的问题是没有标准答案的，需要具体问题具体分析。这一次，让我们来一起听听起点学院金牌讲师团的导师们，针对我们在工作中碰到的具体问题，给出了什么样的参考答案？
Q51. 作为一个产品经理，从产品开始到结束要撰写，提交很多文档，具体都有哪些文档？
不同的公司风格不一样，到底有些什么文档看公司风格，产品经理最重要的是需求文档，这个文档里包含产品最基本的功能逻辑，ui界面交互，用户功能流程，以及某些功能操作背后的处理流程等，所以需求文档是产品经理最重要的一个文档，视觉稿、交互稿、需求文档都是完整的逻辑文档。
还会有一些产品运营相关文档，每个公司也不同，有些公司会有业务相关运营文档，比如基本数据，产品数据统计都有规范和规则，这些数据文档需要留存，其他同学也要根据规范上报数据、分析数据，所以基本数据需要留存。
其他的活动或阶段性的项目东西不一定以文档的形式留存，可以以邮件的形式留存下来，项目目的，怎么做的，效果如何，可以写结果性的邮寄去输出，然后把它作为沉淀，不一定要以文档的形式。
还有一些后台数据，有的产品涉及比较重的后台，后台架构，数据的标注，行业对应数据，这些也有相应文档，只是文档不一样。做偏游戏的产品，有些数值文档也是需要存档的，所以不同产品文档不一样。最关键的是策划同学的逻辑文档。
Q52. 如何辨别真实需求与伪需求？
答：我们在产品实实战训练营有一个实践环节，让各位去体会，从小组的想法到用户对这个想法的质疑这个过程，经过用户深度调研的过程，很多想法可能就变成了一个伪需求。真实需求和伪需求的区别在于是否是用户真实需要的，是否是用户共同的痛点。伪需求的产生往往是由于一些所谓的“极客”、“产品经理”们YY出来的，没有经过用户调研。
那么怎么辨别真实需求和伪需求呢？多进行用户调研。看用户真实痛点在哪里。有时候用户即使有痛点，也可能不会需要你的产品来解决，因为用户不知道你的产品到底能解决他什么样的痛点，面对这种情况，要更多的要沟通，让用户明白在什么样的场景下有什么样的痛，对于痛点人都是有体会的，但解决方案不一样，如果你去告诉别人你有这样一种产品可以解决这些痛点，他可能会告诉你：不需要。因为他们有其他的解决方案，他也不理解你的解决方案会比他的好多少，他拒绝你的解决法案，不代表没有真实需求。需求是从人的本质上的痛点出发的，而不是说解决法案，所以你要分清楚需求和需求解决方案这两者是不一样的，更多的还是要去了解用户有哪些痛点。
Q53. 如何提升产品用户体验？
答：用户体验是一个纯粹主观的感受，它包含了用户交互页面、视觉体验，所以想要提升产品用户体验，只要提升两点：
- 用户使用起来是否顺畅。其实就是要将页面做到好用，易用，用起来舒服，交互顺畅，这些很重要。
- 用户使用产品之时，使用时是否愉悦。产品的视觉是否符合用户的审美，不会引起用户反感。
这些都是很基本的元素，想要提升用户体验，需要好好打磨这些方面。
Q54. 如何使产品从复杂变简单？
答：其实这个问题也是我们前面讲过的，产品会变得复杂，往往是两个主要原因。
其一，产品经理想太多，在迭代的过程中，给产品增加很多功能，部分功能只是某些用户需要的，面对这种状况，建议用金字塔模型整理，产品中哪些是用户使用最多的核心功能，哪些是主流用户需要的拓展功能，哪些又是部分用户需要的增值功能，有一个列表之后就会清楚，要产品变得简单，只需要突出你的产品核心功能，其他的拓展和增值功能，要么不做，要么将入口藏的极深，只让需要的用户找到就可以，千万不要影响大部分用户对于产品核心功能的体验。
另外就是优秀的产品经理需要在产品的发展路径中，尽量不让产品变得复杂，能不做的，就尽量不做，这个说起来简单，但是做起来很难，所以大家还是先做产品，然后用金字塔模型收归。
Q55. 如何做产品规划并向老板阐释自己的规划？
答：其实这个问题，我们在【起点学院】产品经理实战训练营中也有专门规划，当时在课堂上也为大家介绍了一种方式，先设定阶段目标，再做计划，然后做执行的产品路线规划。我觉得这种模型是很实用的，所以你可以先和老板进行这方面的沟通，做好规划后再按照优先级将产品完善。
Q56. 界面上上多用图标还是多用文字？
答：页面多用图标还是多用文字？这个问题经常被问，但其实这是一个用户体验问题，就是你怎样让用户感觉产品容易用，怎样能让我懂你这个产品，图标和文字无非就是个交互方式，我要怎么知道你这个图标和按钮是个怎样的功能？所以这个问题很简单，大众型产品，要求的是所有用户，有很多人，都比较低端，也不太懂高端的东西，我觉得文字是最简单的倾诉，看懂最关键。而图标能产品比较美观，如果产品定位于国际范，产品定位在国际环境上，很有逼格的产品，可以多设置图标少用文字，而且也尽量使用通用图标按钮，使用一些约定俗成的、规范的，有助于产品。
另外看产品用户定位，有的时候拿不准，设计同学会说一定要画图标，产品同学就会说这个图标我看不懂，我就要用文字，很简单得一种折中方式是，图标和文字一起，就是上面图标下面是文字，这也是非常简单的一种做法，这样子也会使你的产品看上去比较好看。其实没有必要纠结在这页面界面上是非要用全部是文字，核心还是用户用起来比较爽。
Q57. 如何进行产品压力测试?
答：压力测试可以交给技术同学，因为压力测试主要针对后台，压力测试的一般都可以交给测试同学和运营同学。压力测试分为真实环境和模拟环境测试。如果需要在真实环境也就是外网环境测试，可以在夜深人静时候，真实用户不怎么上线，做一些模拟访问，对外网某个机器做划分区域的一个模拟流量访问，看实际机器的抗压能力，是可以的。压力测试其实就是在后台模拟编写很多访问的请求，高品质的雪纺问候和各种接口，看一下在哪些情况下后台，会出现问题，甚至说崩溃，如果你觉得在外网环境有风险，不愿意去尝试，那你可以去切换一套虚拟环境，比如说验证环境或者类似的这种都可以。
Q58. TO B产品听从用户的需求过多开发单一功能快速迭代合适吗？
答：以前这个问题我也讲过，有些产品并不适合快速迭代，比如说游戏，特别是手机游戏，它的寿命又短，上线之后还没有达到很多的数据指标，比如说用户留存率、付费等情况，如果你快速迭代的话可能，会更快的死掉，所以说，第一个版本要饱满，各个数据要很好才能够推出来，再考虑迭代。TO B产品也是，因为它是一个行业性的，具有管理性的东西，用户角色很。开发特别完整的时候，产品推出来意义不大，人家会觉得这是个不完整的东西，这个时候就要你们自己去点一下你们自己的产品，怎样才算一个相对完整的产品，怎样才是一个用户可用的产品。不同的产品是不一样的，TO C产品有可能有一些基础功能就够了，但TO B因为要满足一些企业，多用户角色，是不太一样的。
Q59．对于产品发布，若涉及多个项目组之间的配合上线，需检查哪些项目，才能避免上线中存在遗漏，降低上线失败的风险呢？
答：这个问题在于产品复杂程度。对于跨部门产品，大家协同作战做产品，我们在【起点学院】产品经理实战训练营说过：上线之前最最重要的是测试同学，测试是否足够全面很关键，测试产品的时候是不是足够细致，其实不管是哪些项目组配合，只要产品发布出去到功能点是没有问题的，该测试的都测试到了，那就ok了，这就是产品最终发布最核心的一个点。
至于项目中一些项目组的衔接问题，我觉得这些问题更多体现在发布之前。比如开发过程中可能会有一些问题，因为配合不默契导致开发进度受影响，功能弄得比较复杂。遇到多部门协作，我的建议是，事前通过一些会议，把接口、原则定清楚，这样开发之前先沟通了，开发起来，到最终的调试bug等会变得少，这个非常关键。当然最后都是靠测试，其实你在做这些检查点的时候，pm（项目经理）也很关键，他最关键的作用是协同，协同不同的部门到同一个产品，做好相应工作。其实这些工作都是为了减少测试工作的环节中的bug，让项目尽早的提测，但最终还是以测试同学的上线标准为主，项目组在过程中到底配不配合，最终只要测试完成产品上线就好了。
Q60．高保真原型图可以算交互设计稿吗？
答：高保真原型和我们说是视觉稿，但不算是交互稿，低保真原型图，才是我们所说的交互稿，，这是一个很基本的概念问题。
查看更多
产品经理3000问 | 这些细节性的问题，你可以参考下这些答案
关于#产品经理3000问#
产品经理3000问是起点学院倾情打造的金牌讲师团答疑集锦。起点学院金牌讲师团，由起点学院导师团联合众多BAT产品总监组成，所有导师负责亿级产品，所有导师拥有丰富实战经验，并且，他们都有自己独到产品经理培养体系。所有问题均来自起点学员工作实践中的问题，由起点学院金牌讲师团解答之后精心选编而成。内容涵盖需求、团队、设计、创业、运营等产品经理工作各方面；是起点学院金牌讲师团、数千名互联网童鞋的智慧积累。对于产品经理解决工作、项目的实际问题具有很强的参考价值。
