产品经理高效的工作状态是什么样子？

原创： Kevin改变世界的点滴 Kevin改变世界的点滴

昨天

产品经理在工作中出现最多的3个关键词汇总下是原型、文档、会议。今天想就这3个关键词分享什么样的状态是一个高效的状态。

原型的高效

试想app还是一个web产品，从0到1做一个完整的产品。你需要多少的时间绘制原型？

当然很多产品人第一反应可能会提问：“怎么没有需求调研、竞品分析？”

是的，绘制一个原型并不难。但是绘制一个符合业务解决了用户痛点、满足公司业务需求的原型是困难的。因此产品经理需要大量的时间花在需求调研、竞品分析，我见过有的产品经理在从0到1规划原型前会先找100个app，

现实互联网开发中，有的产品经理拿着一线top100的app或直接找到top3的竞争对手，砍掉某些功能，或填补某些功能、加上交互的借鉴。一个自己的从0到1的产品就这样诞生了！原型也会非常高效的完成，可能1天就可以完成

但这样的产品设计方式是对还是错？你如何看

我认为答案本身是没有错的，因为我们都想用最符合用户习惯的方式解决用户的需求，满足产品业务的发展。

比如希望与用户建立客服服务，一套im体系+客服系统或许是一个很完善的解决方案

相同的业务需要类似的模块，快速的借鉴对方产品其实是一种比较好的方式。临摹的只是产品解决方案，通过业务、UI、实现的技术区别，最终产品还是会有特别性。

文档的高效

产品经理大部分工作除了原型，还有文档。文档的撰写我们以需求文档为例，每个产品经理有各式各样的结构与模版。

但归根到底要高效，我们要做的就说清楚页面之间的逻辑与功能的说明、字段的说明、算法的说明即可

我个人的经验是文档撰写分3层

交互层

指的是说明页面的交互效果与下一步页面的跳转

规则层

当前的模块或字段规则说明，有什么样的逻辑

条件层

在什么情况或条件下才会触发某个功能、跳转

将上面3个纬度撰写在一起，并且聚焦在某个点或字段上，方便开发、设计同学阅读。

通常在敏捷开发中，不需要太多的需求背景介绍、项目成员介绍等，直接了当的以页面、功能切入，加上用户流程与用例图，一个PRD文档的时间会缩短1/3。

高效的沟通

沟通是产品经理的第三大时间占比，无数的需求评审会、小沟通会议，甚至有需求方过来咨询是否能实现等。都是需要产品经理花时间沟通介入

但在沟通中，有3个点是产品新人应该注意的，可以提升沟通效率

• 确定会议结果

  
  

• 确定参与人

  
  

• 确定我们要做什么

需求评审会可以解决上面第二个、第三个的问题。但我发现许多产品人在会议结果第三点上做的并不太好。会议中不能确定的结果，一次沟通下来可能还会存在更加懵逼的情况。产品经理应该有意识的主导本场结果。

因为结果不明确会导致项目的沟通成本增加，甚至是延长了项目时间。

另外因为部分互联网团队存在项目经理的职位，所以需要确定本次需求的参与人与负责人是谁？我一个产品经理到底找谁来跟需求，评估能不能技术实现？开发要多久？

所以产品经理一定要把每次沟通中存在几个节点

• 我们什么时候反馈

  
  

• 接下来各自做什么

  
  

• 我们什么时候再碰

每次沟通都要存在这3个元素。时间点、节点、任务名称，保证每次沟通或会议不是蒙蔽的，这样就会成为高校的沟通。

好啦，今天的原创就在这里，我会每周更新2篇在这里。

推荐阅读：

坚持一年，招募100个产品经理

我的第一本书，给你们

我的原创课程，产品经理8次训练