（微信：neutyz，微信公众号：U-4EverYoung）
最近跟很多产品同行在不同社群里面交流产品心得，这其中各种行业的都有，有2B的产品，有2C的产品，讨论的很深入和激烈，收获很多，自己也很受启发，有很多思考，想迫不及待地尽快总结记录下来。
正好借着这种“如鲠在喉”、“不吐不快”的状态，把对最近交流的思考抓紧时间写下来。
因为聊得比较杂，讨论的问题范围比较宽泛，接下来的文章只挑几个问题来写，会先描述其中某些典型的问题，然后再针对问题做仔细的思考。
问题：
产品人员如何更好的利用数据向业务领导汇报，并可以讲的深刻生动，从而更好的支持业务领导做出决策呢？
我的思考：
产品应该围绕核心业务，少给文字，不要直接给数据，把数据包装成图示，多给图看，多基于现实数据，指出问题、分析问题和解决问题。（脚踏实地）
通过对问题的优化和解决，来推导预测未来业务趋势变化。（仰望星空）
也就是传说中的脚踏实地，仰望星空。
对于指出问题和分析问题这两部分工作的具体方法，我建议如下：
先给出绝对数据的折线图。
这个就是所谓业务直接数据量的变化情况，比如前一年度十二月份收入是2万元，一月份收入是10万，2月份是30万，3月份是40万，4月份是45万，看上去业务还不错，金额都是再增加的嘛。
【这个看的是业务金额的绝对值，负责反应某段时间内，已发生的业务盈亏】
再给出对绝对数据求导后的折线图。
这个也就是对上面绝对数据折线图斜率的再描述，也就是传说中的环比，也就是传说中所谓增长率的绝对折线图，按上面的数据就是一月份增长率400%，二月份增长率200%，三月份34%，四月份13%，看上去业务似乎有瓶颈了，增长乏术啊。
【这个看的是增长率的绝对值，负责反应某段时间内，已发生的业务增长速率】
再给出对绝对数据求导后再求导的折线图。
这个就是增长率的增长量，按上面的数据，这根曲线是往下行（增长率是负增长），从图示上任何人都能直观看出来这根线很难看，很有问题。
【这是看的是增长率的相对增长率，负责反应某段时间内，已发生的业务增长趋势】
基于数据给出图示是基础，是吸引业务注意的先决条件，接下来是分析问题、解决问题的时候了。
等你围绕你的业务场景，分析完问题，并给出解决方案后，可以大胆做出你的预测，这个预测一定不完全准确，目的是抛出来，吸引业务，并让领导来否定、肯定或建议。增加领导的互动和参与感的，也便于带动他思考。让业务领导们从被动听你讲的状态，进入他主动讨论思考的状态，从而引发他下一步决策的动作。
总之，业务人员是很想关注数据，但他们可能对数据没有产品经理那么敏感，因此产品人员对业务做数据分析和业务讨论时可以试试我前面说的“脚踏实地，仰望星空”。
问题：
你喜欢和怎样的交互设计师合作？
我的思考：
大厂才有交互设计师，小厂都是产品经理承包全厂的交互设计。
我很多年前就开始进入小的创业团队，团队没有奢侈的配备专门的交互设计师，所以全厂的交互设计都被产品承包了。
关于如何基于业务模型和产品模式来做出好的交互设计，这部分我经验是丰富的，后面可以单开一篇文章来写这部分内容。
问题：
作为一个音乐类产品的产品经理，最重要的能力是什么？是不是要优先做好断点续传、本地保存、后台挂起等技术功能？
我的思考：
最重要的根本不是产品的功能和界面，以及什么所谓的断点续传、本地保存、后台挂起等等各种技术，这些都不是根本。
根本是业务的本质，也就是：
为什么要做音乐类产品？为谁而做？为这些人做音乐类产品是为了什么？
我做这个音乐想解决哪部分人哪种场景下的哪些问题？
应该第一优先把这些问题想清楚，这些问题的答案才是最重要的。
我随便举一些例子：
如果是想解决古典音乐发烧友寻找稀缺或冷门古典音乐的问题，那你要做的首先是看自己有无能力搞定古典音乐的资源，如果你的团队解决不了这个问题，那么针对这个人群的这个产品就不要做了，做了也不解决这批用户群的问题，不解决问题就没有意义，也不会有用户会关注和持续使用。
如果是想解决某些人群休闲时的时间消耗，那你要做的就是瞄准人群的品味，让别人消耗时间的时候有愉悦感，可以很轻松的在你的产品里虚度光阴，这时候你的音乐库不一定非要那么全，这时最重要得是算法和命中率的问题。
所以，核心是业务本质，核心是想解决哪部分人哪种场景下的哪些问题？
我们做产品经理的，我们是产品的第一负责人，产品成功与否我们要负很大的责任。
在这样重要的责任下，按优先级来看，无关的事物要先抛弃掉。
产品经理们看问题要直接一些，要深入一些，要能够直抵业务的核心本质。这样才不会把时间纠结浪费在按钮摆放、页面布局、技术功能这些后续的事情上来。
（按钮摆放、页面布局、技术功能这些工作，当然也很重要，但产品的基石是业务的核心本质，没有这个作为基础，一切都是流沙上的建筑，分分钟垮掉。）
问题（最后一个啦，很好玩的问题）：
产品经理如何避免被程序员打？
我的思考：
我认为这个问题，应该这么考虑：
为什么程序员要打产品经理？为什么人要打人？通常人们会在什么样的场景下去打别人？
我想人们都不会随便乱打人的，能够打人的时候是语言已经无法宣泄自己的情绪了，只能用身体动作来表达自己的态度了。如果语言可以很好沟通，并疏导自己情绪的话，那么我们没必要用身体动作来白耗我们自身的能量。
所以，看上去，这个问题通过沟通能够解决。
那这个问题的本质就又变成了：
产品经理和程序员之间怎么做到顺畅、高效、互相不憋气的沟通呢？
我觉得是这样的：
产品要懂点儿技术，当然最好是技术出身。
产品弄明白业务场景，围绕核心业务做工作，看问题直抵本质，弄明白业务为什么存在，怎么让业务更好，这个是最重要的。
别老是纠结某个按钮放这里还是那里，某个地方用实线还是虚线。
更别老是让某个按钮今天放在这里，明天放在那里；某个地方今天还是实线，明天让人改成虚线。
这样即便不会被打，可能也会被别人腹诽吧。
另外，常常有：
某些产品经理，在最基础的产品落地实现的环节做的不好，比如自己的PRD不写清楚，原型不做清楚。
每当程序员问起来就说“这个你参考下某某App，就按它那个页面那么弄”。这种方式真的很“欠打”。
我认为所有产品描述不清楚的，都是产品人员自身能力不足，自己没想清楚，然后让开发人员参考某某App，这种对自己都没有要求的人，不尊重自己职业的人，别怪别人不尊重他。
当然了，程序员打人还是不对的！！！再说了，万一打输了，程序还要去写，那不是更令人气愤嘛！！！
例行总结：
这几个问题在最近讨论中，非常典型，特别拿出来说一说，大家对于这些问题，怎么看呢？
欢迎关注，欢迎讨论！
（微信公众号：U-4EverYoung）
网友评论