产品规划师/经理(PD)需求分析的六个原则

2011-03-25 来源：网络

需求分析的六个原则（一）永远不要显得比客户更聪明

不知道大家想过没有，为什么要把这条作为产品经理进行需求分析的第一原则呢？

我个人觉的，之所以这条作为第一原则，就是告诉我们这些产品经理一个对待客户的基础态度，是什么呢？就是“平等”。

有朋友会说了，我们提供能够满足客户的产品和服务，客户付费享受这些，这肯定是平等的呀，有什么好说的呢？

果然如此吗？

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、对于自我不太关注的需求，习惯于修修剪剪

这种情况也非常普遍，一个本来能够对我们非常有启发，也是客户非常期望的需求，在经过第三方的反馈后，可能就是轻描淡写了，这还不是最严重的，最严重的是他们自己就成了一个过滤器，把许多他们并不关注的需求在没有经过正规的需求筛选过程处理后，自己就筛选掉了，给我们的只是他们包装好的需求集，或者说是已经丢掉了许多有价值信息的需求。

因此，国外有许多有经验的产品管理者告诫后来者，不要完全相信第三方提供给我们的数据，即使是专业的数据分析公司也不要相信，有营养的还是那些没经过什么加工的粗粮。

老汤好像有一篇博客就是说这个事情的：《产品经理工作法则一：相信自己的双腿，不要相信自己的耳朵! 》，推荐大家看一下。

3、对于自己想到的需求，习惯于私自增加

这个本来是没有问题，大家有好的想法，我们是非常欢迎的，即使是目前不能实现的，我们都会关注并长期跟踪的，但是问题就出现在第三方在反馈这个需求的时候，不是说这是我个人的想法，而是把这个需求包装成是客户的需求，如果再加上第一种情况，这就让我们这些产品经理确实难辨真假了。

因此，需求分析原则三第二点强调的就是：第三方可能会遗漏或补充一些额外的需求。

这里再加一句，这些额外的需求不一定是客户提出的。

那么，有朋友又会说了，对于这种对需求自由发挥的情况，我们是要坚决制止，还是睁一只眼闭一只眼呢？

两种思路都不可取，坚决制止，难免会影响团队成员的积极性，毕竟不能一棒子打死一片，广开言论的渠道还是必须的，睁一只眼闭一只眼也不行，那样会让自己消极懈怠，增加自己的工作量和公司的成本。

那么，应该用什么样的态度来对待呢？

其实并不难，就是“对第三方的自由发挥不应抱怨和生气，而是将其视为客户”。

其实这个态度里有一个核心的词，是什么呢，就是“客户”。

先抛开一些客观前提，我们可以想一下，如果我们把需求反馈者不分为直接和间接，从我们产品经理的角度看，只要是提需求的，就是我们的客户，其实这个问题就比较好解决了。

公司应该有一套客户信息反馈制度和流程，让现在的第三方反馈者和终端客户进入到一样的信息反馈体系中，对于我们来说，就不太容易受到同事或者上级这种特殊身份的影响，并且对于需求的分析，我们也会更加独立，而不太容易受到第三方个人情绪的影响。

当然，这只是一种理想的状态，正如刚才说到的，这是抛开了客观前提的，但是有一些客观前提也会很大程度影响到这个信息反馈系统的运转。

例如，你现在的公司是否有公开的反馈系统，是否有可行的反馈制度，是否有统一的反馈工具，是否有统一的反馈信息标准，等等吧，这些客观条件如果没有或者不够完备，同样也会影响到我们对需求的分析工作。

在这篇文章中，我简单做了一个需求反馈文档模板，大家可以下载下来看看，一个模板就是一个工具，本身没有任何意义，它必须存在于具体的环境中才能发挥相应的价值，等这个系列完成后，我考虑整理一下我以前在需求反馈体系建立中的一些个人经验，详细来谈这个该如何去做。

总结一下需求分析第三个原则的中心思想：

1、需求分析第三个原则：第三方也是我们的客户。

只要是对我们的产品和业务提出需求，就是我们的客户，应该一视同仁。

