产品与运营该绕过哪些坑?
别人的成功经验抄不来,但是别人遇到的坑我们可以躲。能够躲过越多的坑离目标就越近。本人虽然进入互联网行业只有1年多,也没什么好的经验,但是过往6年的管理及业务咨询经验让我在这短短的一年中看到了很多的坑。这篇文章便是我在这1年多的工作中所见所思的总结。
能写出这篇总结首先要感谢我的老板和这家企业,毕竟敢要我这个零互联网基础的人,本身就是一个很有魄力的决策。我来到这家公司的时候职位是产品运营,但实际上并没有固定的职责,有啥能做就做啥。在这段时间内做了竞品分析、用户调研、业务分析、主持B\C\微站的需求讨论会、做OSS的产品经理、做经营分析,抽空辅导下运营部门的新人,还参与了一个应用开发的兴趣小组。这段时间的工作让我从以往做咨询时的策略研究下沉到具体 业务中,看到了更多的实际问题。在这个过程中自己也躺过一些坑,同时也正是这些坑让我不断成长。
我所在的是一家APP兼职平台,算是O2O领域,线下很重,是需要同时搞定B\C两端的一个行业。来时这里刚刚融了1000万美金。这些钱在互联网领域说不上多,但已经能干不少事了。不过公司选择了默默无闻的在线下耕耘,APP到现在还处在冷启动阶段。现在看来,导致这个结局的一大原因就是互联网领域常说的:快速试错。没错,这个互联网人常挂在嘴边的一句话其实就是一个天坑。下面就从产品、运营、公司三个层面谈谈我躺过,见过的坑。当然一些观点可能有所偏颇,还请大家指正。
1、产品层面的小坑
产品层面总结的问题可能不是很深刻,都是一个个的小坑。除了下面提到的坑之外。个人还发现一个坑就是性格的问题:一些产品人员过于感性化、缺乏对商业的认知,就容易在很多地方出问题。所以个人感觉产品经理还是很有必要学一些逻辑、商业、营销、统计、管理等方面的相关知识,毕竟相对于如何吧功能做的好用,明晰什么是重要的功能才是产品人员最先要考虑的事。做咨询时常说的一句话就是:做正确的事比把事做正确更重要。
1.1先说一下自己躺过的几个坑
1.1.1 没有把握好轻重缓急
产品经理,本质上是一个项目经理,一款产品初期待优化的地方会有很多,关键在于理清产品优化点的轻重缓急。
初期来到公司根据直观的感受,一直撺掇着推动UI的美化。但是后来才明白,在当时功能更迭频繁的背景下,如果来个大改版进行UI的美化一则会减慢功能更新的进度;二则在功能反复更新的情况下,如果整体UI框架无法一步到位的话后面再调开发团队就要疯了;第三,其实APP的UI美化对公司的发展来说这并不急,因为反正当时几个月内也不会有多少用户。而且作为一款工具类产品,核心在于是否能帮助用户得到他想要的,UI什么的其实只是锦上添花的。
这个问题让我认识到碍眼的地方不一定要立刻改,而要综合考虑各方面的问题,包括:该开发任务对用户的实际价值,当前产品优化的重点任务、采取这一举措在后期开发过程中可能产生的影响,该开发任务的急迫度等等,在一个合适的时间将其解决。
1.1.2 听信用户所说,没有深挖言语背后的真实诉求
很多时候用户都不知道自己想要什么,我们需要根据用户的反馈挖掘真正的诉求。特别是在用户的反馈涉及某些重要流程时尤其要谨慎,不然很可能适得其反。
我们做的是兼职APP,由于访谈过的兼职人员很多都反映下载APP太麻烦,各城市负责职位匹配的人也说让用户下载APP报名很费力。于是我们就推出了微站版,以方便用户报名职位,等到结算时再下载APP即可。但是后来发现,会自己在APP上报名的用户,大都是从APP注册进来的,从微站注册进来的用户则很少会有自主报名的。也就是说这一举措导致了活跃用户的减少。
这次得到的教训有两点:一方面,微站对于很多用户来说只是其在微信中的一个过客,而APP则会在其手机中安家。置于不愿下载APP,更多的原因在于我们APP提供的价值还不够,岗位还比较少。着眼点应该在提升APP本身的价值。另一方面,虽然用微站报名的用户我们最终也会引导下载APP领取工资,但是这个流程无形中给了用户一个心理暗示,APP就是用来领工资的。进一步弱化了APP的价值认知。所以在流程设计时需要考虑流程对用户认知造成的影响。
总结一下就是用户不爽的原因往往不在于他们所说的,产品人员需要进一步去挖掘。而挖掘的核心个人认为就是“价值认知”。之所以不爽是因为这步操作没有让他感觉到有价值。这里借用福特的依据名言:如果你问客户需要什么,他们只会告诉你他们需要一匹更快的马。
1.1.3 想着一步把功能做完整
刚开始上一个功能总是追求功能模块的完整性,但一个功能最初上线能够满足基础的需求就可以了,非必要的都可以砍,后面再慢慢完善。
在初次做OSS的设计时,企图一下子做一个完备且专业化的用户筛选功能,提供各种可以进行的筛选维度,外加“与、或、非”三种逻辑间的组合关系。然后初次需求讨论会的时候就被否了。因为我们的运营人员并没有接受过逻辑方面的训练,“与、或、非”的关系根本理解不了,而且多维度的复杂筛选会占用大量系统资源。所以只保留一些易于理解的筛选维度。简化版本推出后发现,我们的运营人员对各种维度的组合应用完全抓瞎,无法做到举一反三,只能是我告诉他们哪几个维度组合在一起可以筛选出什么样的用户,各种分析情境下需要通过哪些维度的组合调出哪些数据。最终实际应用较多的只有开发内容的一半,另一半基本不会使用。
这个功能的设计给我的教训有三个:第一是开发过程中,第一版应当尽量选择常用的功能,对于不常用的功能可以在迭代过程中根据需要逐渐加上,而非追求一次性把某个功能做的完善;第二是要考虑到使用人员的实际知识水平,有些需要专业素养的东西,一些门外汉短时间内是学不会的;第三是要考虑各种数据的积累量,一些数据积累的量很少,没有可用性,所以相应的筛选维度也就不会发生作用。
1.1.4 老想着让开发人员一版能多做点功能,快速完善APP
一个初创型的企业产品需求变动会相对较多。这时快就是慢,慢就是快。因为在急促开发的情况下,开发人员写出的代码在后期更改时就会十分的麻烦。但是如果初期开发过程中给予足够的时间,让开发人员将较多的模块写成可以灵活更改的(当然前提是开发团队有这个能力和觉悟这样做),后期改动时所花费的精力则要小很多。开发人员在后期对功能进行调整时也就不会有太多的抵抗情绪。这样前面慢点,后面就会快很多。而且说实话,真正必要的功能其实并不多,很多都是自己以完善为名加入的非核心功能。
1.2再说一下看到别人走过的坑
1.2.1 过度超前——阻碍重点模块的优化进度
我到公司以前,我们的APP就设置了待录用、待上岗、待结算、待评价4个模块。但时至今日除了待录用之外,其他几个模块对用户都没有什么实际效应。此外没有实际应用的模块还有很多。究其原因就是我们在按照心里预设的商业模型埋头进行产品的完善。忽视了实际运营中内外部用户的实际使用情况,使得产品过于超前。
产品开发超前带来的负面效应主要有三块:第一是阻碍了初期一些重点工作进度。比如到现在,重点流程页面的埋点工作依然没有做。使得产品优化缺乏足够的参考依据,比如产品技术架构的更新滞后,在很长时间内产品很多内容的更新都需要用户主动更新APP才能实现。第二是会占用更多的开发成本。一个功能上了之后想下来就很不容易了,从产品到开发大家心里都会比较难以接受。就以待上岗、待结算两个模块为例:为了能够保证模块中提供数据的有效性,我们根据用户报名的不同职位类型、做过哪些操作等一系列的逻辑进行区分。而根据我们所拟定的逻辑,即便再过几个月也不会有几个职位能够出现在待结算的环节中。第三就是导致资源浪费。毕竟对于创业企业研发还是挺贵的。前几天跟以前离开的产品总监聊了聊。由于那些不必要的功能,浪费的研发资金上百万还是有的,够做几次不错的营销活动了。
1.2.2 群策群力——群体智商通常低于个人智商
我们公司技术部开始时喜欢调动大家讨论,甚至大家投票表决一个产品或是运营的策略。这是一个很糟糕的方法。所谓头脑风暴,正常的运用是大家一同讨论后,收集各方的意见,再由专业人员进行整理与分析,最终平衡后得出一个相对恰当的解决方案再由领导拍板决策。
做决策不是打群架,300个臭皮匠也顶不了一个诸葛亮。每个人的知识背景、认知层次都会有很大的差别,不同层面上的对话本身会有一定的交流障碍,使得沟通变得低效。同时,你一言我一语的讨论,逻辑链条无法拉的很长。但是有些问题的决策可能需要几十个逻辑环节。所以,群体讨论是无法解决这种复杂性问题的。但是具体执行层面的细节问题往往都是广泛关联的复杂性问题。所以一定要明确群体讨论只是用来收集观点的,并不能进行决策。下面举一个例子,这是我用线索拼图的方式(由线索1、2得到结论3,由结论3和线索4、5得出结论6……)得到的关于某项产品设计点的最适方案。过程中涉及用户的取舍、发展方向、运营、开发等方面的30余项线索与结论。这绝对不是讨论能讨论出来的,只能通过沉下心仔细的思考得来。大家可以感受下
- 黑色字体代表线索项
- 红色字体代表结论项(括号中的数字代表产生该结论的线索编号)
- 前面的结论可作为后面的线索
移动应用产品推广服务:APP推广服务 青瓜传媒广告投放
本文作者@尹翀云 由(青瓜传媒)整理发布,转载请注明作者信息及出处!