产品经理避坑指南-尊龙凯时平台入口

一旦产品像大海一样深，生活就充满了坑。


不要害怕，今天就来谈谈如何避免这四个坑。


一进产品深如海，从此人生全是坑，这是很多产品新生的深情感慨！的确，在产品实践的道路上，无论是自己无意识的挖掘，还是别人的挖掘，新生经常会遇到一些大大小小的坑。


伤害自己，要么加班填坑，要么跪求开发帮助填坑，要么死在坑里白眼。


其实很多坑都是可以避免的，按照一定的规则谨慎做事。


本文告诉新生如何避免四个高频坑。


一、需求坑 大多数产品学生都听过答案不是一匹更快的马的故事。


我认为我们应该从这个故事中得到两个启示。


一是学会洞察需求，了解用户需要解决的核心问题。


第二，业务需求不等于产品需求。


产品经理应继续培养将业务需求转化为产品需求、规划设计产品的能力。


在实际工作中，很多新生因为对需求了解不透，不得不开发中途改变需求。


有些b端产品，甚至需求研究对象太单一，导致上线后无法满足业务需求。


这些问题将归咎于产品经理，导致产品经理的恐惧和自责。


那么，新产品应该如何避免类似的问题呢？个人认为有以下三点。


1.思考解决什么问题: 思维路径是解决谁？在什么场景下？什么问题？根据这种结构化的思维路径，在场景中思考需求将有助于理解需求背后的真实问题，然后根据真实问题思考产品需求；而不是将业务需求复制成产品需求。


如果是b端产品，需求方不止一个岗位；产品经理不仅要考虑日常运营商的需求，还要考虑上下游的管理需求和业务流程。


日常运营商可能只提到提高工作效率的需求，而管理者更注重控制和降低成本的需求。


特别是当两种需求之间存在矛盾时，产品经理应考虑，特别是管理需求。


对于b端产品，联系上下游业务流程的需求和孤立的需求，最终的产品方案可能会有所不同。


因此，在了解需求时，b端产品必须考虑上下游业务流程，甚至上下游需求方的使用场景。


一定要确认需求 当时不是这么说的，我想要的不是这样。


当需求方这么说的时候，往往会让新产品看起来很无奈。


那么如何避免这样的尴尬问题呢？需要在多个环节进行需求确认。


整理完需求后，确认业务需求；产品方案初稿完成后，确认产品需求；方案评审时，要求需求方和技术共同评审方案；产品推出前，应进行产品演示甚至试用。


甚至，针对复杂的需求，产品方案思路形成后，需要叫需求方和技术来评价产品方案思路。


通过这些步骤，可以避免许多需求与产品不匹配的问题。


产品上线后，等待成就感爆棚，不再需要灭火。


3、需求分类： 有时，需求方会提出一些相关甚至不相关的需求，其中一些收入很小，甚至是虚假的需求。


因此，产品经理必须根据收入来评估需求优先级。


高收入、高使用频率；低收入、低使用频率的功能，根据项目周期确定，建议在下一阶段进行。


需求分类后，必须与需求方沟通，并达成共识。


二、二。


很多新产品，一开始都是做产品迭代，很少上来做新产品。


迭代产品的问题是熟悉产品以前的逻辑，所以新产品需要考虑是需要新功能还是优化现有功能。


如果优化了现有功能，则需要考虑是否涉及产品流程的变化。


如果需要更改，请小心；否则，新功能启动后，原功能不能小，损坏。


那怎样才能谨慎行事呢？首先，检查产品文档，测试产品的所有功能。


其次，如果负责本产品的原同事还在工作，有疑问积极咨询。


第三，如果找不到产品文件，原产品同事也会离职，整理问题，找开发测试同学咨询。


如果这些人都离开了，那就太棒了。


此外，当涉及到生产过程的变化时，也要考虑是否对产品的上下游相关产品产生影响。


三、方案坑 如何减少修改方案的次数？这是许多产品新人想知道的答案。


特别是大方案上线前没有定稿。


与第一版相比，它不仅面目全非，而且小心翼翼地改变了产品经理的遍体鳞伤，这是一滴苦涩的眼泪。


小方案简单，一般变化小，新产品也能应付。


以下是如何减少大计划的修改。


对于大方案，在开始写方案之前，建议先画流程图和原型，原型不要做得太细。


拿着流程图和原型，与需求方和技术一起通过；然后，开始写详细的产品方案。


这比自己写计划要容易得多。


除了绘制流程图和原型外，产品方案中还应注意以下问题，如异常情况、边界极值、极少发情况等。


只有注意这些问题，上线后才能减少大量产品bug。


四、死无对证坑 对于已经确认的事情，每个人都很容易忘记细节，或者一时想不起来。


虽然产品经理是一项高度跨部门的沟通工作，但他应该每天处理各种事情，如需求、计划、日程安排、开发跟进、产品使用问答等；然而，建议新产品仍有电子邮件、文件等书面记录。


这将避免许多不必要的死无对证坑，这里的细节将不再展开，书面的东西如何帮助你，你知道。


以上是作者认为新产品在工作中经常遇到的四个坑。


由于团队风格和个人能力的不同，欢迎补充交流。


··················end·················· 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。


本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。


如有侵权行为，请联系网站管理员删除，。