集团旗下网站: 奇酷集团 | 迈领人才网 | 奇酷方舟
全国咨询热线:400-807-8991
您现在所在的位置:首页 >学员就业 > 就业宝典 > 产品经理有多难,让人头秃

产品经理有多难,让人头秃

来源:奇酷学院 发表于:

产品经理有多难,让人头秃!

  01 不清楚产品服务对象,是惨痛教训
 
  两项目其中一个来源于总监对业务的规划,目的是 通过供应商对资源的有效竞争,来降低公司跨境物流成本;这个我最初的定位是做一个公司内部的工具。
 
  另一个来源于公司产品的迭代,根据公司现有业务和未来发展,对官网前后台进行重构。
 
  工具产品一开始的定位太窄,产品服务对象没搞清楚,对公司做这个产品的思考较少。如何站在公司业务角度思考需求,防止自己闭门造车呢? 这里根据案例整理两个核心点:
 
  1. 我们如何切换思维?
 
  试着把公司人力当工具组件、把服务当商品,把用户当买家。公司其实就是用工具组件制造商品,和用户交易。
 
  以工具 A 为例,最初定位是给内部员工用,整个链路是:用内部成本打造了一款商品,卖给了自己。既然都是卖,为何不多卖几个。
 
  2. 我们如何站在公司角度评估业务?
 
  当你找老板聊需求,总是会被问到:成本多少?收益多大?业务持续多久? 从老板的日常话语中,我们大概就能知道:产品价值 = 收益 – 成本。
 
  最初工具 A的 收益是效率,成本是 技术开发 ,价值不好评估,可能收益不大;如果能开放使用,收益不会太局限,至于成不成就另外一回事了。
 
  有时候,做产品的思维也可以运用到选职业:比如一份工作,收益是什么,成本是什么,持续性怎样?
 
  02 不了解行业信息,是惨痛教训
 
  了解行业信息其实就是调研,这个过程我有遇到了三个问题:
 
  1.如何了解一个行业基本信息?
 
  2.如何找目标用户并调研?
 
  3.如何评估对用户了解程度?
 
  一、如何了解一个行业基本信息
 
  为了熟悉行业知识,搜寻了相应资料。发现照搬有点不靠谱,太大而全,于是照猫画虎,整理出来的东西好像很厉害,但肚子里真正沉淀的不多;
 
  做了无用功,花了大把时间,还没学到东西。
 
  于是项目实践后,我尝试做一些删减,个人觉得做好这三点是能对行业有一个基本了解的。
 
  先了解行业基本信息:知乎、百度、谷歌上找,通过搜索我大概知道跨境电商行业,有仓储、物流、采购、供应商、亚马逊平台等,再逐个细分下去深挖一下,我的知识面就更广了;
 
  了解业务流程,及上下游角色:躬身入局,亲自实操一下;我们常用的做法是线下找相关岗位人观察,聊天,主要看他们做的 事情和协同交流部分。
 
  了解竞品:有些行业信息竞品是比我们更早察觉的,看看竞品看他们的玩法,可以尝试注册,找他们的客服销售问问题。
 
  二、 目标用户?怎么调研?
 
  B 端 寻找目标用户,其实就是做场景的还原;比如做人力资源管理系统,我们需要找 HR 还原现场,沟通日常招聘、邮件发放、资料管理等。
 
  在做场景还原的时候,发现自己没有提前做问题大纲的习惯,导致最终的调研产出内容非常零散;这样一来,需求分析是很容易出错的。
 
  其实找用户调研的时候,很有必要提前准备一些问题,和用户聊的时候思绪会更清晰。比如 提前整理表格,列出核心问题,尽量不做无效沟通。
 
  类似于这样:
 
  三、对用户了解程度?
 
  因为上一次调研,信息收集不全,导致后续自己三番五次  找用户请教问题。
 
  因为对用户不够了解,遇到任何规则的变化,我们很容易陷入联想状态,假设的越多,错得也就越多。提供一个参考思路:
 
  首先按照上述方式调研场景,整理并划分好用户基本类型和特征,这里的特征不是性格特点,是用户群体对行为的偏好。
 
  针对不同用户类型,若预测用户在不同外部条件下的预期和行为,说明我们对用户的掌握基本合格。
 
  比如用户登录密码错误,用户可能会产生懊恼情绪,会尝试找回密码,感受用户也是同理心的过程。
 
  03产品定位错误,是惨痛教训
 
  产品定位踩过的坑:产品定位有用户、痛点、也有方案,但忽略了盈利和收益。
  工具 A 最初定位是给内部使用,调研过程用户述求不断。让自己陷入了功能堆积过程。刚开始的架构思路 大体上是这样的:
 
  后来站在其他公司的角度,发现需求依旧存在(有竞品),于是在方案上加了一层用户关系。把工具 A 迭代成服务平台。这样的改动,给产品带来盈利的可能性。
 
  表面一些小改动,触动的是后台整个逻辑的修改。增加一层用户,实际上后台增加的有:账户体系、付费模块、数据关联表修改等。所以,做 B 端产品,决策路径很长,千万不能忽视了任何一个改动。
 
  为了避免熬夜爆肝,产品设计之前,我们得先把定位想清楚。其次是,如果做一个产品,一开始就在不断累加需求,多问问自己用户是不是找对了。
 
  04 产品设计不规范,是惨痛教训
 
  产品设计阶段做的更多是模块和流程性的梳理,先定义问题,再找场景,然后梳理规则,最后抽离模块;比如这样:
  但这个过程也遇到了两个问题,十分困扰。
 
  产品设计如何避免东拼西凑,有条理进行展开?
 
  功能和规则这么多,配置怎么做?
 
  产品设计时感觉自己信心满满,业务催催需求,就乱了阵脚,跳过功能设计开始画图。结果证明,越画越乱。
 
  后来强迫自己回到正轨,会议、催需求,先晾着,完整流程先跑通(回顾一下我的整个流程):
 
  关于配置的问题:也是踩了太多坑,我们总想把所有功能都做成配置,用户想要什么,产品上给个界面,用户自己设置。
 
  于是在这种思路下,我发现最后出来的产品后台,还没上线就显得十分臃肿。
 
  过程中总结了部分规律,发现功能配置其实有一个核心思维在的:频次 & 范围 四象限;
 
  像电商后台产品,类似商品添加,价格设定这种,涵盖用户量大,且切换频率较高的,妥妥的配置。
 
  05 评审成批斗会,是惨痛教训
 
  直到项目开发,我才发觉要检查一下逻辑,看看文案,再想想交互。
 
  于是准备不够充分,评审会高光时刻成了批斗会。业务会觉得比产品更懂需求,开发觉得逻辑理解优于产品。总之百口莫辩,事情讲不清楚,一个问题 N 多方案。
 
  后来自己整理了一张自查表,项目开发之前,我时不时就会看下,这里分享一下:
 
 
  06 需求失控是惨痛教训
 
  加需求了怎么办?
 
  你是否有这样的经历:开发到一半,业务过来教你做人(做产品) 老板或者业务咨询一下需求状况,灵感爆发,给我们提几个优化,导致需求变更。
 
  在做官网 B 产品的时候,我经历了两次官网核心下单业务的修改,主要是项目到开发阶段了,业务对需求二次定义,麻烦的不是补充内容,而是在修改,产品逻辑改动,可能对产品最终的走向都会产生影响。
 
  新增需求我们要看对现有影响,也要看是否可持续。其次产品设计阶段,我们是比业务更懂产品逻辑的,如果需求不符合产品定位,可以打回去。即便是新增也要尽量归并二期。
 
  针对需求变动,在需求评审之前,很有必要拉上业务,将模块、流程、原型和UI 进行共享,内容走查,确保需求完善。当然,也要有一定领导力,主动推进项目,给开发小哥一点关爱。
 
  07 项目延期是惨痛教训
 
  项目延期了怎么办?
 
  上线推迟,作为产品经理,我们怎么都脱不了干系。
 
  为减少推迟上线对业务的影响,可以尝试:
 
  提前制定里程碑:在什么时间点完成那些核心功能,提前准备内容;
 
  上线二次预估:预计推迟到什么时候,保证后续资源能继续开发;
 
  广而告之:将里程碑、现有进度、发布时间和开发 及 业务多方确认,想办法分配资源。
 
  过程中,主人翁意识强一点,专业度就会有提升,别人会觉得我们靠谱。
 
  总之让产品由我们掌控,把问题扼杀在过程,不能等到开发上线后再解决。
 
  08 关于迭代的思考和复盘感悟
 
  B 端产品迭代的思考
 
  产品进阶是一个缓慢迭代过程,B 端类产品升级频率较低,但并不意味不需要迭代。这次实践过程,让我体会到 B 端产品更需要 关注变化。“牛鞭效应”就是一个很好的例子。
 
  系统服务类的产品 实际上非常个性化的,本质原因就是因为场景的不同。比如我们把一个产品开放,即便基本模块都有,遇上不同客户,定制化需求依旧很多。
 
  系统服务类的产品很多时候是在还原 场景,服务多少企业,可能就有多少种服务方式。
 
  所以,B端产品个性化是件好事,很多企业初期就是在提供个性化服务,待成型,才考虑标准化。
 
  最后分享复盘的五点感悟:
 
  1.问题复杂度越高,解决过程越投入,成长也会更快;
 
  2.产品方法论终究是方法,实践内容和结果还是得自己慢慢找;
 
  3.如果解决问题的方案过于复杂,不纠结,有可能是问题本身不对;
 
  4.以用户角度看问题,以生意角度思考业务,比如收益、成本,是否一直存在;
 
  5.复盘包含:实践、思考、回顾、调整,难在调整,因为是推翻自己的过程。