产品经理到底有多难

最近回顾了一下从今年到现在做过的两个产品,一个是工具服务类,另一个是公司某业务线的项目;针对产品上线全流程,以复盘的角度,来讲讲背后踩的坑

一句话感慨下:产品真难!

对行业知识不够了解,需求分析跑偏。定位错误,导致产品调整。需求临时变卦,功能删删改改…..这些基本踩过,且很痛,以下是文章目录,一条条讲吧!

01 不清楚产品服务对象,是惨痛教训

两项目其中一个来源于总监对业务的规划,目的是 通过供应商对资源的有效竞争,来降低公司跨境物流成本;这个我最初的定位是做一个公司内部的工具

另一个来源于公司产品的迭代,根据公司现有业务和未来发展,对官网前后台进行重构

工具产品一开始的定位太窄,产品服务对象没搞清楚,对公司做这个产品的思考较少。如何站在公司业务角度思考需求,防止自己闭门造车呢? 这里根据案例整理两个核心点:

1. 我们如何切换思维?

试着把公司人力当工具组件、把服务当商品,把用户当买家。公司其实就是用工具组件制造商品,和用户交易

以工具 A 为例,最初定位是给内部员工用,整个链路是:用内部成本打造了一款商品,卖给了自己。既然都是卖,为何不多卖几个。

2. 我们如何站在公司角度评估业务?

当你找老板聊需求,总是会被问到:成本多少?收益多大?业务持续多久? 从老板的日常话语中,我们大概就能知道:产品价值 = 收益 – 成本。

最初工具 A的 收益是效率,成本是 技术开发 ,价值不好评估,可能收益不大;如果能开放使用,收益不会太局限,至于成不成就另外一回事了。

有时候,做产品的思维也可以运用到选职业:比如一份工作,收益是什么,成本是什么,持续性怎样?

02 不了解行业信息,是惨痛教训

了解行业信息其实就是调研,这个过程我有遇到了三个问题:

  1. 如何了解一个行业基本信息?
  2. 如何找目标用户并调研?
  3. 如何评估对用户了解程度?

1. 如何了解一个行业基本信息

为了熟悉行业知识,搜寻了相应资料。发现照搬有点不靠谱,太大而全,于是照猫画虎,整理出来的东西好像很厉害,但肚子里真正沉淀的不多;

做了无用功,花了大把时间,还没学到东西。

于是项目实践后,我尝试做一些删减,个人觉得做好这三点是能对行业有一个基本了解的。

  • 先了解行业基本信息:知乎、百度、谷歌上找,通过搜索我大概知道跨境电商行业,有仓储、物流、采购、供应商、亚马逊平台等,再逐个细分下去深挖一下,我的知识面就更广了;
  • 了解业务流程,及上下游角色:躬身入局,亲自实操一下;我们常用的做法是线下找相关岗位人观察,聊天,主要看他们做的 事情和协同交流部分。
  • 了解竞品:有些行业信息竞品是比我们更早察觉的,看看竞品看他们的玩法,可以尝试注册,找他们的客服销售问问题。

2. 目标用户?怎么调研?

B 端 寻找目标用户,其实就是做场景的还原;比如做人力资源管理系统,我们需要找 HR 还原现场,沟通日常招聘、邮件发放、资料管理等。

在做场景还原的时候,发现自己没有提前做问题大纲的习惯,导致最终的调研产出内容非常零散;这样一来,需求分析是很容易出错的。

其实找用户调研的时候,很有必要提前准备一些问题,和用户聊的时候思绪会更清晰。比如 提前整理表格,列出核心问题,尽量不做无效沟通。

类似于这样:

3. 对用户了解程度?

因为上一次调研,信息收集不全,导致后续自己三番五次  找用户请教问题。

因为对用户不够了解,遇到任何规则的变化,我们很容易陷入联想状态,假设的越多,错得也就越多。提供一个参考思路:

  • 首先按照上述方式调研场景,整理并划分好用户基本类型和特征,这里的特征不是性格特点,是用户群体对行为的偏好。
  • 针对不同用户类型,若预测用户在不同外部条件下的预期和行为,说明我们对用户的掌握基本合格。

比如用户登录密码错误,用户可能会产生懊恼情绪,会尝试找回密码,感受用户也是同理心的过程。

03 产品定位错误,是惨痛教训

产品定位踩过的坑:产品定位有用户、痛点、也有方案,但忽略了盈利和收益。

工具 A 最初定位是给内部使用,调研过程用户述求不断。让自己陷入了功能堆积过程。刚开始的架构思路 大体上是这样的:

后来站在其他公司的角度,发现需求依旧存在(有竞品),于是在方案上加了一层用户关系。把工具 A 迭代成服务平台。这样的改动,给产品带来盈利的可能性

