文|北小小运营记，来源：公关之家
记得第一次接触平台类产品时，我是一个运营人员，需要就这个学习平台的现状提出一些优化的方案。当时，我列了一堆长长的需求清单，拿着这份长长的需求清单，自信满满的交给产品经理，当然最后全被产品经理否掉了。现在回想起当时的那个过程，觉得还是挺小白的。需求提的方式不对，没办法说服任何人。
我当时对比了其他平台，列了一堆的需求清单，比如一级菜单跳出率，二级菜单跳出率，哪个地方要设置埋点，哪个地方又要干嘛干嘛等等，几乎完全是以一个购物型的平台来对标我们的这个学习平台。
这样的需求，列了一大堆，领导看着，觉得你好像思考了挺久的，写了很多的。但深入去分析那些需求时，其实都经不起推敲。
不管是从逻辑上，还是从可行性上。都只能说明你看待问题的角度之浅，以及你缺乏有意义的思考。
不管是产品经理，还是运营人员，当我们提需求时，都要基于具体的场景即：时间地点人物做什么事。根据具体的场景提出可行性的解决方案。当我们在讨论需求时，我们在讨论的实际就是一种解题思路。
因此我们应该切记以下几个原则：
Part1 忌盲目复制
不是别人有什么，我们就要有什么。你要理解别人这么设计的原因是什么，这个功能有什么使用场景，这个使用场景跟我们的产品匹配吗？这个功能加到我们的产品上面，可以带来哪些实质性的收益吗，不加又会怎样。
思考每一个功能的来龙去脉，而不是盲目的抄袭别人。
而且有些功能，在别人的平台是锦上添花，在你这可能就成了雪上加霜。
比如搜索的功能，这个东西对于用户体验来说，理论上当然很好。
有的产品，线上内容做的很丰富，用户随便一个关键词进来，就可以搜出一大堆的东西。
而你的产品内容很少，还加一个搜索框，用户一搜什么都没有，反正更加暴露自己的产品劣势。
Part2 一切围绕核心功能
任何产品功能的修改和优化，都是为了让核心功能锦上添花，给用户带来更好的体验。
当你想要提需求时，你要思考，这个需求影响到产品的核心功能了吗？改了的话会带来什么效益 ，不改的话，又会怎样。改的话需要为这个功能付出的成本是多少。
之前有过一个关于产品经理与研发人员发生冲突的新闻，某公司一位产品经理向研发提了一个需求，要求app的颜色能够根据用户手机壳的颜色变化 。
然后研发人员直接给了产品经理一拳，两个员工大打出手，最后都落下被开除的结局。
对于这个需求，从围观者的角度看来，这个产品经理确实也该揍。不管这个需求能不能实现，先说，颜色跟APP核心功能的关系是什么。为什么要为一些花边功能而浪费没有必要的劳动力呢。
在产品的规划上要扬长避短，遵循最小的MVP原则（Minimun Viable Product,最小可用产品） ，每一样产品的存在，都是为了”解决某个实际问题”，如果连基本的功能都满足不了，则意味着对用户来说没有意义，是一件无效的产品。
任何产品都是从小做大的，我们有时候要接受它的简陋，甚至到了残缺的程度。但前提是，再简陋的产品，也要保证有核心功能，可以满足用户的需求，以及可接受的体验范围。
Part3 理清楚需求背后的交付逻辑
如果产品经理只是在文档上写到了交互的层面，而没有捋顺背后的逻辑，也没有把功能框架拆分好，给开发同事的东西自然就会出现各种问题。
最忌讳乱提需求的行为，我想某公司的产品经理与研发人员之所以会因为一个APP颜色更改的需求，而大打出手。不可否认的一个原因，一定是产品经理没有想过需求的可实现逻辑。
有人可能会觉得我不懂技术，我只管提需求，至于怎么做那是你的事情 。
如果你是老板，你可以有这样的底气说这样的话，但问题是，大家都是同事，你凭什么高高在上的只提需求，而且是那些无理头的需求。
正确的做法应该是，你提的任何需求，都要去思考它实现的可能性，它能够实现的背后逻辑是什么。如果你不懂技术，那就更要认真的与研发人员讨论。
这是一种最基本的态度问题，大家平等对待工作，多站在对方的角度考虑，才能让对方更愿意去思考你的需求。
Part4 提需求要有理有据
这一点特别重要，你不能说看到别人的app有什么，你觉得你们的APP也理应该有什么才行。
提出任何一个需求，都要先思考为什么提的原因。是根据用户需求提的，还是根据大数据分析提的。而你加上这个需求之后，会给公司，给业务带来什么收益。
比如你需要开发一个拼团的功能，理由是因为拼团有助于产品的裂变，且这个功能对现阶段的产品营销很重要。
比如你需要开发数据库，因为数据库有利于产品使用情况的分析。但又由于现阶段用户少，数据量不大，这样的数据库开发成本高，实用性低，可能就不被接受了。
你要让研发看到这个功能将会给业务带来怎样的收益效果，让他意识到他值得投入时间和精力去做这件事。
Part5 写到最后
在与很多搞研发的同事接触之后，我发觉，其实大家都并不难相处。特别是技术人员，大多数的IT小哥哥都是很单纯的。
对于语言的艺术，并不是说要把话说的多好听。只要讲清楚每一个需求的底层逻辑，每个需求所对应的场景，每一个需求所能带来的价值，每一个需求需要修改的依据。同时多站在对方的角度，考虑需求实现的难易度，留给对方合理的时间安排。
有时，对方之所以不接受你的需求，一方面人家担心，你没有想清楚需求，辛辛苦苦做出来的东西，最后可能又要改。另一方面也担心做出来的东西，没有经过市场的验证，换了个产品经理，又是另一套。
而当你能把这些方方面面都想到并做到了，我觉得每一个理性的IT男客观上都会跟愿意帮你实现需求的。
