在信息部门,对产品侧关于联合创新协同研发的思考

文辉
0 评论 4330 浏览 6 收藏 8 分钟

如何设计一款好产品?首先需要了解产品本身,其次是了解用户,而这只是产品经理要考虑的基础。本篇文章,作者将系统分析做一款好的产品该从哪些方面入手,希望能对你有帮助。

一、两个问题

  1. 知己:是否了解品牌的特性?
  2. 知彼:是否了解的用户特性?

需要深入业务体系,如果业务部门没有弄清两个问题,那么我们就要去了解。不能两个盲人走路全靠感觉,给业务团队提供系统就要做到比业务团队更懂业务,这样才能设计出超出预期的产品。

为什么要听你的,你能帮他们解决问题甚至是发现问题。

二、两种模式

1. 模式 1

业务团队只说明他们想要解决的问题,需要我们自己去挖掘,真问题还是假问题?解决这个问题的本质是什么?

甚至我们自己发现问题,然后才划定边界,确认需求。

  • 优点:充分发挥解决方案经理的能力,深挖需求;业务团队只关注结果(是否能够解决他们的问题),他好你也好。
  • 缺点:容易造成思想的冲突,我们自己认为的,不一定是业务认为的,会带来一些争吵。但是我反而认为这是对的,也是我们跟外包公司不一样的地方。因为我们和业务团队的目标一致,在争吵中发现问题的本质,找到一条最优的解决。

2. 模式 2

业务团队全程参与产品设计,每个功能都逐个确认确认(布局、配色、样式)。

  • 优点:目标清晰,责任划分清晰。
  • 缺点:生产出来的产品是工厂化的,自己的价值被降低,业务决策成了成败的关键。同时每一次和业务部门的确认,都是一份责任的累加;也很难做出超出用户预期的产品。

不同阶段采用不同的模式。

三、两种目标

  • 短期目标:业务满意,这个就简单了,他们要啥给做啥呗。我们就像个外包公司一样,找外边公司做和我们做有什么区别吗(成本?质量?时间?还是更大的热情,能够倒推业务进度),本质上是一样的。
  • 长期目标:互相成就,以业务目标为目标,互相成就。

万事只求十全九美,学会在不完美中找平衡,业务满意或是超出预期的同时以长期目标为导向,如果冲突了咋办,如何选择。

应该多一些思考,为什么做,怎么做。

四、两类解决方案经理

我们都希望的合作伙伴(有权、有钱、专业),但是往往跟我们对接的部门或者人并不能完全满足,事还得干,不同的解决方案经理就有了差别。

1. 一类产品

只接需求,业务部门提什么就做什么,好一些的会反推业务进度,能设计出更加SaaS化,更友好的体验。但是结果不能由自己把控,短期目标可以完成,也就是业务部门满意。

但是长期目标无法保障,只能把希望寄托在业务部门身上。他们用得好,能实际解决工作中的问题,那就算成功了。

但是真正能提出真需求的业务部门的人并不多,同时还有背锅被甩锅的风险,长此以往就是恶性循环。

靠几次沟通会,往往解决的都是表面问题。

不是业务团队不想表达清楚他们的真正需求,是真的表达不出来。

就像医生给病人看病一样,我们不能头疼医头,脚疼医脚,病人说腰疼,难道我们就直接给做个靠垫吗?还是说要查一下更深层的原因。

万一他有什么难言之隐呢?也许他是肾虚呢?你说给他做个靠垫有啥用。

2. 另一类产品

会深入业务,主动发现并提出需求,需要对业务有更高更深刻的理解。

首先要解决的是一个核心问题:为什么做?背景是什么样的?是真的吗?有没有特殊情况?

真正想服务好一个部门、提供一套好的产品并不容易的,不止停留在冰山的上层,需要挖掘更深层次的内容,而能够挖多深就体现了一个产品的内在能力。

如果我们真正的解决了一次,哪怕只有一次业务部门的真正问题,他们会对我们无比的信任。

如果想快速进阶产品,需要有那么一次甚至多次的沉浸式投入,做到比业务部门更懂业务。

五、和研发的关系

  • 一个失败:研发和产品讨论业务逻辑,那就是产品经理的问题,无可争议,产品经理在出需求前就已经明确了业务场景,并且和业务团队达成一致。
  • 一个成功:和研发目标一致,确认解决的核心问题,同步背景;研发也能充分发挥他们的能力,在设计底层架构、数据库的时候能够做到更科学、更高效、更灵活。

六、多个视角

看产品,看问题,更多的视角。

如果我是业务运营、如果我是业务领导视角、如果我是用户,用一个词概括就是共情。

视野更开阔,看待问题更加多元化,自己也会更踏实。

七、一套规则

产品的KPI设定不能只满足于做了多少个需求、上线了多少个功能;帮助业务部门增加了多少用户、提高了多少销量、减少了多少人工、提高了多少效率同样值得参考,牢牢绑定解决方案经理和业务团队。

八、自身成长

闷头做产品很难快速成长。

  • 开拓视野:每天看看36k、艾瑞咨询这类网站,了解互联网行业的最新动态,同时类似点燃、驿氪这类运营分享的公众号也是要经常浏览,产品运营是一家,你得懂人家。
  • 论坛峰会:多和高手过招,才能发现自身的不足,有时间就线下,没时间线上也是要听听的。
  • 产品分析:其实就是拆解外部产品,拆的过程就是学的过程,看看别人的架构、别人的设计;灵光乍现的一刻会经常出现,同时和自己设计的产品进行对比分析,不想成长都难。

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

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!
专题
38663人已学习11篇文章
世间万物皆有套路,面试更是如此,多拿几个靠谱offer。
专题
13714人已学习13篇文章
产品体验报告,是体验者在深入了解某个产品的商业模式、使用场景、产品功能等方面后,所作出的先有深度再到广度的图文分析报告。本专题的文章分享了不同产品的体验报告。
专题
12230人已学习15篇文章
当业务进入某一阶段之后,用户新增可能会趋向疲软,这个阶段里,运营人员可能会需要召回流失用户。本专题的文章分享了用户召回策略。
专题
14514人已学习14篇文章
用户生命周期是每个产品经理都必须要注意的一个点,它能够衡量用户对产品产生的价值,也是运营手段的最终衡量指标。本专题的文章分享了如何做好用户生命周期管理。
专题
16732人已学习12篇文章
如何搞懂财务和业务之间的关系,并推进业务系统财务模块的建设呢?本专题的文章分享了财务系统的设计指南。