表面一些小改动,触动的是后台整个逻辑的修改。增加一层用户,实际上后台增加的有:账户体系、付费模块、数据关联表修改等。所以,做 B 端产品,决策路径很长,千万不能忽视了任何一个改动。

为了避免熬夜爆肝,产品设计之前,我们得先把定位想清楚。其次是,如果做一个产品,一开始就在不断累加需求,多问问自己用户是不是找对了。

04 产品设计不规范,是惨痛教训

产品设计阶段做的更多是模块和流程性的梳理,先定义问题,再找场景,然后梳理规则,最后抽离模块;比如这样:

但这个过程也遇到了两个问题,十分困扰。

  • 产品设计如何避免东拼西凑,有条理进行展开?
  • 功能和规则这么多,配置怎么做?

产品设计时感觉自己信心满满,业务催催需求,就乱了阵脚,跳过功能设计开始画图。结果证明,越画越乱。

后来强迫自己回到正轨,会议、催需求,先晾着,完整流程先跑通(回顾一下我的整个流程):

关于配置的问题:也是踩了太多坑,我们总想把所有功能都做成配置,用户想要什么,产品上给个界面,用户自己设置。

于是在这种思路下,我发现最后出来的产品后台,还没上线就显得十分臃肿

过程中总结了部分规律,发现功能配置其实有一个核心思维在的:频次 & 范围 四象限;

像电商后台产品,类似商品添加,价格设定这种,涵盖用户量大,且切换频率较高的,妥妥的配置。

05 评审成批斗会,是惨痛教训

直到项目开发,我才发觉要检查一下逻辑,看看文案,再想想交互

于是准备不够充分,评审会高光时刻成了批斗会。业务会觉得比产品更懂需求,开发觉得逻辑理解优于产品。总之百口莫辩,事情讲不清楚,一个问题 N 多方案。

后来自己整理了一张自查表,项目开发之前,我时不时就会看下,这里分享一下:

06 需求失控是惨痛教训

加需求了怎么办?

你是否有这样的经历:开发到一半,业务过来教你做人(做产品) 老板或者业务咨询一下需求状况,灵感爆发,给我们提几个优化,导致需求变更。

在做官网 B 产品的时候,我经历了两次官网核心下单业务的修改,主要是项目到开发阶段了,业务对需求二次定义,麻烦的不是补充内容,而是在修改,产品逻辑改动,可能对产品最终的走向都会产生影响。

新增需求我们要看对现有影响,也要看是否可持续。其次产品设计阶段,我们是比业务更懂产品逻辑的,如果需求不符合产品定位,可以打回去。即便是新增也要尽量归并二期。

针对需求变动,在需求评审之前,很有必要拉上业务,将模块、流程、原型和UI 进行共享,内容走查,确保需求完善。当然,也要有一定领导力,主动推进项目,给开发小哥一点关爱

07 项目延期是惨痛教训

项目延期了怎么办?

上线推迟,作为产品经理,我们怎么都脱不了干系。

为减少推迟上线对业务的影响,可以尝试:

  • 提前制定里程碑:在什么时间点完成那些核心功能,提前准备内容;
  • 上线二次预估:预计推迟到什么时候,保证后续资源能继续开发;
  • 广而告之:将里程碑、现有进度、发布时间和开发 及 业务多方确认,想办法分配资源。

过程中,主人翁意识强一点,专业度就会有提升,别人会觉得我们靠谱。

总之让产品由我们掌控,把问题扼杀在过程,不能等到开发上线后再解决。

08 关于迭代的思考和复盘感悟

B 端产品迭代的思考

产品进阶是一个缓慢迭代过程,B 端类产品升级频率较低,但并不意味不需要迭代。这次实践过程,让我体会到 B 端产品更需要 关注变化。“牛鞭效应”就是一个很好的例子。

系统服务类的产品 实际上非常个性化的,本质原因就是因为场景的不同。比如我们把一个产品开放,即便基本模块都有,遇上不同客户,定制化需求依旧很多。

系统服务类的产品很多时候是在还原 场景,服务多少企业,可能就有多少种服务方式。

所以,B端产品个性化是件好事,很多企业初期就是在提供个性化服务,待成型,才考虑标准化。

最后分享复盘的五点感悟:

  1. 问题复杂度越高,解决过程越投入,成长也会更快;
  2. 产品方法论终究是方法,实践内容和结果还是得自己慢慢找;
  3. 如果解决问题的方案过于复杂,不纠结,有可能是问题本身不对;
  4. 以用户角度看问题,以生意角度思考业务,比如收益、成本,是否一直存在;
  5. 复盘包含:实践、思考、回顾、调整,难在调整,因为是推翻自己的过程;
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值