技术驱动型公司产品经理的日常
导语：
产品经理的工作内容很大一部分是由产品的属性决定的，我们需要对产品开发的阶段和面临的各种情形了如指掌，并及时反应，调整工作重心。本文翻译自Dan Schmidt 发表于Quora的文章，主要讨论了三种场景下产品经理的日常工作。
场景一
正在开发的产品，其假设有待检验 － 找到一个快速、低成本的方式来验证这条假设。
To do
设立评估产品的标准框架。选择合适的定性或定量反馈机制，确定产品面对的用户群。评估体系不一定遵循传统，要根据产品的特殊属性来确定。
按照需求，设计最小可实现产品来检验假设。不同的产品需要抽象出来的维度不同，有的偏重设计，有的偏重功能性。产品经理需要明确为了完成检验必要的最少工作量。
严格按照优先级开发功能。保证工程师只按照最小可实现产品所要求的功能来进行开发，不要浪费宝贵的时间在其他暂时不重要的功能上。
Not do to
不要寻求最优化。这个阶段，纠结如何提高5%的点击率是无意义的，重中之重是向公司证明你的产品价值从而获得各方面资源的支持。
引导开发团队确定开发架构。要知道在没有经过检验时，你对产品的认知可能并不一定是正确的。
不要打乱开发团队的工作重心和节奏。公司上层急于想看到成果的心情可以理解，但这种焦虑的情绪不要传递给工程师，要保证他们的开发步调，直到实验结果清晰。
场景二
产品假设被验证，是时候规模化生产了！－当核心指标呈现出可喜可贺的上升趋势时，产品经理的工作重心会发生很大变化。
To do
寻求最优化。在第一个阶段我们确定了核心框架并让公司看到了产品价值，到了这个阶段，我们应该利用其带来的宝贵资源，运用A/B 测试或者用户访谈等方法，做好定量及定性分析，搜集用户反馈，和开发团队一起快速高效率地推进优化。
促进用户增长。产品通过检验意味着可以它能为公司带来更多的用户，产品经理需要尝试SEO、发送推广邮件、推送通知等不同方式去吸引新用户或重新激活老用户。
Not to do
不要在没有明确假设的情况下重新设计。不要被外在的声音左右，盲目添加新的功能和设计，要避免不必要的风险。
不要忽视系统基础设施的影响。不要让你努力的结果由于系统bug和网站性能而功亏一篑。
场景三
产品假设未通过检验－你需要带领团队重新建立假设进行测试。这种情况下需要更多地发散性与前瞻性
To do
引导公司理性地面对阶段失败。当某个假设不成立时，公司有可能会采用比较极端的处理方式，摒弃掉与该产品相关的一切，这时候你需要让公司理性地分析，弄明白究竟问题出在哪里，从中汲取的经验和教训可以如何借鉴到下一个假设的验证中去。
寻找并明确符合公司发展和市场需求的产品机会。随着每一个假设经受检验，公司的本质也会逐渐明晰，团队的整体优势和激情是什么，哪些软实力会激发出最大的潜力，哪些核心价值与目标让公司凝聚。梳理好这些能更好地帮助公司找到定位，找到合适的市场机遇。
Not to do
不要放任士气低落。如果公司就此决定改变产品方向，请确保这个决定不会影响到开发团队的斗志，不要让之前的付出看上去毫无意义。
不要彻底的反转。力图避免一锅端的处理方法，相反，要结合公司当前的优势和实力，从过去完成的工作中提炼出有效成分和有用经验，在此基础上找到新的方向。
不要感情用事，紧抓过去的开发成果不愿接受新的方向。虽然眼看倾注了大量心血并为之奋斗的产品被放弃并不容易，但你必须要知道什么时候该放手，做好转折与过渡，投入到新的项目。
虽说产品经理在面临不同的情形时，工作重点和内容会有偏差，但以下几点是每天都必不可少的to dos
掌握产品大局和方向的主导权。要做到这点，作为产品经理，必须要对公司当前的方向及高层思路有深入的认识，并充分理解为什么公司要做这样的决断，保证产品思路与之契合。
改善产品开发流程。开发过程中难以预料会发生什么，但通过积极自我分析，积累经验，逐渐了解该怎样去合理切分复杂任务，提高效率。例如，即使产品假设检验可能会失败，但依然可以从中学习到如何更有效地检验新的假设。
沟通。产品经理肩负向团队的成员解释需求的任务，也要向其他利益相关者介绍产品，要保证开发在正常轨道上顺利进展，有效的沟通是日常工作中不可或缺的一部分。
原帖Dan Schmidt 发表于Quora
本文译者： 贾婧（点融黑帮），现任点融网投资端产品经理，斯坦福大学国际教育学研究生毕业，由好奇诱发的转型一步从教育界转入互联网金融领域成
关键字：产品经理, 产品
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