2、原则第一点：第三方一般会把自己想象成设计者。

他们对产品或许很熟悉，但是对整个业务可能不熟悉，因此，他们成不了设计者。

3、原则第二点：第三方可能会遗漏或补充一些额外的需求。

每个人都期望产品能做好，这种强烈的成功心理容易让人们产生日晕心理，从而影响我们对需求的筛选。

4、原则第三点：对第三方的自由发挥不应抱怨和生气，而是将其视为客户。

客户是第一位的，而他们又是我们的客户，因此，我们应该心平气和的对待他们的想法，无论这些想法是出于公还是出于私的。

需求分析的六个原则（四）客户和用户要区别对待

客户和用户根据产品的定位有时候是一致的，有时候则是分离的，这个大家都很清楚，通常来说，做企业级消费产品的客户和用户通常是分离的，做大众级消费产品的客户和用户通常是一致的，但也不是绝对，例如公务用轿车，应该是大众消费类产品，但是它多所面对的客户和用户通常是分离的，客户是各类政府公务部门，用户则是具体的操作者，也就是这些单位的工作人员。

具体什么是客户，什么是用户，我就不花很大的篇幅来介绍了，我想大家肯定都非常熟悉他们之间的区别的，其实简单一句话就可以概括：客户一定是掏钱的，用户不一定是掏钱的。

作为产品经理，其实在规划一个产品的时候，需要重点考虑的就是基于产品而要面对的这两类人群（其实还有一类，叫buyer，可以翻译成购买者，看了一些这方面的资料，感觉国内是把客户和购买者合为一体了，这样做其实也有好处，就是可以把抽象的客户概念在营销过程中具体成一个实际的人）。

04年的时候，我在一家为企业提供信息化服务的公司，负责企业信息化产品的管理，一次，我们的一个销售谈了一家半官方性质的公益组织，他们找到我们想用我们的产品搭建一套企业信息系统，包含内部信息管理和外部信息发布，但是那个销售人员只会拉单，对于具体的产品则不是很熟悉，因此，在确定了基本意向和他们的大致需求后，我就陪同这个销售人员一起去见这个准客户。

和政府客户谈单与企业谈单就是不一样，企业客户会直入主题，深入了解你产品的方方面面，但是政府客户就不一样了，本来想着花半天时间和客户沟通一下就可以了，结果一上午过去了，都没谈到实质的内容，客户倒是挺热情，中午的时又是他买单（呵呵，其实都是公家的钱）请客吃饭，搞的我们都觉得要是这单子不给对方优惠，我们都对不住人家。

下午继续聊呗，下午的时候他才找了一个他们单位里负责硬件维护的人和我们谈，离开的时候，热情的拉着我的手，对我们说“你们谈吧，具体的我就不管了，XX（维护硬件的那个人），你好好和小X（我的姓）他们了解一下，以后这个系统就是你的工作了”，说完，端着茶杯就到自己的屋子里醒酒去了。

具体和接下来这个哥们怎么谈的就不说了，但是因为这也是我第一次和政府类客户打交道，还真感觉有些不适应，但是通过这次谈单也给了我一些新的启发。

1、客户是客户，用户是用户，他们的关注点是完全不一样的。

就拿这个客户来说，之所以要上信息系统，目的就是为了响应国家政府机关上网的号召，说的直白一些，基本属于完成上级任务，做好政绩工程的动机，至于系统上去以后怎么用，怎么才能用好就不是他们要考虑的，而用户（也就是具体和我们谈的人）对于领导为什么要上这个系统就不会关注太多了，反正我就是一个一般工作人员，领导安排什么就做什么就行了，因此，在那天接下来的交流中，这个人就非常仔细地了解我们的产品到底是什么情况，都有那些功能，甚至都可以了解应该如何具体使用了，因为对于他来说，最关键的怎么能够用好这个产品，不要出意外而引起领导的不满。

2、关注点的不同，决定了我们在拉单，谈单，签单的时候要用不同的策略。

