大老板在下基层体察民情的时候说：“我觉得这里应该放一个饮水机”。那么很有可能“放一个饮水机”是伪需求，领导渴了是真需求。要满足真需求，需要做的是随身带一瓶水。要满足伪需求就必须满屋子的放饮水机。
　　客户说“我需要一个自动汇总每月销售数据的报表”。那么很有可能“自动汇总”是伪需求，“数据真实、灵活的呈现”是真需求。要满足真需求，需要首先做一个销售明细的Excel导出，在线外灵活的筛选求和；要满足伪需求就得准备好应付各种体位的“自动汇总”。
　　用户说“我想有一个批量审批的功能，每天点OA太费劲”。那么很有可能“批量审批”是伪需求，“梳理出那些值得我审批”的是真需求。要满足真需求，需要梳理一遍业务流程，不一定涉及系统的改造。要满足伪需求就得准备在做好一个“一键审批”按钮后再做一个“一键撤销”。
　　当用户直接提出解决方案的时候，往往意味着诞生了又一个“伪需求”。因为他们所指的方向并不一定能到他们所想去的地方。
　　用户随意指的方向和他们真的想去哪儿，就是伪需求和真需求的区别。
　　我觉得在需求之前，应该是产品短期和长期的价值体现和变量（这个产品的引爆点，一般我们都考虑用户量和日活等因素…）
　　第二个在需求之前的是框架
　　产品逻辑搭建需要的产品框架体系，使得产品能够按照既定逻辑进行，不至于引起偏差……（创意期产品直面客户大多谈模式，就算你拿原型去讨论他们也不会有太多问题存在）
　　在此基础下，在用户应用和头脑风暴中的问题，我把这些问题称之为需求，而需求的真伪我觉得应该这样划分（个人习惯）。一个周期内验证一套框架逻辑即可，在框架逻辑内的，是真需求，这些需求可以分为易用性、应用性、流程性三类。易用性决定了产品的难易使用度（我把这个称之为周期内的客户的脑容量），应用性则是产品测试期既定逻辑的错误、用户限制（也就是我们管的太宽）等问题的发生，流程性则是在整个产品链条上的既定、预估问题发生变化（这个不太好看出来，需要综合分析）
　　在产品逻辑、设计中，易用性最简单搞定，数据埋点和支撑可以让你看到你的客户在哪里跳出高或者点击强烈，客服也能收集到不少的类似问题，规划和更改着重在前端。（如果是B端的部分产品经理，已经可以进行用户思维模拟化的话，就自己去走原型流程，进行更改－慎用，很多问题不是你想当然的）
　　而第二个应用性是后端的功能性问题发生，一般这些问题发生，大多是我们脑洞太大，场景和客户要的有偏差（如果你是直接项目负责，那么恭喜你，想太多…憋着笑，改吧）这种便差的发生一个是数据分析得出（需要些基础和对产品全局的了解，不会分析数据的赶紧学），第二个就是客户通过客服，营销指导的次数呈指数级增加（史上最难操作：）），应用性会改变部分框架，严重的应用性问题会改变整个产品逻辑。
　　第三个就是我们的既定核心价值没有体现出来
　　客户误解，或者客户不关注这个价值。这类问题是数据整个的综合分析，（骚年，事情已经不是你能搞定的了，开大会吧…）这种场景蛮少见，小一点的公司看不到。
　　现在我们来说说辩识真伪需求～（这个难度很大，脑袋里有东西，但是没怎么总结过呢，我尝试下，大家表骂我…）
　　第一，伪需求后面藏着真需求；
　　第二，部分伪需求可以通过已有产品模块解决，只是客户没发现（这里反思流程和易用）；
　　第三个最难，客户说的直接需求不是他想要的或者表达的，我还是建议你直接问细致的，我帮你琢磨下…
　　没法举例，因为我做saas+B电商的，语言服务类，俗称翻译电商，产品及其产品构成以人的智慧和学识构成…
　　这里有些划水，迟到+上班，这两天我再更新一个。。。。
　　继续，仔细想了下，发现在上面架构中，辩识真伪需求已经不是很难的事情，难的是场景的多样性：
　　首先，不管是真需求还是伪需求，都是在一个量级用户下的需求反馈统合，我们在分析归类后进行的深度挖掘的结果，然后根据量级用户来选择具有偏向性的一方，选择的偏向性为最快到达你阶段性目标的…猜测或逻辑。（在初期逻辑和价值确认后，我们不在考虑产品大架构和大框架的问题，那么我们的思维角度就要从P的角度转向为C的角度，主要做的工作就是归类、分析、反思）
　　我做B端（客户拜访和沟通中的需求）
　　举例1：
　　我在上上个月和营销去拜访一个客户，为了传播产品的理念和模式，那么我主要介绍给他的是我们贴合行业特性的协同平台和只为公司服务的封闭式订单平台，而我带去的目的性是他用我的产品并感兴趣，我们互加了微信和QQ，在过程中，我期望产品的讨论主要在当前模式下的产品应用，那么这个东西涵盖了易用和应用性（这些是当时就可以分辨出来的），而逻辑性却是比较难的。
　　那么这里我开始编：
　　1. 用户提出，二级域名这个东西接受起来很麻烦，每次总是分不清楚；（不确认需求）
　　2. 用户提出，在订单平台其实可以有更多种服务，能不能把订单外的X种服务增加出来；（假需求，这需要另一套逻辑兑现和落地）
　　3. 用户提出 ，产品在某个模块点击不进去；（真需求）
　　4. 用户提出，X个模块在逻辑上应该是这样的…（不确认需求）
　　…
　　那么现在开始分析：
　　第三个需求可以马上判定为真需求，因为我们经常进入一个误区，就是客户理解能力和部分模块的稳定性；
　　第二个需求判定为暂时性假需求，其实这并不是一个假需求，而是在当前周期内，我需要验证的并不包含这条逻辑；
　　不确认需求中的第一个，是因为这是个个体现象还是一个群体现象？需要收集验证。
　　不确认需求中的第四个，分几种情况，你足够了解这个市场，或者你有做过调研，那么这个是假需求，是订制需求；而你刚进入这个行业，那么先判定成为不确认需求；
　　数据需求收集：
　　这个中间分为全埋点和只使用工具+部分埋点的，那么如果是第二种，你看数据的时候，就要贴合你的核心需求来看（这问题好大，MD，掉坑的赶脚啊）。
　　举例：
　　我们直接略过渠道验证，纯粹认为来源用户都是需求用户。
　　那么我要看的数据是：
　　注册转化率（7-15天周期内的变化）：我的核心是不是被清晰表达，逻辑被认可；
　　细节中间可以看（如果有的话）：
　　从注册步骤1-3，用户在哪个步骤退出率较高或者停留时间较长。
　　（前者说明此模块有问题，后者说明你给用户造成了麻烦，需要优化）
　　留存率（次日、周、月-这个数值在你了解行业的前提下可调，和活跃一样）：整个产品模块和逻辑是否吸引用户，痒点是否有效；
　　留存率分为刺激性和非刺激性（如果想深入知道这些理论，最原始的应该是斯金纳的书）。
　　…常规数据的略过好不，最多你从热力图，点击分布，点击数据等，能看出在你框架下用户最期望用的产品和用户的疑难点，这玩意不难理解，多看看多将心比心下就好。
　　那么其实重要的是部分埋点数据，关键数据的埋点可以让我们看到客户的大致使用范围，比如：
　　我想要看到客户登陆后，是先进Saas协同，还是先去订单中心查看下有没有适合的订单；
　　我想要看到客户登陆后，点击统计和设置的情况；
　　我想要看到客户登陆后，点击帮助和退出的情况；
　　我想要看到多少客户只用saas；
　　我想要看到多少客户只在意订单和收入；
　　继续细分，我想要看到客户在哪个页面退出率最高等…
　　这些都可以帮助我们找到客户的需求点，同时还有一个~
　　按照客户分级，单一客户应用的潜在需求可能是你平台上的其他需求，那么，做一个刺激性、单一流程性的活动是比较不错的…
　　以上：你已经根据这些内容开始修改你的前端、完善你的产品、帮助系统；并且从中区分出了客户主体，对客户的掌控性开始建立…
　　额，我忘记说数据需求中，数据偶尔会说谎这个事儿了，不过这个不太难，电话反馈、有将反馈或者问卷调研什么的，如果愿意，直接出一个新产品模块来看看是不是当初的问题引起的A/B版就好~
　　需求没有真伪，只有你对需求的把握是否准确到位。对某种需求有需要的人群，是否是必要即时去开发新功能的。需求分先后，产品的完善是一步一步的，先解决大部分人群的需求，再慢慢去完善解决部分人的需求。