编辑导语：由于学校里并没有专门的对口产品经理的专业，再加之许多人都是后来转行做了产品经理，所以不少人都是“野生”产品经理。那么，作为一名“野生”产品经理，应该如何寻找职业发展的方向和自我提升的途径呢？接下来，本文作者就为我们讲述了他的相关经历。
好奇职位名称而入行，零认知的进入外包公司，到离开后对未来的期待。与公司的性质有关，因此招聘要求不高，入职非常的顺利。其他PM都是半路出家，没有成熟的工作方法，都在同一起跑线上的。
外包性质互联网公司，主要承接分销类型的商城项目，以支撑自营电商项目的开发运营成本。
通过在自营项目上摸索直播、社交、聊天等，来培养团队成员相关技术知识的积累，从而使公司的业务可以得到相应的拓展。
1.5年的工作时间，基本时间是负责项目的管理。
清楚团队各成员的技术能力，在根据版本中的技术实现逻辑，可以很好的预估开发周期。负责管理各成员的工作进度，保证项目按时上线交付。
一个月时间从负责商城的一个小模块到一整个B2C商城的，遇到很多问题，逻辑不通技术怼，交互不合理UI怼，业务有问题客户反馈……
秉承遇到问题就解决问题的原则，将问题划分等级按照优先级，依次从业务——系统——交互解决。
通过PMCAFF，人人经理恶补知识，下载《电商产品经理》电子书全面了解整个电商系统，《用户体验要素》电子书了解基础的设计原理，很快那些工程师就很少BB了。
之后负责的B2C商城项目多了，工作就越来越简单，相继也出现了新的问题。
因为要负责与客户对接需求，而客户提的需求又非常多，考虑到技术投入的成本问题，产品对接时要删减不必要的需求，最重要的还是要说服客户接受。
起初是与领导一起对接，全程听他们之间扯皮条，我只负责记录定制化需求。而之后的项目由我负责对接，我还是负责记录客户定制化需求，在与领导沟通需求内容，领导很耐心的指导项目承接的需求范围。
由于本人不善于也不喜欢扯皮，刚好想起需求管理这门学问的作用，网络上搜罗很多需求分析需求管理的干货，认真阅读的同时联想是否符合现有工作流。
对于外包企业只要项目款到位，任何需求都可以实现的。
最终根据我们的客户群的一些属性和结合那些干货知识，我便按照以下的方式去对需求进行分析和管理：
- 使用价值：了解业务领域、了解产品、了解用户群，分析需求解决目标用户在什么场景下的什么问题和该问题现有解决方案以及出现的频率，从而判断该需求的使用情况；
- 技术可行性：因为对市场上的竞品有一定了解和技术知识基础，在拿到需求时只要是清楚的就要预估出时间（不清楚的则需要和技术讨论，因此又可以积累更多技术知识）；
- 投入产出比：预估需求的开发投入成本（人力+时间 < 项目款）。
版本规划：优先实现项目的购物流程 （会员/商品/购物车/订单/物流/库存/内容）——优化迭代——在实现促销 （拼团/优惠券）——优化迭代——定制化 （分销规则等）——优化迭代—— 售后 （退货退款）。
根据以往的经验进行规划，滞后一切打乱节奏的需求，开发节奏被打乱后，会影响项目之间的成员调配，最终所有项目都会受到影响。
以上就是我在外包中使用的方法，在最初进入公司时基本不怎么分析，只是分析下流程逻辑就出方案原型。
这样的工作方式导致项目开发很累，为了能轻松有节奏的开发才开始了分析，顺带把一些客户提的需求忽悠到之后版本，然后额外多收一个版本的项目费。
一、温故而知新，可以为师矣
为了能进入拥有成熟产品团队的企业，筛选各种公司投递简历，能力和经验不足公司是真难找。好不容易找到一个来自微信团队的公司，最终却发现没有自己想像的那么好。
作为A的ISV服务商，负责某个行业领域的初创公司，初期成员都是T挖来，以至于我觉得他们很强，接触时间长了发现并没有我想象中的那么强。
在选择离开时他们又挖来了一个专家，虽然很期待这个专家的实力。
入职后总监头衔的前微信产品一起负责会员权益方案，合作中对于其个人能力无任何质疑，但管理能力有待提升。
研究现有的会员权益相关资料，在后续权益方案会议的交流，为了确保上线的权益转化率，开始着手调研市场，验证我们所提供的权益内容，能够真正转化用户到平台。
广州本地市场调研工作，根据调研调研目的整理调研的问题内容，装作用户到各个网点与工作人员沟通。其他省份各市的调研则安排线上，开始的线上调研还挺顺利，当调研的省份城市多了之后，调研的结果就非常的混乱。
思考一下午出了一个新方案，与领导沟通后次日执行调研，最终调研结果：现阶段我们提供的权益与其他渠道的权益差异并不大，用户更换渠道的各项成本之和大于我们提供的会员权益的回报。
会员权益任务的搁置，莫名其妙的被安排接手同事的售后服务，根据同事交接的资料慢慢熟悉售后业务，与来自微信的运营经理沟通售后所有的场景和流程，核对同事交接的资料确保资料的准确性。
之后收到来自总监发送的一份接口文档，是当前服务方系统提供的最新接口能力说明，让我根据接口文档尽快熟悉整个系统，又一个莫名其妙的任务。
由于业务属于项目的核心部分，涉及与各个系统的数据交互，通过接口文档大致把整个系统都了解了一遍。
在与业务方沟通确认大致的产品方案后，开始分析与各系统之间的数据流是怎么走，传输哪些字段，两个系统间的唯一标识等等。
期间因为是一个人负责前后端，不仅要考虑与其他系统交互还要考虑与前端的交互，所以我给他们的方案都是我这边能怎么简单就怎么简单，吵过反驳过怼过最终我还是默默地忍受着，按照最佳的方案处理。
整个系统划分4个线上系统和1个线下系统，根据接口文档和各系统的业务场景，分析总结出以下的关系图。实现关系需要我去定义传输的数据字段内容，并且与其他系统沟通传输数据字段规则：
因为售后的业务重，更多是考虑业务流程，该怎么提升效率和体验，其次还要和商务/业务方沟通流程是否合理合规，复杂的一些还需要法务的加入。
一系列的工作流程走完后，确认当前的业务流程后，开始着手规划售后系统各个阶段的版本内容。
版本的规划按照业务频率、开发时间和业务价值考虑（业务出现频率的，技术开发时间，业务上提升产品价值，业务上减少企业损失的维度）：
- 这个阶段的工作让我学会了看接口文档；
- 来自同事的分享，需求方提供的需求需要有明确其目的，否则需求不予接受；
- 来自工作中的发现，结合读过和看过的资料，产品需要有明确数据指标，才能够健康的发育成长。
二、自强不息
能力水平太低找不到好工作，又入职了一家小型创业企业，而且还是陌生的业务领域，作为该企业唯一的一个PM亚历山大。
对自己非常没信心是件不好的事情，在收到通知时严重的自我怀疑，但进来后发现需要做的并不复杂，与以往的工作相比更为简单划水。
初来乍到通过与管理层的沟通，了解清楚项目的战略规划。开始网上搜索相关文献竞品资料等，根据战略定位的竞品很少，所以找了一些相似模式的竞品。
通过分析竞品提供的功能，了解其解决用户哪些场景下的问题，整理出于我们有用的问题后，挖掘该问题当前线下和线上的解决方案。对比两者之间的差异优势，按照需求权重高低过滤和排优先级，需求高的使用拆解方法以五个维度去思考，需求低的则简单的思考。
根据竞品/战略目标/产品定位，可以划分出我们的用户群（XX设计师、XX爱好者、XX工作室…)，身边从事该行业的朋友，同时在网上找到一份详细的介绍资料，之后的与朋友沟通和核实资料可信度。
对产品的定位和规划有了新的收获，后面陆续找了一些（墨刀、蓝湖、电商中的某些流程与规划的产品类似）产品进行分析。一系列工作后与管理层沟通产品规划的初稿，在多次的沟通中逐步完善产品的规划，确认产品方案后现在持续的补充细节中。
本文由 @Mading 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议