上文谈完产品职级的分配，本文详细谈谈产品底层的助理工作以及晋升方式。
产品助理，顾名思义辅助完成产品工作的人员。一般助理的工作中会做以下几个事情：
1.产品数据汇总，资料整理收集，需求文档的撰写（也就是杂活）
2.小功能点的设计
3.项目进度的跟进以及简易问题的解答
那怎样做好一个助理的工作呢？给出以下几个建议：
熟悉业务
产品所有的事都是基于业务产生的，建议助理入职第一件事就是了解你做的产品行业是怎么样的，你们产品功能逻辑是什么样的，查看积累是产生解决方案的基础。
杂活摸门道
产品本来就是一个信息汇聚然后再根据信息和经验产出合理的解决方案，所以杂活也是一个产品体系中的一个个环节，从中摸出门道才是最重要的。
杂活一，需求整理。
一般需求都是从各个地方汇总而来，杂乱无章需要梳理评定后才能进行解决方案的制定。你或许说我的经理不要我整理，那就看经理整理的。
看需求的过程请带着脑子，思考以下几个问题：
1.用户提出的需求需要解决什么样的问题
2.解决了这些问题用户能达到什么样的收益，我们能达到什么样的收益
3.那我们应该怎么解决，我们竞争对手的用户有这个需求么，他们怎么解决的，为什么会这样解决
4.解决这个问题我们要怎么设计，影响面怎么样，因为能力解决方案不会很优化，那就多想几个
5.所有需求归结在一起对我们和用户来说，哪些更为重要更为紧急
长此以往的坚持，你对待需求的理解就会更加深刻，解决问题的能力也会增强。
杂活二，资料的收集
资料分为多种，竞品的分析，行业的知识，使用的数据，问题的反馈。
这些信息内容不同，但能有一个共通点，就是需求的整理。比如：
竞品分析
在竞品分析中不仅仅是汇总出一个个单一的功能，而是功能背后产品为用户解决的问题。
比如京东在商品选购的时候会有一个单一的分类页面，通过分类层级到达具体的商品。他们有强大的搜索功能，可以在输入关键字是快速到达商品，为何还要做一个独立分类搜索。原因在于有用户来买一件商品知道商品用在哪，大概类型是什么，但不知道名字。那通过一个个层级到达商品就是解决这个需求。在分析过程中多思考每一个功能解决需求的场景对能力的提升会有很大的帮助。
资料整理
在行业知识汇总时，也是同样的道理，从业务流程思考解决方案。
举个例子，拿宾馆预定行业来说。大流程为
以此我们可以归纳从流程中大概归纳出以下需求
1、宾馆需要管理房间情况并展示给用户
2、宾馆需获取和记录用户订购、入住和退房情况
3、用户需要找到房间，订购房间，退房
那再思考怎么解决这些问题，我们大致会有如下设计
1、做一个商家后台，一个用户服务端
2、商家后台需要能管理房间状态，并且在用户端查看对应房间信息
3、用户端查看信息后可以预定房间，使用完成后可以退房，并且商家后台房间状态变更。
4、其他用户也能查看都对应的房间状态。
基本的思路就是这样，根据业务情况梳理出需求，给出解决方案。在实际工作中会更加详细的完善流程，而解决方案也更为细致。那就自己体会了。
文档撰写
有时候经理将方案做好，助理需要辅助完成需求文档。而文档的撰写不要仅仅着眼交互和字段，因从需求与功能层面思考问题。与竞品文档类似，思考每个功能解决了什么需求。
与竞品分析有差别的事情是，每一个需求文档都只是一个功能版本。这其实应从中学到产品对需求的拆分和功能规划，学习的前提有两点：1、业务的熟悉；2、所有需求的熟知。在看需求文档可以多拿几个版本进行对比，去思考经理在每期迭代中解决的问题是什么，关联性在哪里，为什么会有这种功能排期。
还是拿宾馆订购来讲，我们已经定大的功能项4点，我手上的人手和资金，以及公司的战略不足以让我做一个大而全的东西（并且大而全的东西如非本来就是十分成熟的一般难以把握方向，会产生偏离实际需求的情况）。
我们要做一个宾馆订购系统，提高宾馆入住率，以及用户选购的便捷性。
第一期，我会针对核心需求进行设计，确保所有业务能跑通。因为只有用起来了产品才是有价值的。
（这个是一个小时内写的规划，也没有深入的调研过，只是用于举例）
短时间使用过程中用户会有很多反馈，如
1、宾馆发现我自己有房间管理系统，我手动管理状态太不方便，能否对接宾馆的管理系统
2、用户说，我订了房间去了商家没把房间预留下来。商家说，他没有给钱，也没有说明好久来，我有客人肯定会给其他用户了。
3、用户说，商家会随意退订房间。商家说用户也随意退订房间，这样让双方的使用很不便捷。
4、我们发现因为手动更新房间信息，房间状态经常与实际状态不符，经常去了没有房。
根据用户提出的问题我们整理下需求及解决方案：
1.对于订购需要提高双方的协议性，我们准备做在线支付，并设计违约惩罚机制，包括赔偿，信誉等级等。
2.用户获得的信息更准确，商家维护信息准确后用户获取信息就准确，在信息不准确时增加一个电话验证环节，增加信息有效性
3.商家对信息的维护更便捷，接入宾馆自己的管理系统，并为没有管理系统的提供对应系统。
针对系统核心，促成用户订购，一切降低订购的事都应该快速解决。再衡量项目研发难度和需求紧急程度排布需求。
优先级一
需求二为系统机制问题影响订购，导致成单效率问题，更会因此问题导致用户流失。因首要解决，因为同步信息成本和时间过长先选择增加一个验证环节。
有效级二
需求一相对需求二的影响较小，且解决方案更为复杂，所以优先级降低。而需求一的核心是商家保证能有限的入住收费，因此会先做在线支付。奖罚机制是一个较为庞大体系，想要有效需要在健全的业务下做出合理的规则，项目初期先向后排期。
优先级三
需求三，状态管理再难用再繁琐，也仅仅一个人花几分钟的事，那业务内部管理就好。而且对于多系统对接，更应该是自己做强大下提供标准接口，让其他系统对接。
并且根据产品战略，我们可能会将一些需求插入，比如优惠模式，会员机制。以便达到产品核心目标。
你看产品规划的大体思路如此，正好需求文档做了很好的体现，多看多思考肯定会有提升。
小功能见真招
在能力提升后，一般给予一些小功能点让助理处理。虽然需求明确，功能简单，但还是请认真对待。
在需求调研阶段，要更深刻的挖掘需求的本质。听用户说是最基本的，但不能简单的按用户说的做。结合业务场景用户需求的原因，再考虑解决方案。
如宾馆一期完了，如用户反馈需要房间信息更准确，宾馆也希望接入管理系统便于管理，对双方都有利。
宾馆解决方案确实对用户和宾馆最优化的，但是不同宾馆有不同的系统，还有些没有。那我们需要兼容对接的系统过多，成本过高，周期过长。而提供标准化接口，在项目初期使用量不可能上去。那根本无法解决该问题。
那我们再从需求入手，用户和宾馆就是想确认信息，那增加一个确认环节吧。增加环节怎么保证使用，前文说了我们还有在线支付，钱在我们手上，从结算入手就有办法控制了。
因为经验问题，在思考过程中也可参考竞品处理方式。但切记不要去搬用竞品方案。就算用也考虑清楚为什么这么做，真的没有更好的方案了吗？
后面就是原型设计和需求文档，体现一个细字就可以了。考虑问题全面，细致，做出的方案实现才准确。
项目进度和问题解答
进去研发阶段后，技术会给予我们项目研发排期，非技术出身的产品一般都会在项目经历合作下完成。这就较为常规，需要注意的事就是，尽量避免跟催每个人的进度。每天抽一个时间大家更新进度，协调研发间配合问题。
问题解答，应该正面面对，每个人思维都会有漏洞。再好的方案也可能存在多多少少的问题，他们研发还有那么多bug呢，当然出现问题时不是去怼别人。而是放平心态，沟通出现的原因，思考解决方案，毕竟大家都是为了把项目做好嘛。
助理们首先要踏实的做好手上的任务，毕竟公司请你来是帮忙的，不是仅仅为了让你学习的。在工作的同时能更多的思考，将问题想的越深刻全面，也就能更快的提升。当然不要天马行空了，讲求事实逻辑，好坏区分。做好手上的事，提升自己的能力，成为经理还是很简单的。对吧？
到此。
