#43 点子到产品之间的路

点子与方案

阿信在会议上突然冒出一个新想法，他激动不已。如果这个点子能做到产品中，对市场中的其他竞争品牌就会形成降维打击。于是他开始迫不及待地推演，并对着同事兴奋地讲了自己的方案，甚至已经想好了原型怎么画。

这样的场景，相信很多人遇到过。特别是从事产品相关的，基本上都存着一颗不平凡的心、一颗想改变世界的心。我也是如此，经常会有一些奇思妙想的点想加到产品特性中，以为靠着这些从脑中蹦出的新点子就可以趟平行业中的竞争对手，打他们一个措手不及。

但后来的事实证明，产品不仅仅是一个点子就能支撑的，在产品从0到1的过程中，最先要确定的就是关乎需求的逻辑是否在产品上、商业上行得通。这要求我们在面对一款产品时，不能仅仅是一些零散的点，而应该有一个框架和定义来辅助决策，这个框架包括产品模型和商业模式。

产品模型让我们首先要确定一件事：用户到底为什么要用你的产品？

在之前工作的经历中，有一次惨败记忆尤深。当时我们团队打算做一款硬件产品，负责人和我们说，在基于他拿过来的硬件框架上开发，产品性价比会非常高。于是几个人开始分工协作，有人负责写实现逻辑，有人开始研究算法，有人开始负责整体产品的推广。当时有一个系统集成商也正希望换一款性价比更高的产品，于是我们一拍即可，项目逐步上马。可最后的结果却是产品的性能在当时根本无法满足现场的要求，在竞争对手都在使用CCD的时候，我们妄图使用CMOS想靠着软件算法的弥补剑走偏锋，结局自然是惨痛的。无法解决用户的问题，再好的合作关系也是没用的。（备注：CCD和CMOS为图像传感器的两种工作方式）

如果有产品模型的概念，那我们需要好好想一想产品的基础逻辑是什么，需求能不能良好地运转起来。在产品逻辑没问题的前提下，再把产品所有的关系捋清楚，画出流程图或结构图。然后再从底层的市场、需求、用户三个维度去检验产品模型是否合理。

商业模式主要是考虑清楚盈利的合理性。

作为产品，最根本的意义就是给用户创造价值、从用户那里得到酬劳。产品经理在考量需求时，也一定要考虑到商业的层面。“怎样赚钱”是实实在在的、与产品逻辑并行的关键问题。

还是上面那个例子，为什么该是你来挣这个钱？是产品确实达到了市场上独一无二的效果，还是能够给客户提供额外的增值或差异化服务？

如果说在产品模型中能把自己当作用户从头到尾演绎一遍使用流程，那么在商业模型中就要把每笔钱、每笔账都算清楚，它们流入流出会是什么样的情况，未必特别准，但至少保证不会在逻辑上都很难自洽。

团队：实施可能性

除了对产品整体逻辑和商业模型的判断之外，还要对团队的自我能力有清晰的认知。作为产品经理，尤其要清楚团队资源的状况。在当前的条件和资源下，到底哪些产品和功能是能够得心应手的，哪些产品和功能是会做得非常吃力的，哪些产品和功能又是遥不可及的，要有客观的判断，不要只顾着做“最好的”产品，却不考虑是不是有能力做这样的产品。

产品的核心价值

做产品过程中有一种取巧的方式，就是把所有的功能点都列出来，然后告诉开发人员：你去做吧。做好了说是自己想得全，如果万一有点问题也可以说：你看，我之前把这些功能都规划了，但是因为各种原因没有做或者没做到之前规划的要求。

不断发现需求、不断实现功能，这是一种产品开发模式；但还有另外一种模式，即基于产品的核心价值来展开，所有的功能都是在“核心价值”这个底层支撑上做文章。这样做的好处就是：不只是堆砌功能，而是做对用户和公司最有价值的；而且相同的核心价值能保证逻辑的一致和统一。

“核心价值”可用一句话来概括：是不是能真正解决用户的实际问题，或者说，对用户有什么意义？

比如，对于准确性要求高的仪器，我们说测量的参数多就不是核心价值；对于稳定性要求高的设备，我们说外观漂亮、搬运方便也不是核心价值。有一个比喻是这么说的：“就像你买一辆汽车，你开完了，你到了目的地，你说汽车里面的空调特别好，所以要待在里面，那不是它应该做的事情。”

另外，还有一种常见的误区，我们经常会说：“你看某某产品非常不好，所以我们的产品肯定行。”这种逻辑的问题是，某某产品不好并不代表你的产品就能好，产品目前状况“不好”的原因可能是市场不成熟、用户没有习惯，也可能是这个问题根本不需要解决。