如果是企业客户，或许他们最关注的是价格和效果，因此，后来我在培训销售的时候，就告诉他们，对于企业客户，主要要突出咱们产品的性价比和售后服务，如果是政府客户，他们恰恰关注的不是价格和效果，而是购买了这个产品后，能够突出多少自己的政绩，有一次，我们又去一家政府客户，他们的领导上来就问我“你知道XXXX（他们同一个系统的同级单位），他们买这个系统花了XXXX（一个对我来说几乎是天文数字的价格）元，我们决定了我们的系统不能比他们差，价格不用担心”。

但是做过企业级产品的朋友都知道，政府类客户是最难伺候的，因此，到后来，一般遇到这样的客户，就安排其他人去应付了。

3、对于产品经理来说，如果说客户是销售要搞定的话，那么，用户就是我们要搞定的。

刚才那个例子中，到了下午具体谈的时候才轮到我发挥，上午的谈话对我来说就是一种煎熬，下午，我好好地和那个人谈了谈我们的产品，我们产品能够提供那些应用，能够为一个组织带来什么样的价值，并且也了解了他对于我们的产品有什么样的想法，他们希望能够解决什么问题，我们的产品有那些已经实现，那些没有实现。

对于下午的交流，我感觉双方都是非常满意的，因为我让他充分了解了我们的产品，也解决了他许多心中的问题，至少在向领导汇报的时候不至于稀里糊涂了，而他则让知道了他们更为具体的关于产品的需求，知道我们的产品应该如何改进才能更符合他们的要求。

因此，这也是需求分析原则四的第一点：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定。

那么，刚才说到了，企业级的产品，最终的决定权并不是在具体使用者手里，而是在这个组织的决策人手里（前面提到的购买者有时候也是决策人），在企业客户里，如果这个企业比较规范，那么，在决定购买一个大型产品的时候，往往会经过这样的一个流程，首先是对评估预算，然后是评估产品，最后是产品购买决策。

在这个过程里，可能会出现两类角色，一类就是购买者，通常又分为技术购买者和业务购买者，他们会分别评估这个产品的技术价值和业务价值，并且会把评估报告提交给决策层（可能是一个人，也可能是一个组织），为最终的决定提供参考。

而那些不够规范的企业，往往这些角色可能就是一个人，也就是企业或者政府中某个人就有完全决定权，无需什么评估和讨论。

从上面简单的介绍中可以看出，技术购买者和业务购买者通常既不属于决策者，也不属于最终的使用者，并且有些大型的企业也会采用第三方评估的形式来避嫌，因此，本篇文章中暂不讨论购买者的特征都有那些，我们应该如何应对他们。

关于产品能够给最终用户带来什么价值，在前面也提到了，其实一句话就可以概括：无论是企业组织还是政府组织，把这个产品用的能够达到领导的期望就可以了。

这一方面给这个组织中的最终用户带来了很大的压力，另一方面也给我们这些产品经理带来了压力，大家可以回忆一下，面对这类客户，我们要应付的事情是不是要比普通用户多的多呢？

而对于客户（决策者）来说，我们的产品又带给他们什么价值呢？

前面也提到了一些，这里总结一下，用我们专业的术语来说，就是要知道他们购买我们产品的真正动机是什么。

动机是内心的真实想法，而需求则是基于动机的外在表现，有时候是一致的，有时候是不一致的。

还拿刚才那个例子来说，这个组织购买我们产品的动机（其实就是决策者的动机）是什么呢？很简单，就是为了完成上级要求的政府信息化任务，并且通过完成，最好是出色的完成这个任务来增加自己的政绩。

至于这个产品到底是什么样子，有什么应用，能够真正为他们带来什么，这并不是他要关心的，会有下属为他打理好这一切的。

因此，这个产品对于他来说，价值就在于“能够为他带来政绩的提升”。

因此，这个产品在他眼里就成了一个介质，什么介质呢，提升政绩的介质。

