Product_Management.png
最近一段时间在规划新项目。之前，大部分情况下，项目的方向甚至具体的内容都是由领导来掌控，我去补充细节，然后推动产品落地。例如在大房鸭的时候，老板定义产品方向及大部分功能范围，我去梳理流程，产出交互和文档，协同设计、开发推进产品上线，我自己主导推动的内容大部分是一些业务相对简单的模块。在学霸君，虽然做什么由我自己去定义，但由于需求是明确的，大部分时间只用确定优先级去执行就行。
而这次，根据业务的总体目标、市场拓展计划，我自己去定义该做的方向，拆分、明确这个方向上的目标，规划目标实现的路径，进而向领导申请相应的资源。
在产品规划过程中，我尝试不断地去梳理自己之前掌握的内容，也查资料拓展知识边界，于是有一些自己的总结和见解。
一、确定项目目标
《用户体验要素》里的战略层其实就能很好的说明如何确定目标：
- 产品目标：我们（公司）要通过这个产品得到什么？
- 用户需求：我们的用户要通过这个产品得到什么，他们为什么会依赖我们？
产品目标很好定义。通过参加公司的战略会议，我理解了公司新的战略方向，然后从战略目标中，拆解出产品能够提供的支持就可以。
2018年的业务目标和销售策略有很大的变化，导致目前的产品无法适应这些调整，我需要通过这个项目去推动产品进行优化，协助销售提高销售演示效率及效果，并对最终的效益目标做出贡献。
定义完产品目标，我们需要去定义用户需求。
演示产品的用户是销售和渠道商，所以我们要解决的问题的方向也比较明确，就是销售和渠道商出去演示的时候，会遇到很多产品或者非产品的他们无法解决的问题，需要产品经理通过产品手段为他们提供支持。
于是问题的关键在于如何去拆分目标，即我们需要做哪些事情来达成这个目标。因为对于项目比较熟悉，之前跟销售也有一些的沟通，所以我有大概的想法，未来要做什么。但大部分想法都是我的假设，接下来我要做的事情是去调研，去验证我的想法和假设。
于是我对销售进行了用户访谈，了解他们的销售场景、流程以及遇到的问题，并且到销售前线去了解销售售卖的具体场景。
经过调研，我弄清楚了用户需求，即这个方向下涉及到的角色，各个角色的使用场景，他们当前的动作流程，以及这些动作流程中的需求和疼点，这些其实也就是用户故事。
在这一阶段，我弄清楚了现状是什么，也对于未来产品的发展方向有了较为清晰的认知，也拆分出了我需要满足的需求/提供的服务。
二、梳理实现路径
经过上一步的梳理，我拿到了一堆需要做的事情，那么我们如何来安排这些事情，让产品通过不断的迭代去持续交付成果？这其实就是如何去定义产品RoadMap的问题。
我们在梳理RoadMap最常犯的错误是去梳理每个时间点或版本需要完成的功能点。例如，在3月份我们要完成以下几个功能，在4月份我们要完成另外几个功能。
这样梳理会有2个问题：
第一个，我通过什么依据去安排每个版本的功能点？
第二个，版本迭代过程中，如何形成节奏感？
所以，与其梳理每个版本的功能点，不如梳理每个版本的版本目标。这样我就能清楚的说明，我这个版本要实现什么目标，最终会带来什么变化，为了实现这个目标，我要实现哪些功能。
基于这个，我就梳理清楚了目标的实现路径。在制定版本计划时，能够清晰地定义出每个版本想要实现的目标，确保所有的需求都是为了这个目标的实现做出贡献。
三、资源争取和利用
作为产品经理，我们的直接产出是没有价值的，我们必须争取资源，让他们来利用我们的产出，进而实现最终的目标。我需要争取设计、开发资源，这样才有人力配合我完成我的项目；我需要争取销售的信任，进而在后续的工作，对我们产生依赖，从而不断地反馈新的需求。
于是，我召集了各部门的老大，去讲解我对于销售目前遇到的问题的理解，当前的产品是什么样子，未来的产品会是什么样子，它解决了销售的哪些疼点，以及明确的迭代节奏。这次汇报内容得到的销售leader的认同，认为我的产品规划能够极大的解决销售目前遇到的问题，技术leader因为之前体验过销售环节，所以也能感知到我在解决正确的问题，也能感知到产品未来会对业务的帮助，所以也愿意从现有项目中调配一部分开发资源。
这就是我争取资源的方式，让团队里的每个人都认同这个项目所带来的价值，也知道自己的投入会有产出，所以也愿意给予资源支持。
目标、路径、资源，这个项目规划的梳理逻辑，是我从我领导那里学到的，在网上搜索之后，发现这是傅盛提到的“管理三段论”。
采铜的《精进》这本书中，有一个章节的标题是“技能，才是学习的终点”。
在运用的过程中，我也发现，在看文章，听别人讲中得到的知识只是信息，我们得反复去使用，获得反馈后修改，才能将知识变为我们的技能。
网友评论