在进行产品设计的过程中，最难的可能是我们始终在平衡，某个功能是自己认为的亮点带着自己的标签，可能这个是领导提出来的，另外的功能做好了能为公司节省费用，但真正却忘记了我们做产品，最终的最终其实是为了用户。为用户创造真正的价值，才是有意义的功能；能为行业甚至社会创造价值的产品，当然更加高级。

产品管理

无论是在产品组或者在开发组中，有些日常的管理工作总是开始信誓旦旦，中间马马虎虎，最后不了了之。之前有个同事说：最难的并不是制定策略和计划，盯执行其实是个更难的活儿，我深以为然。

产品经理原本的英文叫法就是“Product Manager”，也可以翻译成“产品管理者”。产品经理在维护和跟进产品的过程中会有很多环节需要管理，不光要管理文档、需求和流程，还要管理团队，甚至管理自己。从宏观视角我们要认识到管理的意义和价值，把控管理的节奏感和效果，从细节层面我们要熟悉管理的具体操作方法和技巧。

文档管理

文档管理说起来容易，做起来难。为什么这么说呢？一是很多人没有这个意识，二是有的文档模板本身也存在问题。作为产品负责人，该怎么对待文档管理呢？特别是交付给技术开发人员的文档。

如果用一句话概括，优质的产品文档应该是：交付给开发人员后，不用来回确认沟通。当然这是理想状态，但至少要保证文档没有逻辑硬伤、不缺失关键内容、逻辑清晰、可读性强。至于文档的格式，反而不是最重要的。

总结来说，不管文档是什么形式、篇幅如何，能让开发人员们看得懂的就是好文档；文档的完整性、逻辑性比文档的可读性、美观程度都重要。

需求管理

需求管理，在网络上已经变成一个调侃。每次产品经理和开发人员的“互掐”，如果必须有一个原因，那一定是因为需求。作为产品经理管理矩阵中最重要的一个内容，需求的关键程度自不必多说。如果不能对需求了如指掌，那功能实现必然是混乱的。

需求可以分为：需求获取、讨论和设计、待开发、开发、复盘等几个阶段，在不同的阶段，管理和处理需求的方法也有所不同。

在需求获取阶段，我们知道需求的来源有很多，所以在获取到需求这一刻，就必须做一个判断并且记录。判断是为了梳理出头绪，记录是为了方便回溯。此外，一定要把需求背景描述清楚，再根据背景提出相应的解决方案。这种“背景+方案”的形式，才是一个相对完整的需求。

在讨论和设计阶段，最主要的工作是需求的评审，可以采用「四象限法则」或者「KANA模型」确认需求的优先级，然后形成方案的草稿再和相关部门或需求提出人核实后，指定负责人按照时间节点计划继续推进。

在待开发、开发和复盘阶段，主要的工作是方案确认、实际开发过程的跟进、意外工作的协调，以及如果发生需求的变化、调整，通过及时沟通将信息传递给整个团队。

工作流中的管理

在实际工作过程中，我经常有这样的体会：有一些的确有用、但如果换成别的事情可能会更有用的事情。换句话说，实现一个目的有很多方法，但往往会选择最容易想到的而不是最好的方法。这样就导致花了大量精力在没必要的事情上，其一，你做的事情其实应该是别人做的；其二，你做的事情应该有避免重复劳动的更高效的方法。

作为产品经理，我们的工作并没有标准化的模板，一样规模的团队，类似的产品，同样岗位的产品经理却有可能在做完全不同的事情。所以，我们更应该在协作管理、流程管理、个人管理等方面反复思考，是不是可以做得更好。

产品经理面对的部门和环节比较多，有和技术人员的协作、需求方的对接、客户的沟通等等方面，是否能抱着“双赢”的心态便显得尤为重要。我自己也曾经在沟通过程中出现争吵、撂电话，甚至和客户沟通过程中不知道说什么的情况，但我的基本立场、做决策的依据一定是“对大家有利”、“对产品有利”，而不仅仅是“对我有利”。协作的过程中，可能涉及开会、记录等一些基础工作，也应该好好对待，曾经有员工反馈我们的会议和记录根本无法形成有效作用的时候，这时候最应该反思的是能不能拿出更好的办法。

后记

不论什么岗位，两个能力是非常重要的：认知能力和执行能力。这两个能力听起来普普通通，但唯有放弃心中的成见、加强学习才有可能得到成长。一些看似简单的小事情，诸如：把点子到方案之间的逻辑厘清、挖掘产品的核心价值、提炼自己的产品方法论、文档和记录管理、沟通、反思自己的错误、长期坚持学习和提升等，能坚持把这些基础工作做好、做到位的人，相信工作成果不会太差。

以上内容来自《从点子到产品》这本书的读后感。