因此，我们在知道了他的真正动机后，只要基于这个价值点去和他交流，往往都是能够打动他的，例如可以这么说“通过这个系统的对外信息发布平台，可以让你们的政务更加透明和公开”（符合国家提出的政务透明化的要求），还可以这么说“这个系统能够降低你们单位系统的沟通成本，并且提升办公效率”（符合国家提出的政府机关高效廉洁的作风要求），其实，打政府类的单子也不是太难办，主要就是摸清他们的真实动机，而这个动机往往是和国家对机关部门的规定要求，文件指示结合在一起的，因此，如果你是一个做企业级产品的产品经理，尤其主要客户集中在政府部门，那么，了解一些国家的制度规定是非常重要的。

这也就是需求分析原则四中第二点强调的：为客户寻找价值上的需求。

通过以上内容的说明，我们可以得出这样一个结论：

一个产品能够延伸出来的价值是多元化的，产品作为企业综合资源的市场载体，要面对不同动机的人的选择，不同的动机就决定了消费者价值导向的不同，而这正是产品经理在制定产品策略时核心的关注点。

产品经理依赖产品团队的工作而实现产品策略，针对不同价值导向的消费者需要不同的团队来完成。

在一开始的时候就说过了，当客户和用户一致的时候，那就是产品经理的焦点所在，例如针对大众用户产品的产品经理应该深有体会，需要考虑的因素应该是最全面的，当客户和用户分离的时候，产品经理关注的焦点就是用户。

这也就是需求分析原则四中强调的第三点：用户的利益高于一切。

总结一下需求分析第四个原则的中心思想：

1、需求分析第四个原则：客户和用户要区别对待。

客户是客户，用户是用户，有时候一致，有时候分离，这是我们首先要搞清楚的。

2、原则第一点：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定。

用户决定产品，我们需求工作基于用户，始于用户，归于用户。

3、原则第二点：为客户寻找价值上的需求。

客户是多样的，价值导向也是多样的，我们的产品能否承载多样化的客户价值决定了产品能否实现最终的交换。

4、原则第三点：用户的利益高于一切。

产品的最终价值是通过用户来体现的，脱离了用户的产品，就是“皮之不存，毛将焉附”。

需求分析的六个原则（五）用最简单的文字工具记录需求

需求是信息的具体表现，我们知道，一个信息进行一次传递，需要具备以下5个条件：

1、信息本身

2、信息发出者

3、信息承载介质

4、信息接收者

5、信息所处的环境

这5个条件的综合作用决定了这个信息最终的质量。

具体到需求这种和产品经理每日息息相关的信息上，我们都必须面对一个非常现实的问题，就是：如何来保证我们获得的信息的衰减性是最小，并且我们又如何能把这种信息尽量少衰减的传递给下一个接收者。

既然本章的标题是“用最简单的文字工具记录需求”，并且在本系列的第三章中，我提供了一个自己整理的《需求反馈文档》模板，属于记录市场需求的第一个工具，因此，在本章里，就以这个模板工具为例，详细来说明一下如何把需求记录好。

第一部分：

这个部分比较简单，主要是说明原始需求提出者的信息，具体包括三项：

1、需求来源：我这里是以我所在公司的情况写的，大家可以根据自己情况来定，其实这部分就是说明需求的市场细分，这个需求是个人终端客户提出的，还是企业级客户提出的。

2、来源方名称：说明需求提出者的名称，如果是个人，就是姓名，如果是企业，就是企业名称。

3、来源时间：说明需求提出者的反馈时间。

这项比较关键，因为咱们通常会发现，客户向公司的是市场人员反馈了一个需求后，市场人员往往不能及时反馈给我们，要么是想起来的时候才说，要么就是等着开会的时候才说，要么就是右耳朵进，左耳朵出，根本没放在心上。

因此，我在公司里一直强调有需求一定要及时通过这个文档反馈给产品部，当然，要让相关部门的每个人都真正重视起来，一是需要时间，二是需要规范。

第二部分：

这个部分就是针对内部第三方的了，主要是说明需求获取方的信息，在前面的文章说过了，许多行业的产品经理很少有直接面对客户的机会，因此，我们往往还是通过第三方来得到市场需求，具体包括5项：

1、需求提交人：这里用需求提交人，而不是需求来源，就是为了区别客户和第三方。

2、提交时间：说明这个需求是第三方什么时候加入到需求池中的。

