创业公司如果CEO是第一任产品,那还要产品经理干嘛?

我近来作为唯一的产品经理供职于一家创业公司,工作期间感受到了前所未有的张力(Tensions),这种张力使得产品相关的工作非常难以开展,而且进度极其缓慢。究其原因,我发现,在创业公司,尤其当CEO对产品有非常强的干预时,CEO与产品经理两者的职责划分是需要进一步明确的,不然….与CEO权责扯不清可不是什么小事情。那么,如果创业公司中CEO是第一任产品,那还要产品经理来干嘛呢?今天就让我通过这片短文来简单总结一下,希望其他奋斗在创业公司的苦逼产品可以从中获得一些经验。文章不长,我尽量精简了信息量的表述。 这里涉及到了一个核心的问题: 在创业公司中,哪些工作是一定要CEO来做的,哪些工作又是一定要由产品经理来做的? 而这个问题又涉及到另外一个问题: 创业阶段,CEO和产品经理都要做哪些事情。 让我们先来回答这个问题,再从中这些待办事宜中找出哪些是CEO应做的,哪些是产品应做的。 创业阶段第一步要做的事情也是重中之重的,自然是客户/市场探索了。在《四部创业法》当中,明确描述了客户探索法和产品探索法的区别和优劣。首先,我们需要确定的是,我们在做的是客户探索流程,而不是产品开发流程。 这是产品开发方法: 这是客户探索方法: 在客户探索方法中,这4个节点分别实现这些目标: 客户探索[完成需求验证]:根据既定的产品设计已经找到了目标客户,且判断产品可以解决他们的问题。 客户检验[完成业务模型]:已经找出了可以反复使用的销售模型(或者叫业务模型) 客户培养[完成渠道搭建]:已经激发了更多的潜在客户,并把新的购买需求引入销售渠道(或营销渠道) 组建公司[探索型到完整编制]:从学习探索型客户发展团队向完整编制的公司过渡。 你的组织是否也在用产品开发方法去完成客户探索和市场验证呢?或者你的组织是否根本就没有执行客户探索呢? 如果你认为,你的组织已经完成了客户探索?你应该直接向下翻到客户探索的checklist的部分来进行检验。事实上,很多公司貌似已经完成了组建公司的工作,但实际上却并没有完成客户探索的步骤就开始迭代产品了。那我劝你尽快开展客户探索流程,不然就只能祝你在迷茫的路上走好。(走的越远,越迷茫) 另外可能大家也发现了,在客户探索方法中,团队首先要完成客户探索,客户检验和客户培养后才会组建公司。没错,也就是说,比较保守的情况下,在组建公司之前都不需要职业产品经理的介入。客户探索流程提倡的就是:稳健,避免盲目扩张。 不过,如果CEO一个人搞不定前面3个流程,自然需要一个团队来帮助他。那么就让我们来讨论一下,帮助CEO完成客户探索的情况下,CEO和产品经理分别应该承担哪些工作。(记住,主导客户探索步骤的一定是CEO而不是产品经理。如果CEO都没有意识到目前大家是在做客户探索,这将会是一个非常大的问题。) 客户探索 那么,什么是客户探索呢?让我们先来定义一下。 客户探索流程力图解决如下4个关键问题: 是不是发现了一个客户亟待解决的问题? 产品能不能解决客户的问题? 商业模型是否切实可行,确保盈利? 准备好开始销售产品了吗?(营销产品) 客户探索流程中不应该做的事情: 尽可能多的理解客户的需求 尽可能多的列出客户想要的产品功能 尽可能多的收集客户需求信息,提供给产品开发团队 撰写相惜的市场需求文档,提供给产品开发团队 召开用户研讨会 为什么?这些可能是大多数产品经理每天在做的事情,原因如下: 创业公司第一款产品往往不是针对主流市场的 真正的客户是未知的 假设未必是正确的,过多投入的风险很高 所以,如果已经在做上面的5件事情,你正在做的工作可能并不是客户探索流程,也就是说,可能你正在做无用功。 那么,客户探索到底如何来做呢?手把手的步骤如下: 写一份任务宣言,并且贴在墙上 撰写备忘录,提出假设 寻找潜在客户,倾听它们的意见 请客户检验修改后的产品功能和产品定位 阶段性小结 这其中,步骤1,2明显只能由CEO来完成。至于3-5可以由产品经理来协助完成。但整个流程中依然应该由CEO进行主导。也就是说,首先CEO要提出,或至少认可并授权这套流程的开展,由产品经理协助完成流程中对应的执行类事物,同时参与到改进产品的讨论和工作中去。 当完成以上的步骤后,CEO和团队应该使用下面的检查单来检查客户探索是否已经被很好的完成了。 只有同时完成以下所有问题,才算是完成了客户探索,可以进入客户检验的环节: The checklist 抓住了客户亟待解决的问题 确定解决客户问题的产品方案 找到了可行的,可盈利的商业模式 明白客户使用产品前后有哪些变化 能清晰的画出公司,客户,用户,销售渠道(营销渠道)的关系图 没有抓住用户需求?请返回到上面第一步修改假设。 认为产品的定位还有问题?请返回第三部,修改产品/原型后再次向客户演示产品。 当然,作为资方背景强大的土豪公司,可以暂缓考虑商业模式的盈利问题,不过这会是一个非常大的定时炸弹。 […]

产品经理是否应该画线框图

近来在公司内,被boss强制要求必须要画线框图,而且对线框图提出了诸多要求,包括:不允许添加图片和颜色,必须使用mockplus的形式,不能使用xd (Experience Design)的形式来制作,等。作为产品经理,在试用了多款工具后,更倾向于选择使用xd完成交互设计稿,而同时boss非常坚持,认为产品经理怎么能不画线框图呢?不画线框图你还是产品经理吗?“你这能叫线框图?”并当场百度,结果如下。 度娘给出的线框图: 我画出的交互稿(实际上是省略了线框图): 确实感觉完全不是一个东东。而且知乎上搜索了一下,貌似很多同学对线框图的概念也不是特别清晰。所以,还是决定写篇文章来深入探讨一下到底什么是所谓的线框图。 WHAT? 首先让我们先来搞清楚线框图的概念,其实我们口中说的线框图的概念有点大。下面圈里面的东西都被我们称为线框图。而百度给出的应该是狭义上的线框图,即Wireframes。而线框也分为有链接跳转和交互的线框和流程线框。本文讨论的线框图是指包涵说明和流程跳转的线框图。 当然实际的情况中,可能还存在介于这些概念之间的其它形式。总而言之,无论什么形式,从项目和产品的概念阶段开始,产出的产品文档一定是越来越清晰,图片越来越多,交互越来越完整,功能点越来越详细,视觉呈现越来越逼真,修改起来也越来越麻烦的一个阶段,这个文档的形成过程被称作The Design Funnel。 WHY? 那么,明确了线框的概念,再来看下到底为什么要画线框。(ps: 需要说明的是线框一般都是交互设计师完成的。但创业公司的苦逼产品,交互设计自然都是要一个人负责到底啦)线框图的目的被整理为下面的几个: Wireframes display site architecture visually (直观的展现站点结构 / APP结构) Wireframes allow for clarification of website features  (定义站点功能) Wireframes push usability to the forefront (将产品的可用性问题暴露出来) Wireframes identify ease of updates (便于更新和修改) Wireframes help make the design process iterative (使得设计过程相对独立) Wireframes save time on […]