作者：固执有解药
作者授权早读课发表，转载请联系作者。
欢迎投稿到早读课，投稿邮箱：mm@zaodula.com
小女子开发出身，三年java开发经验，码键盘能力不比一般公猿差，且自认为以自己的思维能力一直合适干开发(因为觉得只有开发才能不让自己的智力浪费)。But one day在一个一堆以公猿为主的程序群里，小女子被一堆公猿撺掇去转市场转销售。基于这个推力以及个人兴趣爱好和曾经伟大的梦想，小女子走上了产品的不归路。（谨以此怀念祭奠一下曾经的程序路）
下面谈一谈这一年多产品路的一些坑和心得：
对于产品经理这个八面玲珑的岗位，流程上的东西需到位，销售、市场、研发、测试、运维、采购、领导，与如此多形形色色的人打交道，必须有个完善的管理流程。
论立项的重要性，就是当产品问世要测试时，却发现特么没有固定测试人员（做产品后越来越汉子了）。立项会确立产品团队，明确各自责任，保证产品有序进行。
论需求评审的重要性，一些边界性的不确定性的因素在需求评审时可提早发现，防止开发中需求细节不明确。在讨论需求的时候，程序猿一般不想在会上讨论，他们更愿意看文档，然后自己默默开发，但是开发中或完成时却提出各种各样奇葩问题，所以在开会时，一定要和他们讨论清楚。
论流弊需求文档的作用，流弊的需求文档不仅明确了产品的各种细节逻辑，且开发测试愿意拜读，研发测试干的都很有激情的样子，自己也装的像个样子，484。
论邮件在部门间沟通的重要性，跨部门的协作都有各自的职责，防止后面问题出现时扯皮现象，邮件显得很有价值的样子。
小女子得幸经历了产品从0到1的过程，也经历了团队从0到1的过程，期间的困难现在回想起来都一把泪；记得刚开始时团队android只有一个初级外包攻城师，ios一个初级攻城师，我不仅要对接客户需求，还要指导开发完成开发，甚至和开发写接口文档，协同测试一起测试。这一段岁月让我明白了团队的重要性。专业的人干专业的事，效率更高。现如今整个团队已发展为40人，产品也已经迭代了多版。一切已走上流程。
我比较幸运的是第一款产品便是为阿里做产品，传统科技公司首次触碰互联网公司。在和阿里确定产品时间内，我们为一个问题会争得面红耳赤，但是这种争吵只会让彼此更了解产品，让产品更合理，产品体验更多的适应于各种各样的群体。经过几天的争论讨论，最后定了产品版本。在随后的产品开发迭代中，争吵无可避免，但我享受这种争吵，争吵的过程虽然有些激烈，但是好处却是大大的，不仅有利于产品的发展，对团队成员也是一种相互了解的过程。
对于初步踏入产品的童鞋们，产品文档太重要了，研发等待prd，测试等待prd，想要研发为开发的东西负责，测试为自己的测试结果负责，那产品得为产品需求负责，产品需求落实就是prd。所以写得一手好prd对整个产品的交付有着不可磨灭的作用。各位童鞋提升自己prd实力吧。
产品任务下发后，要实时跟进，实时了解产品存在的问题，尽力协调解决。做到自己是当下最了解产品情况的人。
迭代要先想清楚迭代需求，不要为了迭代而迭代。迭代一般需要数据说话，交互数据，产品数据，结果数据，这都为迭代提供参考。
我是技术出身，意料之中，并不会像其他人那样忽悠，在这一年多的产品路里，我实事求是，脚踏实地。但有些门面忽悠的话其实尽可说的委婉一些(送给内心固执的我们)，但其实有时就算你忽悠了领导忽悠了销售，但是还是要产品给力，所以我觉得不要为了忽悠而忽悠，产品都是有情怀的人，为合理的固执不妥协。
沟通的重要性不再多说，你懂的。
产品想要在一片市场中脱颖而出，甩掉竞争对手，变革是势在必行的，不管是技术上，需求上，交互体验上，都要超出竞争对手，才能保证产品有一席之地。
个人认为变革虽然伴随风险，但是不断试错后的surprise会更让你兴奋。
做产品到现在，个人认为作为产品的我们要多出去转转，热爱生活，热爱自然，拥抱新鲜，拥抱变革，敢于思考，敢于实践，脑洞大开，不局限思维，当然还有多读书….确为目标群体解决需求的产品是好产品。
致各位有想法的前行在产品路上的我们，不妥协直到变老！！
版权声明：早读课文章均来自作者投稿或者授权文章，部分文章为转载均尽量注明作者和来源，文章版权归作者所有，若涉及版权问题，请添加momo微信：qqj5211314，感谢。