3、所在部门：说明第三方所在的部门。

4、工作职位：说明第三方在该部门内的工作岗位。

5、PST位置：PST是什么呢？就是产品战略表（Product Strategy Table），关于PST的解释这里不多说，对于第三方来说，只要说明这个需求是针对那个产品线或者产品的即可。

第三部分：

这个部分就是针对需求本身的了，大家可以看出来，一共就三部分，非常简单，为什么呢？就是因为大家要知道，对于客户来说，他们在提出需求的时候，根本不可能按照我们期望的那样分门别类的告诉你。

有一次，我们的一个产品经理和一个客户进行需求沟通，他首先问客户“你对我们产品的功能有什么想法呢？”

对于客户来说，产品功能还是比较熟悉的，也多少说了一些，但是接下来问题就出现了，他又问客户“你对产品的UI有什么想法呢？”。

客户一下子就糊涂了，想了半天，问他“UI是什么？”，他可能也意识到这个词太专业了，于是又给客户解释说“UI就是界面，也就是产品的外观”，客户这次似乎是多少明白了一些，但是明显感觉在说的时候有些不够放开了，为什么呢？大家可以分析一下，你把UI就解释为界面或者产品外观，实际上在限制客户的思维，客户在每说一个需求的时候，就会想“我说的这个是和界面或者外观有关系的吗？”。

这或许还好一些，UI还比较容易解释，如果是UE呢，谁敢说能让客户很清楚的知道UE是什么意思呢？用户体验？估计用户会更没体验了，呵呵！

其实就是这样，对于客户来说，越是专业的词汇，越是把需求分的很细，在省了我们事的时候，反而会让客户很费事，我们要知道，获取需求的时候，一定是要让客户在思维上不受限制，让客户想到什么说什么就可以了。

在第三部分，也就是需求说明中，只有三个部分，即使是这三个部分，也不是由客户直接填写的，而是由公司第三方在获得了客户需求后，稍微进行整理后填写的，相对于第三方来说，他们要比客户更了解一些产品方面的知识，即使是这样，对于第三方而言，我们也不能太专业了。

1、产品需求：针对产品介质本身的需求内容，通常包括功能、性能、UI和UE上的，不要细分，用户怎么说的，就怎么写。

2、业务需求：针对产品营销层面上的需求内容，通常包括用户对产品的渠道、价格、销售、服务等方面的需求，撰写要求同上。

3、个性需求：有时候客户会提出一些我们看起来异想天开或者是我们没有预料到的需求，千万记住了，对于这些需求，不要一笑而过，一定要让第三方记录下来，有时候这些需求往往能够让我们的产品另辟蹊径，获得意想不到的成功。

第四部分：

这部分就比较简单了，就是要让第三方留下自己的联系方式，因为如果我们对某个需求有不解或者想进一步沟通的时候，可以通过第三方找到提出这个需求的客户，便于我们进行直接沟通。

从这个模板中可以看出，文章开头说到的信息传递的5个要素中，这个模板包括了4个，分别是：

1、信息本身：模板中的第三部分。

2、信息发出者：客户是需求的反馈者，第三方是需求的提交者。

3、信息承载介质：需求反馈文档。

4、信息接收者：第三方是客户需求的接收者，我们是第三方需求提交的接收者。

只有一个元素没有涉及到，就是信息所处的环境，这个环境虽然决定不了信息的传递过程，但是会非常影响信息传递的效果，也就是会影响到信息的衰减程度。

这个环境包含的内容比较多，我也没有很好的整理过，就不往下结论了，但是有一点是我体会非常深的，就是信息传递的环境包含一个非常重要的因素，就是“信息传递的环节”。

我们都知道一个传话的游戏，一个本来很有效的信息，经过的传话环节越多，那么到最后，可能已经和原始的信息大相径庭了，如果每个环节之间还是相互封闭的，问题会更多。

这就是需求分析原则五中强调的第四点：保持沟通的通畅，是了解需求的保障。

这个通常首先是每个环节之间一定要开放，二是每个环节的传递介质一定是统一的，三是要传递的信息一定是标准的。

