记录一位新人做产品的经历，感受下其中的挑战。
1
Y 是做产品运营工作的，新入职一家公司，工作很卖力。
她想做精细化运营，但公司没有一个产品策划。我很想推动做这个事情，如果要做的话，只能自己来当产品策略了，不过先要说服老板同意这件事情，你觉得可行吗？她说。
我不了解你们业务，适不适合做这个事情。你要觉得合适，可以试一试。我说。
第二天。老板同意我的想法了，不过他要让我出一个 PPT，跟他汇报下，Y 说。我说，挺好的呀。高兴之余，Y 有些犯愁了。从来没做过产品经理，不知道该怎么设计产品，问我有没有需求模板参考。
我说，老板哪有心思看需求文档啊。你的 PPT 任务只有一个事情：让他认可这件事，然后你就可以启动这个项目了。把你的方案思路，流程，目标，预期，风险，有条理地说清楚就可以了，不需要详细地说明你的方案。不然光做这个事情，就得花很长的时间。
没多久，Y 跟我说，老板说 PPT 不是他想看的东西，想要看到具体实现方案。那就做吧，我说。好歹向前进了一步。规划可以写得大些，切入角要小，找到最容易突破的那个点。确保做完第一期，有明显数据增长。这样，也容易拿到老板信任，继续往下做。
老板说我的方案不是他想的，Y 有些沮丧。刚入职两个月，想做出成绩，所以积极地提了新方案。但现在感觉跟老板沟通不畅。
搞清楚老板的想法很重要，这跟理解用户需求是一样的。如果你真不知道老板怎么想，最简单的方法就是直接问他了。总是揣摩的话，你的方案改一次才能确认一次，不得累死。反复改的话，老板更会不高兴的。
Y 说忙死了，有好多事情都要处理，每天都要加班很晚。
我说，如果不能确定每件事情都能做好，就做最重要的那一件，其它的先不要管了。
每个事情都很重要，她说。
我想起了业务方提需求场景
每次排需求时，先要收集业务方需求，每个业务方都要先排出优先级，汇集完不同业务线的需求后报给领导，再定最终优先级。收集需求时，业务方总是至少提 7 个需求，优先级都是 A。我说，按 1-2-3-4 排序提，提 3 到 4 个就好了。因为，最终能有 2 个需求排进去就不错了，不然还增加了所有人的筛选成本。
业务方总想的是，我提了一堆的需求，你总得给排进去1个吧。关注的是量，却忽略了重点：提出高价值的需求。
2
方案基本通过了，Y 开始设计产品。为了赶工，Y 利用中秋节放假的时间加班，画原型和写需求文档。她之前没有用过 Axure，还问我在哪里下载 Axure。
节后，Y 发给我一个截图， 上面是 3 个文件：两个 Axure 文件（原型图+流程图），一个 Word 需求文件。问我有没时间，跟她沟通下这三样东西。我说，发给我，晚上看吧。
到了下午。Y 说，刚跟老板对完，老板说太简单，想要的一个 CRM。她正在收集 CRM 相关的资料，继续改。他们公司并没有 CRM。
在于功能，不在于名字吧，我说。
老板希望的系统是很全面的，我的这个只是其中一个小分支，给他的感觉他说是那种比较简单的活动，Y 说。
由小到到大是个过程，管理下老板的需求。我说。
老板的理由是需要给技术说清楚，之后要做的系统后台大概是什么样子。目前的设计是会让技术误判工作量的。这个从小分支功能到多项内容包含在这个系统里，后面实现会难吗？Y问我。
系统工程自上而下设计是理想的，我说。求大白解释一下，Y 说。
如果有人想当马云，按马云走过的路来设计自己要怎么走，这是不可行的。我说。
我之前一直以为需求是明确的，我是负责用户增长的运营。我需要的就是一个可以满足我配置策略的后台，能大规模做用户营销。但是刚刚和老板对完，才发现，老板想要的一个CRM。现在在想怎么挽救老板心中的人设，他现在肯定在想我的这个后台怎么这么简单。Y 表示无奈。
做好自己能做的就好，我说。
3
Y 要跟研发过需求评审了。
她说，原型比较简单，没有加交互，就那种点一个按钮就展示另一个，还没有学会。老板觉得交互也很简单，不好使用，要重新改。
老板喜欢什么样的，那种就好了，我说。
她说，原型是不是职业 PM 看起来很不行，标签应该怎么圈选下才清晰和好管理呢？
能帮开发理解就是没问题的。你老板觉得交互要好，就让交互设计师做。我说。内部的后台产品是没必要花时间在这个上面的，特别是资源紧张的时候。
我觉得我画的呢？她继续问。我说，慢慢来。
你的评价是啥？可以点评下吗？她还在追问。我感觉到她很在意原型，但这个并不是产品的重点，没有回她。在第一次用 Axure 之前，我都是用 PPT 画原型，不同的工具影响效率，但不影响表达。君子不器，是同样的道理。
Y 宣讲完了需求，说自己被前端喷了。被喷是正常的，对方说的对就记录采纳。
我做成复选框了，但是他们说要改成可配置页面，Y 说。我说，觉得不对的争议，大的就先放一放。把主业务讲完，再回过来看。
被喷是，觉得不是产品经理。你一般是怎么主持的呢？Y 问我。多理解对方，再讲东西，我说。
咋理解，比如？Y 问我。前端可能因为实现成本高，不想做。或者不认可，因为不常用。我说。
Y 说自己的流程是这样的，首先我先讲下这个后台的流程，大家有问题可以流程过完后地起再问，然后我就开始讲了。但别的人给我说，前端问他，你就是这么过需求评审的吗？
你是这么过需求的吗，Y 问我。
我说，背景-目标-需求：
流程。
功能范围。
实现方案。
Y 问，我刚才的那个方案可以吗？我说，应该是比较理想的，一次讲完，中间都不问。
4
前天，Y 问我，知道分桶实验吗？不知道，我说。
她总是会问我一些产品相关的新词汇，总是有一些我都没听说过的。
从她第 1 次询问我产品设计到现在，快 3 个月了。希望她的第一版产品能尽快上线。
产品最大的风险是没有成效，比如，用户得不到增长，业务得不到增长。其它的风险都是间接风险。抓住这一点，意义在于每一次的输出在于求所得，并不在于求完善。完善是一个演进的过程，需要每一个点的连接，持续有效。盖尔定律总是有效的。
需求与资源需要平衡，运营，产品，设计，研发，每个角色要理解并绑定在同一目标上，做好自己能做与值得做的事情，而不是为了付出辛勤劳动干活。
产品管理的极限是对人的管理。人的管理有两面：自我的管理和他人的管理。
自我的管理影响的是在组织中发挥的作用，始终明确业务的目标，知道事务的优先级，做出合理的安排。
他人的管理与组织架构没有关系，他人可以是上级领导，可以是上游的运营，下游的技术，也可能是你的下属。了解对方的长处，清楚他的短处。从对方角度看问题，有利于明白现状，做出合适的决策。
文章首发于公众号-野兽说（monster_talks）,欢迎关注，查看更多产品内容。