情况一：用户的需求合理且其实当前是基本满足的，只是并非完全符合他想要的。
举个场景：产品后台中对于数据部分已经有了流量数据、用户画像、订单数据，但你的用户希望后台能够有更多的数据分类，并不断的跟你提这样一个需求。
而数据的关键是在于如何通过数据现象看到本质，继而形成解决方案；同时你们自身的规划上是将产品的数据版块的深度做得更好，而非狂加各种数据的类型。
这时，正确的引导在于——作为运营你可以通过自身的专业能力先帮助用户当前的现状进行一轮分析，让用户意识到自己当前存在的问题，使其重点在于对现有的数据分析好、加以利用好，而非浮于表面的数据种类是否丰富。
情况二：用户的需求不合理，且只是站在自身的角度考虑。
面对这样的用户需求，核心在于怎么判断“用户的需求合不合理”。
首先，肯定是基于你自身的判断力，其次是将需求向上输出转移到产品人员，由他们进行判断，但原则不能变。即：所有的产品加减法，都是围绕着产品的标准化去的，而非个性化定制。
当然，如果这个用户很重要，且需求对他们自身为必要的话，可以做特殊满足，但这个“满足”一定是要基于定制收费的基础上的，否则用户将形成“张口即要”的恶习。
三、 避免 C 端运营思维陷阱
在文章一开头我们也说了，关于目前市场上的 B 端产品运营的一些方法论是很少的，可以说是奇缺的。
而相反，C 端产品的运营干货书籍文章那是一搜一大把。所以，就会导致很多人运营 B 端产品的时候，都会不自知的把 C 端的运营思维或多或少地嫁接到 B 端产品身上——特别是对于刚推出自己的 B 端产品的时候，直接就会从公司内部抽调人手去直接负责运营。
从各个角度上去看，这两类产品的很多方面都不同，所以就有不同的运营方法。
比如 ：C 端产品的考核指标相对直接，可以定量分析，如日活跃用户数、月活跃用户数、用户增长率、营收相关指标。
而 to B 端产品因为其产品形态的问题， 在为 Web 端产品团队制定 KPI 考核指标的时候，都是围绕系统建设、效率提升、工作能力进行指标构建。