许多企业花大力气建设CIS（企业信息系统），其实根本目的就是为了让部门间的信息流转能够畅通和高效，最终让企业的运转成本降低下来。

在做一些企业级产品的时候，我们通常会不断地和客户进行需求的交流和确认，如果采用快速原型法的开发模式，那么，我们还会在原型开发完成后，和用户进行需求的最终确认，这个时候，就会有一个问题出现了，就是“这个原型一定是要让客户无需太多思考就可以理解的”。

有时候我们会认为原型又不是成型的产品，差不多就行了，其实不然，对于客户来说，他们看到原型的时候就会认为最终的产品也是如此，因此，在原型上，不但不能掉以轻心，而且要更加重视才可以。

记得有一次，我们为一个客户做了一个产品原型，因为是原型，开发部门也没怎么当回事，许多细节地方都带着开发部门的专业印记。

例如，这个产品中其中有一项很简单的功能，就是在选项里可以设置是否“自动读取放入光驱中的光盘”。

但是在原型中，开发没当回事或者认为写中文太费事，于是直接就写上了“AUTO READ CDROM”，开发当然明白这是啥意思了，可是给客户看的时候，客户就是搞不清楚这CDROM是什么，解释了半天后，客户还是很认真地问“这个CDROM就是VCD吧，那CD能不能放呢？”。

后来我和开发说这个事情的时候，开发还满不在乎的说“不就是一个原型吗，没必要那么费事吧！”

我经常会遇到这样的事情，开发和产品经理说“产品原型差不多就行了吧，简单表示一下就可以了吧”，那个产品经理认真地说“嗯，意思一下就可以了，没必要花太多精力”。

还是前面提到的那句话：我们省事就意味着客户要费事。

因此，需求分析原则五中第三点强调的就是：不要希望客户能花更多的时间来了解需求转换后的模型。

要做到这点，就只能在我们获得用户需求的那一刻起，就要想着“我费些事，客户就可以省点事”。

总结一下需求分析第五个原则的中心思想：

1、需求分析第五个原则：用最简单的文字工具记录需求。

客户并不麻烦，需求也不复杂，麻烦的是我们把一切做的太复杂了。

2、原则第一点：所有人都能懂的东西，最不容易出错。

没有人喜欢复杂的东西，需求也不例外。

3、原则第二点：不需要再学习的东西，最不容易出错。

产品是需求的表现，没有人喜欢复杂的产品，要做到这一点，就从需求开始吧。

4、原则第三点：不要希望客户能花更多的时间来了解需求转换后的原型。

我费些事，客户就可以省些事，客户省事了，我们最终也就省事了。

5、原则第四点：保持沟通的通畅，是了解需求的保障

要实现需求的清清楚楚，就要做到沟通的反反复复。

需求分析的六个原则（六）天下没有免费的午餐

在前面的文章中，已经说到了这个问题，客户向我们提出的需求都是他内心最期望我们能够满足的，我看到一个朋友的留言，我觉的非常好，他是这么说的：

“客户不是我们的竞争对手，他没有理由来欺骗我们，因为欺骗我们的最终结果就是使我们做出不符合他们需求的产品”，“如果说我们的产品有问题，那么首先应该从我们身上找问题，而不是客户”。

我非常赞同这位朋友的观点，这个观点其实也表明了需求分析原则六所强调的第一点：客户从来没有不合理的需求。

理解这点其实很简单。

客户购买我们的产品，是由各种各样的因素决定的，有价格的因素，有服务的因素，但从根本来看，还是因为我们的产品能够比其他的同类产品更好地解决客户的问题（当然，最终的购买还是多个因素综合作用的结果，也就是所谓的“性价比”），客户在使用我们产品的过程中，一方面自身会有新的需求产生，另一方面则发现我们目前的产品无法满足或者有效的满足这些需求，因此，他就会把这些新的需求反馈给我们，并期望我们能够在接下来的产品中能有所改进。

这是一个再正常不过的逻辑，我想没有一个客户会向我们提出不合理甚至是虚假的需求，因为这样做的结果最终只能是两败俱伤，只有我们的竞争对手会这样做。

