在职场进阶中，在不同时期需要定期进行回顾复盘，在复盘过程中总能发现一些问题。在复盘过程中，作者提到：产品经理要避坑“衰退期产品”的职位，为什么这么说？一起来看看本文分析吧。
本文是关于我在职场进阶中的一段经历，在不同的时期回顾复盘，有助于自我觉察，找到不足。
这家公司的产品运转模式：以产品规划为主，产品经理主导输出季度、年度产品规划目标。
好处是在做产品规划时，会考虑顺应市场的趋势，所以在协作上需要向市场人员收集反馈，获取更多的有效信息，以便做出符合市场趋势的产品。
当时我在公司算是空降的产品经理，所负责产品线团队之前是由研发经理兼任管理。研发经理会负责产品需求输出及迭代上线。
当时第一个感慨是这个团队的自组织能力极强，对于客户反馈的问题响应很迅速，第一时间想办法解决，对待问题的处理态度是刻不容缓。
但产品与研发分别为两个部门单独管理，而非一个整体进行协作，实际工作不好开展。这也引发了后续在该公司的一系列问题。
总结这期间的状况，我会有以下3点感悟。
由于团队成员原本是以研发经理为主导，大家的定势思维很难扭转成以产品经理为主导。
想要转变，就要从组织架构做出相应调整，自上而下贯彻落实。不过，在实际实行过程中，涉及到职能和权利的转移，阻力极大。
同时，该研发经理又是公司的“老人”，关系错综复杂，短期内比较难转变。需要管理层意识到问题，并提供相应的办法，可能会有显著效果。
正是因为没有很好地建立起来产研管理架构，导致一些工作很难推进。不过现在想来，当时自己作为产品经理，专注力在产品打磨上面，对于组织层面的事情知之甚少，也是可提高之处。
作为产品经理，秉着职业的原则，对产品负责，对客户负责。我认为只要帮助客户解决了他们实际运作过程中的问题，产出就是有价值的。
公司的需求产生到方案定稿的过程：接收到需求，先与业务人员沟通确认需求背景。如是涉及多个业务方的共性需求，将逐一调研多个业务方来收集VOC，必要时会请求与客户电话沟通，或去到客户现场了解实际情况。
收集到客户VOC后，将VOC转换为产品的问题，再转换为技术的问题。分析问题点，设计产品解决方案。为确保产品方案是满足客户需求的，一般会与业务线上对齐需求方案。双方达成共识后，就推进到与研发评审需求的环节。
我从中收获了如何挖掘需求，及如何找到一些未知的东西。这是产品经理能力的基本盘，大家要重视起来，找对问题比如何解问题更重要！
该项目在公司属于边缘型产品，我当时在公司的定位就很尴尬。当你所做的事情不在公司主营方向时，公司给到该项目的资源是有偏倚的，做得再多，对公司而言，产出的价值微乎其微。
我负责的产品和公司未来战略路径并不一致，公司希望通过中台的方式重新构建，我在团队中的角色在大家看来，只要维护好现有的客户，不出什么大的问题就可以了。
至于取得突破性的产品成效，在内部是被打压的。
在不断地内部探索中，我慢慢明白自己在其中的使命。其实是让一款在生命周期处于衰退期的产品，能够更好地完成过渡，无痛地结束它。
当时的自己对于产品经理在一个组织上的角色和定位，没有特别清晰，没有把产品经理在项目流转过程中的重要地位凸显出来。
现在看来，是因为当时没有经历过更正规、更好的组织，所以也缺乏对于什么是好或者更好的认知。
在这个时期，就是要让自己真正地进入到标准流程化的组织，才能培养对好的认知，成为更好的自己。
我从中收获了如何挖掘需求，及如何找到一些未知的东西。为我的产品职业道路增加了砝码。
同时吸取经验，产研职能分工不明确、项目定位不清晰，这些因素影响了我对整体工作的评估，项目的挑战性不大，做的再多成就感也不大，长此以往，将影响个人成长。
所以，想要在项目中获得持续的挑战与成就感，请先了解清楚项目在公司的定位，避免踩坑。一个项目在公司的定位太重要了！
实践出真知，这段经历，塑造了半个完整的我，从此也有了后续的自我完善，感恩！
本文由 @Nana 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。