产品上线的7个惨痛教训,说多了都是泪

17 评论 1.3万 浏览 123 收藏 20 分钟

文章为作者产品上线的项目复盘,希望能够对产品路上的各位带来一些启发。

最近回顾了一下从去年年底到现在做过的两个 B 端产品,从需求调研到产品设计再到最后上线落地,耗时接近4个月;整体来看,时间有点超出预期。作为产品经理的我,有很大一部分责任的

从开始的行业不够了解,需求分析跑偏。到定位错误,导致产品调整。也经历需求临时变卦,功能不断修改调整……不过,好在项目最终都顺利上线!

发表一下感慨:产品真难

不过这些坑都是非常宝贵的经历,对于产品而言,如果能有效地进行思考、复盘、调整,或许能带来很多新的东西。

那过程中,我究竟经历了踩了哪些坑呢,以下是文章目录,我们一条条看!

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. 复盘包含:实践、思考、回顾、调整,难在调整,因为是推翻自己的过程;

本文以自己项目经历在此抛砖引玉,如果大家有不同意见欢迎一起交流。希望能和喜欢写字的你,交个朋友。

 

本文由 @好奇产品铺 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写的真好 😉

    回复
  2. 很棒,请教下您一个项目上线零预算获取用户有没有好的建议呢?

    回复
  3. 很赞 😉

    回复
  4. 半路改需求真是深有同感,真是要骂娘,在我看来,PM要么最好是个女生,业务不能拿你怎么样,要么就是社会人,否则被牵着鼻子走。

    回复
    1. 这个想法可以,哈哈哈

      回复
  5. 请问是两个B端产品共耗时四个月还是,每个分别耗时四个月?

    回复
  6. 正在经历,好文

    回复
    1. 哈哈,谢谢反馈!是最近遇到了某相同经历吗?

      回复
  7. 回复
  8. 很有共鸣,向你学习,多多复盘总结!坐等更新

    回复
    1. 蟹蟹

      回复
    2. 方便告诉我,你觉得哪一块比较有共鸣吗?嘻嘻

      回复
  9. 很棒,是我目前遇到的情况,感谢总结

    回复
    1. 笔芯

      回复
    2. 哈哈,方便简单说下,你最近遇到的情况吗,如果有好的经验更棒啦!

      回复
  10. 讲真,产品经理真的被人低估了吧,什么都要会,什么都得用,左原型右设计,进能写代码后能做运营。yysy,原型用墨刀,设计用sketch都还可以~

    回复
    1. 哈哈,你说的这些都是工作技能。产品需要的技能确实比较多,可能更值钱的是业务的理解、规划,还有团队领导力,你怎么看?

      回复