有朋友会说了，嗯，你说的这点没有问题，但是，我却感觉客户提出的好多需求虽然真实，合理，但是却是不现实的，这又该如何解决呢？

果然如此吗？

要回答这个问题，得从两个方面来考虑。

1、客户提出的需求有不现实的吗？

何为现实呢？客观存在的就是现实的，也就是说，只要客户提出了一个需求，那么就说明客户肯定是有这样的需求的。

之所以我们认为某个需求不现实，根本在于我们没有搞清楚这个客观是基于哪一方的。

这里强调一点，这种客观是基于客户一方的，而非我们一方的。

也就是说，有时候我们认为这个需求不现实，仅仅是从我们自己的角度来看待的，我们不是客户，不应该替客户判断某个需求的现实性。

还有一种情况是什么呢？

就是有些需求在我们看起来似乎是不现实的，但是往往我们一下子就否掉了，说“这个需求太不现实了，无法满足”。

许多产品经理就是这样来判断客户提出的需求的，而这恰恰犯了一个产品经理之大忌。

04年的时候，我们为一家企业做信息化系统，客户提了一个需求，是希望能够通过系统后台为他们的客户发送邮件，简单的说，就是邮件群发，当时我们那个产品经理一听，非常专业地对客户说：“要实现这个需求非常的麻烦，很不好做，并且可能会超过您的预算”，然后就用非常专业的知识向客户解释了为什么这个需求不太好实现。

这个产品经理说的有错吗？一点错也没有，说的非常到位，并且也是抱着对客户负责的态度，因为我们都知道，在服务器端假设一个邮件群发系统，首先硬件上要达标，包括服务器和带宽都要足够支持才可以，然后就是软件，必须要购买webmail系统（虽然有免费或者破解的，但是效果肯定够呛），最后就是由我们在客户的服务器上搭建即可，其实从技术上来说，并不复杂，难就难在肯定会超出客户的预算，并且还会超出不少，客户很难接受。

客户也接受了这位产品经理的建议，就暂且没有考虑这个需求，过了几天，我和这个产品经理聊到了这个事情，一开始我也非常赞同他的建议，但是我仔细一想，问他“你问了这个客户，他每次发送的邮件量有多大了吗？”，他说“没有呀”，我说“我建议你去问一下，说不定这个功能就能实现了”。

他在和客户确定后，和我说，“因为这家客户是为大型企业做服务的，他的客户量也不是很大，大概也就是不到1000家的样子，并且群发邮件的频率也不高”，我说，“既然如此，这就好办了”。

我们来分析一下。

首先，每次发送1000封邮件，这个量很小，根本无需搭建专门的webmail系统，第二，发送频率不高，说明就不用有专门的人来负责这个事情。

最终我的解决方案是：我在后台加一个邮件列表提取的功能，这样客户就可以通过后台得到所有客户的邮件列表，并且可以导出为常见的列表格式（确实比较简单，呵呵），然后找一个服务不错的邮件服务商，例如gmail（每天最大发送量为500封，不限单次发送量），这样不就搞定邮件群发的事情。

其实还有其他的解决方法，例如购买企业邮箱，但是那样同样也会增加客户的成本。

这个事情给我的启发就是：看起来对客户很不现实的需求，其实只要我们深入地和客户进行沟通一下，就能找到一个合适的解决方案，但问题是，我们有多少产品经理真正和客户进行过沟通呢？更别说深入沟通了。

没有沟通，就不知道客户在某个问题上真正的症结是什么，难免会出现头疼医头，脚疼医脚的情况。

只有把好了客户的脉，才可以知道是什么病，下什么药，用多少药。

这也是需求分析原则六中所强调的第二点：客户的要求都是可以实现的。

既然客户的需求都是可以实现的，正如上面那个例子说到的，根本上就是“钱”的问题，用我们的眼光来看，就是“成本”的问题。

假设需求已经很明确了，那么就是一个能否实现和实现到什么程度的问题，但归根结底还是用多少钱来做多少事的问题。