产品规划师经理PD进行需求分析的六个原则.docx
《产品规划师经理PD进行需求分析的六个原则.docx》由会员分享，可在线阅读，更多相关《产品规划师经理PD进行需求分析的六个原则.docx（22页珍藏版）》请在冰豆网上搜索。
产品规划师经理PD进行需求分析的六个原则
产品规划师/经理（PD）进行需求分析的六个原则
需求分析的六个原则
（一）永远不要显得比客户更聪明
不知道大家想过没有，为什么要把这条作为产品经理进行需求分析的第一原则呢？
我个人觉的，之所以这条作为第一原则，就是告诉我们这些产品经理一个对待客户的基础态度，是什么呢？
就是“平等”。
有朋友会说了，我们提供能够满足客户的产品和服务，客户付费享受这些，这肯定是平等的呀，有什么好说的呢？
果然如此吗？
02年的时候，我在一家软件公司做产品经理，当时我们公司为了能够让我们的客户更贴近公司产品，最好是参与到公司产品设计中（联盟里好像有这样一篇文章：
《让顾客参与产品设计》）成立了一个叫“用户实验室”的部门，这是一个常设部门，专门有一个人在进行管理，主要的工作就是不定期的邀请一些公司的用户来体验公司的最新产品，并让他们提出自己的意见和建议，以方便产品部门进行进一步的改进，目的是在上市的时候，尽量能够达到用户期望的指标。
这个部门的运作就不具体说了，具体说一个案例吧。
有一次，公司另一个产品的产品经理组织了一次新产品用户体验，当时来了大概不到30个用户参与新产品的试用，大家想了，能够耽误个人时间来参加这次试用的用户肯定是公司或者产品的铁杆支持者了，因此，这些用户都显得非常认真，每一个细节都不放过，并且在试用完成后，都非常精心的完成了公司准备好的问卷，至少从我一个旁观者的角度来说，我觉的这次用户试用还是非常有成效的。
但是过了几天，我和那个产品经理闲暇聊天，问他看了那天的用户问卷，对产品有什么新的想法吗，他说“不瞒你说，你是没看那些问卷，那些人（指用户）的想法真幼稚呀，我就不信了，用户会提那样的问题出来”，我说“那你考虑去改进一下目前的产品吗？
”，他说“改什么改，我设计的产品我还不知道，要是按照那些人的想法做，这产品成什么了，我和你说啊，那些人来就是一个噱头，咱们该怎么做还是怎么做”。
既然不是我负责的产品，我也就不好太多说什么，这件事情就这样过去了，直到看到这个原则了，我的头脑中才又浮现出这个事情。
通过这个案例，我就是想说明一点，其实在许多产品经理的心中，对客户有一种根深蒂固的“瞧不上”，只不过是看在客户掏钱的面子上，大家过得去也就算了。
后来开始带人，不止一次的看到有的产品经理在拜访完客户回来后，兴奋地和我说“我从来没见过这样的客户，简直什么都不懂，提的问题真是弱智”，满脸的不屑，甚至是鄙夷。
因此，在需求分析原则一中的第一条就是“了解需求，而不是去批评用户”，而我们的许多同行却是一直在扮演着批评家的角色，对于用户的需求阳奉阴违，当面说的是“非常感谢您的建议，我们会认真考虑的”，头一扭，就对团队的人说“提的这是什么，大家别管这些，继续按照我们的做”。
更为可怕的是，这种对待客户的态度已经蔓延到整个产品团队甚至是整个公司，大家如果留点心，可以去观察一下团队里的对待客户的态度。
那么，为什么会出现这样的情况呢？
似乎联盟里也就这个事情进行过一些讨论，大家都能说出许多原因来，我总结了一下，无非就是三点：
1、我是内行，客户是外行
2、我是设计者，客户是使用者
3、我是产品专家，客户是产品用户
这三点其实都反映出许多产品经理的一种心态，就是五个字：
我懂你不懂。
果然如此吗？
再来说一个例子。
04年的时候，我在一家做SP的公司，负责他们的小区短信产品，这个产品大家都很熟悉，就是每当我们进入到某个区域的时候，例如你从北京进入到河北，就会自动收到一条河北移动发送的欢迎短信，我们的产品可以由用户来划定范围，例如北京-海淀-中关村-科贸大厦，只要一进入到科贸大厦，就可以收到一条短信，具体短信内容可以由发送者来制定，同样，也可以设定接收者在离开的时候收到短信。
有一次，某省举办了一次高规格的展会，省里面的头头闹闹们都出动了，那些参展商为了吸引领导能够到自己的展位一观，于是都到移动开通了这项服务，并指定了领导的手机为接收手机，短信内容都差不多，基本都是领导来进入指定区域的时候，收到“欢迎XXXX领导来我展位指导，展位编号：
xxxxx”，领导离开的时候，就会收到“非常感谢您对我公司的厚爱，XXXX公司敬上”类似这样的内容。
按说从服务流程上一点问题也没有，但是却出现了一个很大的问题，那次大概有500家参展商，据说有400家开通了这个服务，大家可以想象了，当那些领导在一踏入指定区域的时候，他们的手机该是多么的热闹呀，当这些领导离开这个区域的时候，又不得不热闹一次，这还不是最麻烦的，最麻烦的是有一些领导因为某些事情，必须反复进出这个区域，我想那些领导的手机在那一霎那，就似乎开了一场交响乐，交相辉映，热闹无比了。
最终的结果是移动的老总被省里警告，我们被移动警告，差一点封了我们的端口。
这说明什么呢？
我们做产品经理的，或许可以把产品本身设计的足够好用，足够完善，但是，我们很难把客户的业务流程设计的足够完善，也就是说，我们对于用户会在什么环境下使用我们的产品，往往是一无所知的，即使有了一定的数据去支持我们尽量能够在用户习惯的环境下使用产品，但是一切皆有可能，用户是不会按照我们的思路出牌的，除非你做的产品就是独一无二，无法或者不易被替代的，例如windows，即使这样，微软每年也要在用户使用环境上下很大的功夫。
这就是需求分析原则一中的第二点：
客户比你更熟悉业务环境。
有朋友又会说了，这个问题其实也很容易解决呀，让用户把这个问题告诉我们不就可以了，从技术上来说，这个问题是很容易解决的。
果然如此吗？
还以上面那个短信产品的例子来说。
首先，如果没有这次展会，或许这样的问题根本不会出现，那么，我们永远不会知道如此集中的用户会在一个集中的区域发送短信，我们从何得知用户会有这样的一个使用环境呢？
其次，即使出现了这样的问题，而短信的接受人不是这些省力的领导，而是普通的参会观众，即使这个问题被反馈上来了，会引起我们的足够重视吗，如果能够引起我们的重视，引发我们的思考当然最好了，那么，如果没有呢？
最后，即使我们看到了这个问题，但是通知给我们这个问题的不是运营商（其实也是如此，如果不是移动的警告，我想这个问题还会拖下去）而是一个具体的客户，我们能否平等地去对待这个客户的意见呢？
这就又和第一条联系在一起了，我们和客户之间应该是一种平等，这种平等不是建立在交换上的，而是建立在心理上的，尤其对于产品经理来说更是如此。
好，那么，如何来解决这种问题呢？
这就是需求分析原则中的第三点：
真正的问题只有客户知道，我们要做的就是让客户愿意说出来。
这里面包含三层意思：
1、客户知道问题所在：
作为产品经理，有时候会有一种心理优势，认为自己知道问题的所在，其实不然，你所知道的只是产品本身问题的所在，但是产品不是艺术品，不是放到博物馆展览的，而是要由用户在千差万别的业务环境中使用的，不同的使用环境也决定了问题的多样化，我们仔细想一下，其实有时候我们接触的大部分产品问题本质上并不是产品本身的问题，而是因为客户业务环境的不同造成的。
因此，从这个角度来说，客户才是真正知道问题所在的人。
2、我们如何得知：
客户虽然知道问题，但他们并不是解决问题的人，最终还是要通过我们的分析来解决，那么，我们就必须知道出现了那些问题，这就得通过客户反馈给我们，无论是前面说到的用户实验室，还是现在咱们常用的许多形式，根本还是希望能够获得一手的用户使用信息。
3、客户如何给我们：
这里不是说信息反馈途径，而是指客户传递信息时的心态，其实这是和我们的态度紧密相关的，正如前面第一个案例说到的，虽然通过用户实验室能够完成第一和第二个工作，找到问题和告诉我们，但是，我们可以假设一下，如果我以前那个同事对待客户反馈信息的态度被客户得知，那么，我们能认为这些本来很支持我们的客户还会继续支持我们吗？
争取一个客户很难，但是放弃一个客户却很容易，大部分客户的流失并不是因为产品本什么，而是因为我们对他们的态度。
因此，在第三点里特别说明了，一定是要让“客户愿意说出来”，而这种愿意，本身就包含一种客户的主动，而这种主动就是建立在我们对待客户真正的心理平等之上的。
总结一下需求分析第一个原则的中心思想：
1、需求分析第一个原则：
永远不要显得比客户更聪明。
聪明反被聪明误，这样的事情太多了，我们产品经理都是有智慧的人，而不是耍小聪明的人。
2、原则第一点：
了解需求，而不是去批评客户。
产品经理不是批评家，心理上要重视客户，行动上要尊重客户，平等对待每一个客户。
3、原则第二点：
客户比你更熟悉业务的环境。
产品经理熟悉的仅仅是产品本身，但是，产品经理要做的却不仅仅是产品本身。
4、原则第三点：
真正的问题只有客户知道，我们要做的就是让客户愿意说出来。
客户会给你反馈，但是这些反馈有些是真实的，有些是敷衍的，你希望真实还是敷衍，请参考原则第一点。
需求分析的六个原则
（二）尊重用户的现实选择
我们常说，存在即为合理，但是在许多产品经理的需求工作中，似乎并不是这样。
许多客户提出的需求，在经过了我们人为的过滤之后，被打上“不现实”、“不可能”的印记而束之高阁。
客户提出的这些被束之高阁的需求果然是不现实，不可能的吗？
在01年的时候，我在一家通用软件企业，当时互联网已经开始平民化，许多传统的软件公司也开始关注这个市场，希望能在网络大潮中有所作为，当时，公司开发了一个基于IE内核的网上冲浪平台，之所以没说是浏览器，是因为这个平台集合了许多网络应用工具，例如邮件收发，网络下载，网上聊天等，有点像现在许多浏览器上增加的插件，但是我们那个产品的插件是不开放的，只能由公司来提供。
当时，这个产品的产品经理获得了一个需求，用户希望能够通过这个平台订阅自己感兴趣的新闻，并且能主动推送给订阅者，类似于现在的RSS，这个产品经理分析了这个需求后，得出的结论是：
这个需求在现阶段不能实现。
理由如下：
1、网络环境：
那个时候，家庭用户普遍还是56K猫，好一些的家庭用户顶多是ISDN，虽然已经有ADSL了，但是价格贵的离谱，这样的网络环境去实现搜索并整合成用户订阅的信息，简直是天方夜谭。
2、信息来源：
01年的时候，软件公司和互联网公司基本属于老死不相往来，软件公司的看不上互联网公司，认为一点技术含量也没有，这就出现了一个大问题，客户订阅的信息从何而来呢？
去抓取互联网公司的信息，除了技术上的考虑，更关键的是质量上的考虑，如果没有固定的信息来源，即使第一个问题解决了，依然无法实现这个需求。
3、表现形式：
可能是因为当时受到新闻形式的固有思维所限，他认为推送给用户的新闻就应该是图文并茂并且能够让用户在线阅读的形式，如果是这种形式，那么，就又会受到第一个问题的影响而无法实现。
当时我记得这个产品经理列了很多个原因，但是我印象比较深的就是这三个，确实没错，即使仅仅是从这三个原因去看，确实对于实现这个需求是一个很大的挑战。
但是，在前面说到了，存在即为合理，既然有用户提出了这个需求，那么就说明这个需求是合理的，也就说，客户提出的任何关于产品的需求都是对的，有朋友可能会说了，你这是吹毛求疵，怎么可能呢？
其实原因很简单，首先，客户提出的需求可能是业余的，但很有可能是需要的，我们不能用我们专业的角度直接就否掉一个可能许多用户都非常需要的需求，这在第一篇文章里也说到了，关键是我们对待客户的心理决定的，其次，客户提出的需求可能是不好实现的，但不代表是不能实现的，正是因为我们有时候显得过于专业了，在思考许多问题的时候，陷入了一种专业思维的惯性中，尤其是一些技术转型的产品经理，更是如此，往往去思考一种最完美的实现形式，因此，许多不可能仅仅是因为我们觉的不够完美而已，第三，也是最关键的一点，客户提出的问题往往不会超出我们的产品范围，这很好理解，用户对于产品的需求都是引导式的，简单地说，也就是只有当用户在使用了产品的A应用后，才会促使他去想会不会有比A更好用的B能够更好的满足我的需求呢？
大家可以仔想想，我们在使用一个产品的时候，经常会想，“如果这个功能要是能这样或者那样改进一下就更好了”，而这种想法的前提一定是在我们使用了这个产品后才会有的。
因此，用户提出的问题都是在目前这个产品范围中的，用户是不会提那些没有接触过，但是却能够靠空想描述出的需求来的。
简单的说，想法一定是建立在客观上的。
因为我们的产品是客观的，用户的使用也是客观的，他们的想法也是客观的，客观的就一定是存在的，存在的就一定是合理的。
我们不要轻易否定用户的需求，不要轻易向用户说：
你的想法是错误的。
因此，需求分析原则二的第一点就是：
客户永远是对的。
那么，基于这个前提，我们产品经理要做的事情又是什么呢？
很简单，找到一个最合适的方法来满足用户的需求，而不要去找最好或者最贵的方法。
继续刚才那个案例，最终那个需求实现了吗？
当然实现了，并且实现效果在那个时期了还是不错的。
先不说我们是怎么实现的，咱们先来做两个假设。
第一个假设：
去寻找一种最好的解决方法，我们会想，如果用户家里是512K的ADSL（估计那时候许多人还不知道AD呢）该有多好，要是互联网公司都开放接口该有多好，要是互联网上的信息都是规范的该有多好……
当然了，最终我们会想，要是用户不提这个需求该有多好，省的我这么麻烦，呵呵。
这个假设的前提本身就是有问题的，期望通过一种理想状态来实现需求，如果这种理想状态真的有了，还需要你产品经理干什么，产品经理不就是为企业寻找与众不同的机会，创造与众不同的产品，为客户创造与众不同的价值吗？
如果做不到这些，企业能答应你吗？
第二个假设：
去寻找一种最贵的解决方法，刚才也说到了，其实从根本上来说，要是能够解决用户带宽的问题，那么，其他两个问题是比较容易解决的，那么，我们可以这样做，一方面从公司入手，增加自身服务器出口带宽，另一方面，从用户入手，要求用户都换成ISDN或者ADSL，这样，这个需求就很容易实现了。
但是，成本呢？
先不说公司自己，有那个用户会因为看几条新闻而付出这么大的成本呢？
如果想做到这些，用户能答应你吗？
两种比较极端的假设就不去多说了，好，我简单来说一下当时公司是怎么来实现这个需求的，可能用现在的眼光来看就显得有些可笑和幼稚了。
我们无法改变用户的网络环境，那么我们唯一能做的就是优化信息的来源和形式，通过优化来尽量满足用户现实的网络环境。
其实思路很简单，就是这个，当然，具体工作就多了，例如通过人工来收集信息（还好，当时互联网上中文信息有限，所付出的收集成本不是太高，如果是现在这种情况，靠人工来实现就肯定不可能了，并且当时投资我们公司的集团还投了一个互联网公司，做分类信息的，这种共享的资源对我们做这个服务起到了关键的作用），把信息通过自己开发的一个小软件自动导成纯文本的，虽然表现形式上不如HTML的，但是传输速度大大增加了，有时候用户订阅的最大新闻量也不会1K，现在RSS传输过来的也是纯文本。
反正通过利用了不少方法，在没有增加公司多少成本的情况下，这个需求还是实现了，也赶上当时许多用户确实是处于上网兴奋期，对于美观不美观没什么太多的要求，能有新闻看，能有论坛灌水，能有聊天聊天就非常满足了。
因此，需求分析原则二第二点就是：
提供最合适的解决方案，而非最好或最贵的方案。
我们能够提供给用户的产品在不断发展，不断改进，不断完善，同样，我们的用户也在不断进步，不断熟悉，不断精通我们的产品，我曾不止一次见到许多用户提出了非常专业的问题，甚至有时候看产品的眼光比我们许多产品经理还犀利，我曾经待过的一家公司就把一个用户招了进来，最终做到了产品经理。
因此，如果用户的进步速度超过了我们的发展速度，那么，我们的产品在市场上就面临着很大的危险，这样的产品太多了，遍地都是，比如说winzip这个软件吧，想当年是多么的火，但是现在还有多少人去用它呢，没落的原因有很多，其中有一点就是当许多用户对zip和rar这两种压缩格式都非常熟悉，并期望用一种软件就能实现兼容的时候，winzip落伍了，当winrar能够兼容zip的时候，winzip依然守着自己的一亩三分地，让许多winzip的用户投向了winrar。
（备注：
zip和winzip不是一回事，zip依然流行，但是winzip却不行了。
）
因此，我们许多产品经理不用想当然的认为用户对产品的理解永远不如我们，尤其是软件或者互联网行业的产品经理，认为自己是高科技的玩意，说实话，对于用户来说，没用，一个功能不好用，马上就可以转投他家，因为用户的转移成本太低了，有时候我就在想，是不是也是因为这个原因，造成了许多软件和互联网的产品经理不重视和用户的交流，相对于传统行业的产品经理来说，我们欠缺的太多了，需要向传统行业的同行们学习的太多了，而我认为最为重要的，最需要学习的一点就是：
永远不要把自己和用户拉的太远，永远不要认为自己做的东西用户不懂，永远不要认为用户只能按照自己的想法来使用产品，简单的说，就是永远不要把用户当成傻瓜。
对于产品经理来说，没有傻瓜用户，只有我们傻瓜的想法，我们有时候确实太天真，想着能靠忽悠和谎言来自圆其说，保持用户的满意度和忠诚度，如果你现在依然是这么想的，那么，我只能说这个傻瓜是你，而不是用户。
因此，需求分析原则二第三点就是：
不要把客户当傻瓜。
我想，应该在这句话前加一个前缀，就是“永远”。
总结一下需求分析第二个原则的中心思想：
1、需求分析第二个原则：
尊重用户的现实选择。
产品是客观的，用户是客观的，使用是客观的，需求也是客观的，一切都是现实的。
2、原则第一点：
客户永远是对的。
客户不是我们的敌人，客户不会害我们，客户提出的需求看似在为难我们，但本质上是为了让客户自己更好的使用产品，因此，客户不会为难自己。
3、原则第二点：
提供最合适的解决方案，而非最好或最贵的方案。
我们能够做的不一定是最好的，我们不想做的有时候往往是客户最需要的，找到最合适客户的，而不是最合适我们的。
4、原则第三点：
不要把客户当傻瓜。
这个世界上没有傻瓜，自以为对方是傻瓜的人才真的是傻瓜，不要忽悠客户，不要欺骗客户，如果非要在这个前面加上一个期限的话，我希望是“永远”。
需求分析的六个原则（三）转述需求的人也是客户
大部分行业的大部分产品经理必须承认，其实我们很少能有机会能够和终端客户面对面的，原因很多，时间上的，精力上的，市场上的，这其实就给产品经理出了一个自相矛盾的问题：
既然市场客观要求我们要亲自接触客户，但是现实的情况却往往不能提供这样的条件。
对于从事企业消费类产品管理的朋友来说，对于需求的获取或许还稍微好一些，并且也会有更多的机会能够直接接触到终端客户，但是对于从事大众消费类产品管理的朋友们来说，这样的机会就少之又少了。
我个人现在也在为这个事情头疼，虽然说公司也强调产品经理应该尽可能多的处于一线，但是往往许多公司内的事情就把产品经理们折腾个够呛了，对于跑一线的事情往往是心有余而力不足了。
因此，对于大部分的产品经理来说，我们获得市场需求的主要途径就是经过第三方的反馈。
这个第三方所涉及的范围就比较大了，有代理商的，有经销商的，有销售部门的，有技术部门的，也会有高层的，总之，他们对产品的需求犹如洪水一样会不断的朝你涌来，面对这样的情况，我们又该如何应对呢？
在这种情况下，我们通常会面对一个最为核心的问题：
这些第三方往往认为他提的需求就是市场最需要，应该在新产品中必须要实现的。
也就是说，第三方喜欢并且习惯于充当产品设计者的角色。
01年的时候，我负责一款大众消费类的桌面软件，因为有一款软件已经在市场上占据了绝对的优势，无论是从品牌知名度，还是产品本身的性能上，我们都无法与其直接抗衡，但是，这个产品是基于公司整体竞争战略的，属于冲击市场的产品，是为我们的主力产品服务的，一般来说，对于这种产品，公司往往会重点考虑成本而不是产品本身，但是中国许多软件公司（包括许多互联网公司）的情况大家都比较清楚，基本上都是技术起家，一把手基本上都是技术高智商，业务低智商，他们习惯于对每一个产品指手画脚，把自己的一些想法或影或软的加入到新产品中去，而那些往往是思路不错，但是市场并不需要的想法。
因为刚开始做产品管理时间不长，缺乏斗争经验，并且无论是从从业经验还是资历上，肯定都无法和这位老大相提并论了，虽然我隐隐约约感觉他的想法有些不符合市场的要求，但是我又没有足够的依据来支持我的观点，因此，就稀里糊涂的定在了新产品的规划中。
产品上市后，果然印证了我的猜测，用户对于这些和产品定位几乎没有任何关系的应用根本不买账，不断在公司产品论坛里抱怨这些无用的应用使自己的电脑资源空被消耗，影响到了正常产品正常应用的使用，而对于公司来说，平添了许多的开发成本，其中有一个应用我记得非常清楚，公司并没有实力进行开发，是购买第三方的，花了不少钱。
从这个案例中可以看出，通常第三方要充当起产品设计者的角色，往往不会考虑得非常全面，要么是不知轻重缓急，要么是做捡了芝麻丢了西瓜的事情，但无论怎样，对于公司来说，都是成本的无谓付出。
其实这也是从侧面印证了为什么产品管理能够逐渐兴起的重要原因，就是公司期望产品管理者能够为企业评估出一个性价比最高的业务解决方案，并最终实现。
老汤的一个观点我比较赞同，就是“产品经理对于企业来说，最能体现价值的地方就是通过自己的工作，让企业有限的资源流向到最有价值的产品上”。
其实不止是技术部门喜欢充当产品设计者的角色，许多销售部门的同事也喜欢和产品管理者在业务上较真，他们往往认为自己是在第一线工作的，接触客户的机会要比产品管理者多的多，因此，他们也就想当然的认为自己是最了解市场需求的，因此，对于产品管理者的产品规划和设计，往往是横挑眉毛竖挑眼，有时候甚至是不屑一顾。
因此，产品管理者在做需求分析的时候，最不想遇到的情况就是：
第三方一般会把自己想象成设计者。
其实他们这样想象倒也无大碍，只要产品经理心里有谱就行，而现实的问题往往是我们不得不面对高层和强势部门给我们的压力，甚至更窘迫的是，有时候产品经理就成了这些需求反馈部门的代笔者，他们想的需求是什么样的，我们要做的就是用文档记录下来，按照一些朋友的话，产品经理咋感觉就是一个写文档的呢？
有朋友会说了，为什么你对于第三方反馈上来的需求如此态度强硬，甚至是反感呢？
这里澄清一下啊，第一，我不是反感需求多，需求越多，越有助于我们更全面的了解市场，第二，我不反感这些第三方，他们是我们的同事，是和我们一同战斗的伙伴，我们之间是互相帮助，互相支持的关系。
我所要说明的是，因为种种原因，他们反馈上来的需求往往已经不是我们这些产品经理所期待的最原始的需求了，也就是说，这些需求或多或少的出现了遗漏、增加、删减的情况。
出现这种情况的原因有客观的，也有主观的。
客观的原因更多的是和第三方的素质、能力，所依赖的反馈渠道，反馈工具，信息规范等有很大的关系，这个就不说太多了，因为这需要企业从整体上来规范和加强信息反馈制度的建设，当然也不仅仅限于是市场需求反馈这一信息链。
重点说一下主观上的原因。
产品团队中的每个人都希望产品能够做好，能够在市场上有出色的表现，但是，我们必须承认，也正是因为每个人都有这种美好的期望，而造成了许多团队成员在反馈需求的时候容易出现以下几种情况。
1、对于自我关注的需求，习惯于夸大其词
我们经常会遇到这样的情况，一个级别本来并不高的需求，但是就是因为提出这个需求的第三方非常希望能够实现，他往往会增加许多形容词和量词来给我们一种压力，通常的有“这个需求非常（类似的还有：
相当；十分；绝对；等等）重要”，“我接触的客户几乎（类似的还有：
全部；差不多；大部分；百分之XX；等等）都期望有这个需求”，等等。
有时候确实能够让我们这些产品管理者不明真相，花了很多的时间去验证这个需求的重要性，如果果如其言也好，但怕的就是名不副实。
2、对于自我不太关注的需求，习惯于修修剪剪
这种情况也非常普遍，一个本来能够对我们非常有启发，也是客户非常期望的需求，在经过第三方的反馈后，可能
升级会员 