做一个和自己持续较劲儿的产品经理
同一个产品问题，一定会有他人给出更好的解决方案。身为产品经理的自己，不能在有所成绩时沾沾自喜、嚣张跋扈。做一个和自己持续较劲儿的产品经理。
产品经理的平庸或卓越，并不是决定公司以及其产品成败的唯一因素。我们经常看到一些不拘小节、丑陋不堪的产品大获成功。我们也经常看到一些流程混乱、逻辑矛盾、体验糟糕的产品，存在于我们的日常生活中。
好的产品，是产品、开发、运营等多方面相互协作的成果。我们不能把产品割裂成多个独立的模块，导致彼此之间失去联系。
如何验证你的产品创意？
做产品前为什么需要收集大量的信息？
产品失败纵有千万种可能。任何一个产品创意都不会独立存在，而是有着自己独特的行业定位和上下游资源。无论你对行业是否已经有所认知，但在产品创意之初，你要做的第一件事就是大量收集信息，并对信息进行针对性、系统性地分析。
信息收集的思维框架：如何快速地了解一个行业或产品呢？
上下左右、古今中外，这八字决是帮助我们快速了解一个行业或产品的基本策略。这八字决也是我们收集信息时所用的思维框架。
所谓“上下”，即行业或产品的上下游，要搞清楚产品的核心资源从哪里来，去向哪里，以及资源是否集中，是否存在没有被解决的痛点。比如一个文学作品的产吕，其上游是供稿来源，下游是广大读者等。
所谓“左右”，即广义的竞品、竞争对手；还可以行业环境，如政策法规、潜规则等。
所谓“古今”，即关心行业或产品的发展历程，大部分的问题都不是第一次出现，一定有前人试图解决过，从前人的实践经验中汲取教训，或优化，或革新。前人踩过的坑，现在千万不能再踩一遍。
所谓“中外”，即向发达国家、地域借鉴经验，从别的地域中学习成熟的模式为已所用。
如何高效地收集信息？
- 学习体系化的课程：体系化的课程，具有系统性、知识框架相对完整。
- 跟行业内专家深入交流：预先设计好访谈的问题框架，向行业内资深专家学习，是快速了解一个行业的捷径。
- 读书：读书是最有效的求和手段。
- 研读财报、券商分析报告、行业分析报告。这些报告都具有时效性，能及时地了解和判断市场的趋势。
- 行业资讯、文章、论坛：了解用户动态、客户动态等。
本节中着重强调了产品创意和信息收集的重要性，并介绍了“上下左右、古今中外”的八字决思维框架，以及常用的信息收集方法。
如何锤炼你的产品创意？
锤炼产品创意的第一步
在充分收集信息、了解行业知识和市场情况之后，在产品设计之前，我们要做一件非常重要的事，即沙盘推演。这是锤炼产品创意的第一步。在这个过程中，要不断地质问自己并回答以下三个问题：
- 行业未来会是什么样子的？
- 行业痛点和机会在哪里？
- 为什么你能做成，你打算怎么做？
行业未来会是什么样子的？
根据市场现状和逻辑，客观地对行业做出一些方向性判断，最好能使用数据说话。这是一种演绎法，对逻辑的拆解。
行业存在哪些痛点和机会？
对行业现状和趋势有了整体的判断之后，我们要从中找出痛点和机会。如何从利益相关者出发，去发现和挖掘他们所遇到的问题？既然是机会，往往具有风险性。
为什么你能做成，你打算怎么做？
如果行业趋势成立，痛点和机会也存在，那么接下来就应该思考你的优势和实现路径了。这个阶段，并不需要提供详细的解决方案，只要是大而化之的策略即可。
有时候，你应该给直觉一个机会
有些时候，我们需要暂时跳出沙盘，跳出这些路径、规则和方法论，给自己的直觉一个机会。有时候需要剑走偏锋，不妨去实战中寻找答案。需要注意的是，对一个行业新手来讲，这个直觉往往是不靠谱的，切勿把冲动当作直觉。
要不要相信你的调查问卷？
产品设计的敌人之一是闭门造车。当我们有了创意和沙盘推演以后，一定要去了解用户。了解用户的方法有很多，而调查问卷、访谈问卷便是其中之一。下面是关于用户调研的一些经验分享：
- 在做调研之前，先列清单和调研计划，以数据分析结果为驱动力去设计调研策略。
- 对用户调研，务必保证用户可以流畅地回答问题。你的问题要便于用户回答。
- 在调研中，要尽量少地提出假设性问题。
- 不要套路你的用户，也就是说不要有意地制造情境、引导用户回答，因为这会给用户带来干扰。
- 除此外，你还得跳出问卷，身临其境去观察和研究你的用户，这样可能更容易收集到你所需要的信息数据。
MVP 用最少的资源，给你的产品试试水
如果说前面的信息收集、沙盘推演、用户调研都算是纸上谈兵的话，那么这一步则是真刀真枪的动手阶段了。
即在全面投入和集团作战之前，用尽可能少的资源去试试水，验证我们前面几步中所做的假设。
MVP，即“最小化产品”，剧烈缩减产品范围，用最少的资源和成本构建出符合预期的最小功能集合，并投入验证。
MVP，算是精益思想在科技行业中的一种应用方法论，其核心是：不断地用尽可能少的投入创造尽可能多的价值。即“走一步看一步，不憋大招，低头拉一步车，抬头看一步路”。
从产品的角度来讲，就是围绕一个核心问题，创造性地提供解决方案，实现一到两个核心用例，以验证这个核心问题是否真实存在的，或者验证该解决方案是否能被用户接受。
除此之外，MVP 还可以用于商业化验证，验证产品模式是否成立。
使用 MVP 思想的一些原则和建议
把MVP思想用在我们的工作中，下面是几个重要的参考原则：
- 提前推演逻辑，不要盲目验证。在设计MVP产品之前，一定要搞清楚自己想验证什么问题，要收集哪些数据项，还要预测可能出现的结果。这好比是软件开发中的TDD思想，即“测试驱动开发”。
- 验证长板，而非短板。即在MVP开发时，一定要选择这个产品与从不同的功能。事实上，市面好的产品之所以能够立足，都是因为它的核心功能做到了最好。与其做一个不犯错但极其平庸的尝试，不如把一个长板功能做到最好。
- 选择创造性的低成本方案。用低成本的资源，去验证最关键的命题。
- MVP并不是永远正确的。MVP只是我们目标产品的一小部分、一个局部，其验证结果未必总是对的，我们认可MVP的思想，但也不可迷信MVP，切记不要一概而论。
如何设计低成本的MVP方案呢？
- 用人工替代系统。为了节省开发成本，我们常常很难一开始就为MVP产品设计出一套闭环的系统方案，但是我们又不得不使用闭环数据，那么该怎么呢？这个时候，我们不妨用人工来替代系统功能，即用人工协助完成系统的闭环。
- 使用第三方系统。如果市面已经成熟的便捷的方案，可以帮助我们快速地建立起MVP并进行验证，那么一定要优先使用这些第三方系统来实验，千万不要自己花时间去开发。让成本更低，就是最好的MVP方案。
- 创新规则，缩小场景。比如我们要开发一个客服系统，在设计MVP时，我们没必要真的去开发一个聊天系统，我们完全可以做一个 QA 问答页面即可进行 MVP 验证。
在产品经理的工作中，要学习很多方法论。但仅仅学会这些方法论是远远不够的，更重要的是要把这些方法论运用到实际工作中去。你需要亲自上战场，弄脏你的双手，才能真正地获得成长。
认真对待“产品立项”这件事儿
所谓“产品立项”，指的是在完成了产品创意的验证、产品设计之后，说服、协调各方资源、开始动手干活的过程。这个“产品立项”的过程，也需要注意以下问题：
- 识别产品的利益相关方，理解这个产品对各个利益相关者的影响是怎样的。让利益相关者心里有数。
- 明确产品需要，联合各方利益。对不同的利益方，用不同的语言去说明、协调并说明，平衡各方利益，并使得产品的总体利益最大化。
- 预算代价，合理地安排计划。产品经理常常没有直接调动资源的权力，因此在产品立项时，要尽量地说服拥有资源的利益方主动掏出资源。资源预算的原则是“谁做谁估计，多估几次，留足余量”，要考虑投入产出比。
- 产品立项，就是争夺、确定、锁定资源的过程。因此立项时，务必谨慎准备，提前演练。不可掉以轻心，吊儿郎当。
产品发布与检查清单
产品立项之后，就需要组织项目团队、设计、评审、开发、做项目管理和执行了。本部分分享一些与产品发布有关的经验和注意事项。
产品发布是产品面向用户的重要时刻，如果做不好，经常会灰头土脸地回滚代码。
使用检查清单 CheckList
CheckList
所谓“检查清单”，就是在产品发布上线前需要做的系列事情，比如数据库变更啊等。
三个检查思路
- 该知道的人知道吗？要确保产品发布时，让所有相关方都能明确地清楚本次产品发布的范围和时间。
- 预先在大脑中排练一次。把发布流程过一遍，如果有必要，还应该将其转化成文档，列出每一步的任务、负责人、可能的异常或预案等。
- 有预案吗？产品发布过程中，难免会碰到各种意外问题。你是否为这些可能的意外做了预案？没有永远一帆风顺的事情，必须要有风险意识、以及应对风险的策略。
2019-03-26
网友评论