开发转产品必会基本技能(一)概述

个人经历

相信很多人会和我一样,有想要做出现象级产品的心,在这个社会留下自己的一点影子,其中最简单成本最低途径就是成为一个公司产品负责人,负责整个产品的开发流程。从刚开始上大学的时候就想成为雷军一样的男人,通过自己努力写出一个每人都很喜欢用得产品,所以选择了软件开发专业,之后也从事了差不多两年的java开发工作。在这个过程当中一直没有忘记自己要成为怎么样的人,一直在学习产品方面的相关知识,直到两个月前转行成为了产品经理。

在这里分享一下关于产品的技能架构和工作流程。

 

产品人的几个特征

  1. 具有创新精神,对某一个产品或某一个产品功能有自己的见解,善于发现需求
  2. 有一个想创业改变某个现状的心,都说产品经理是公司ceo的学前班,这句话一点也不为过
  3. 有求知精神,喜欢去学习各个领域的东西
  4. 做出来的产品,自己内心很有成就感

 

基本技能

竞品分析

古有云“知己知彼, 百战不殆”,互联网的竞品分析主要是针对竞争对手进行分析和比较。确定产品的市场切入点和后期工作的中心,影响上级和团队决策的书面输出形式。

如果产品目标没有确定好,很有可能就会拿市面上现象级的产品作为竞品,开发到最后会发现自己只是把那个产品给抄下来,出来的效果相比起竞品变化很微妙,没有自己的灵魂。然后又不断的迭代更新,很容易陷入一个推翻-需求-开发的死循环里,花费巨大的时间成本和人力成本。

 

其中文档主要包含以下几点

  1. 竞品说明:选了什么作为竞品,选择竞品的原因
  2. 产品描述:我方产品目标及定位,粗略的用户群体划分
  3. 功能说明(选择需要参考的主流程)
    1. 使用场景:触发流程的用户场景
    2. 满足的需求:帮用户解决了什么问题
    3. 流程:说明竞品的主流程的流程及说明
    4. 交互:竞品功能的ui交互、布局结构
    5. 功能总结:竞品之间缺点、优点、个人的分析
  4. 整体总结:综上所述,产品未来的市场切入点和重点的工作

:获取竞品的途径可以从七麦数据、app store、应用商店、同行交流群等地方获取,对于tob的产品,可以在市面上找到相关公司直接作为目标客户找销售直接咨询。

需求文档

需求文档包含两种,产品需求文档(prd)市场需求文档(mrd),在产品工作中比较常用到prd,其中prd的格式相对固定,写起来有规律可循。一个好的prd绝不是一个格式很全的prd,好的prd判断标准取决于文档的受众,受众怎么在最短的时间get到要表达的点,明白整个功能的属性和流程,这才是最重要的,这也是很多同事不看你prd的原因,就是因为写了很多充分不必要的点。这里有一个prd的模板,是xiaopiu原型工具的案例,供大家学习

案例

https://xiaopiu.com/prd/5ce2621a96541012dae2ae07

 

:其中文档的错误流程要做完善,很多人在做文档画原型的时候会忽略错误流程,把重点关注在主流程和交互上。留给开发、测试、设计的同事无限的遐想空间,这会让团队成员很“难受”,开发出来的产品也会出现一些很影响用户体验的事件出来,比如:抢购场景,商品已经没有库存,用户已经在付款页面进行支付验证后点击付款,没有商品是直接提示他商品不存在还是商品库存不足,是否取消订单还是将订单保留在购物车,这些流程尽量不要让别人去发现。

原型

原型是产品日常工作最常用的交流手段,对客户、老板、开发、运营、测试基本都用原型交流,好的原型配合需求文档都不用和他们交流他们都能了解每个流程每个细节。其中axure、墨刀,两个是市面上比较成熟的原型工具,其中axure比较权威,能做的交互比较多,墨刀出原型比较快,能做的交互比较少。个人选择用墨刀,出原型比较快,产品也不是ux,用墨刀我能把更多的时间花在思考产品本身上。

数据分析

我们得知道一个前提,数据分析的目的是为了帮助产品负责人决策,产品毕竟不是专业的数据分析师,在公司里面也有专门的职位去做这些数据分析的事,但是作为产品负责人得知道一些比较常用的指标去观察一个产品的情况,比如AARRR海盗模型、日活跃、新旧用户比例、热力图,线性回归、朴素贝叶斯分类、推荐算法,市面上很多工具和第三方sdk都可以得到很完善的可视化界面,这里推荐百度统计和友盟。

运营

市场运营、社区运营、内容运营、活动运营、推广运营,运营是很好的收集需求的渠道,产品经理能从当中获得各种各样的需求,如何筛选其中的需求是产品工作中非常重要的一环。在很多规模比较小的公司中没有具体的运营人员,但也不要忽视运营的重要性。

沟通

在日常工作的过程中,团队成员之间交流、资源申请、客户对接都需要一定的交流沟通能力,在这我也没有具体的方法论,一般自己都是对成员提倡每个成员的想法和意见,从采集的需求列表中去判断所提出的需求对产品带来的影响。不去触及别人的专业知识领域,虽然也是开发出身平时也喜欢写代码,但出风头去冒犯别人的知识领域这是很不礼貌的行为。对于上级尽量采用,原因+结论+方法+成本的说话形式,带着方案去会面。对于客户尽量保持同理心,很多不切实际不符合逻辑的需求站在他的用户场景,提出其他解决方案,这是一种责任,当然给钱叫你做,就是不合理的都得做,客户是爸爸。

其他能力

互联网产品经理在大学是没有相关科目的,很多从业者都是处于不同行业转到产品岗,其中有技术、设计、运营、销售比较常见,其实这也是很多人争论的点,我到底从哪个岗位转到产品岗比较有优势,技术说“我懂具体的实现,没我你做不了东西”,这也是很多程序员的傲气。设计说“没我设计的东西,你什么也不是”。运营说“我懂用户需求(或许他也不懂),我知道产品在市场的趋势”。销售说“我能把东西卖出去,我知道客户要什么”,看起来每个人都有优势,那哪个比较有优势比较重要呢,我认为是专精会全,精通其中的一项技能或者多项技能,其他的都要会,对产品的审美,了解需求,了解市场趋势,懂客户的需求这些都要会但不需要精通。从其他行业转进来,就已经满足其一的技能,对未来的产品工作有一定的帮助,但不要忽略了其他技能的培养。

 

 

工作流程

产品目标

在立项的开始,作为一个产品负责人脑海中就必须比谁都知道你这个产品是干什么的,针对的是哪个行业,市场的局面,以及竞争对手,市场的切入点,盈利模式,以及未来发展的趋势。这里可以用一些常用的模型如swot模型,波特五力去有意识的思考一下再作出行动。

swot模型(图来源自百度)

开发转产品必会基本技能(一)概述

波特五力

开发转产品必会基本技能(一)概述

确认用户群体

确定用户群体是非常重要的一个环节,一个东西谁来用,谁会天天用,谁用了一次不用,一个产品的idea再好也不可能让所有人都用他,只能服务于一部分的受众,如何确定受众是一件很难的事一两句话说不清,之后的日子我会用我的亲生经历去描述我的方法论。

可以用到的方法

  1. 自身去感受,让自己变成用户
  2. 问卷调查
  3. 数据分析

明确产品验收标准(关键指标)

给自己的产品下一个验收的标准,比如日活跃到底多少,交易金额要到达多少,这得看产品的定位和性质去制定不同的指标。

竞品分析

竞品分析的主要目的是为了比较市面上竞争情况,确定市场切入点的手段。

确认需求、用kano模型确认优先级

从各个渠道收集完需求之后,就得确定哪些需求是真实需求哪些是虚假需求了,每个需求都是真实存在的客观情况,没有好坏,但对于每一个产品而言都有其必要性,对于没有必要性的需求就得把他搁置起来。这里推荐一个kano模型,利用这个模型可以培养自己相关的需求整理思维,这个模型也是比较主观的,很多决策也是通过主观意识去决定。

kano模型

开发转产品必会基本技能(一)概述

必备属性:当优化此需求,用户满意度不会提升,当不提供此需求,用户满意度会大幅降低

期望属性:当提供此需求,用户满意会提示,当不提供此需求,用户满意度会降低

魅力属性:用户意想不到的,如果不提供此需求,用户满意度不会下降,当提供此需求用户满意度会有很大提升

反向属性:用户没有需求,提供影响用户满意度

无差异因素:无论提供什么功能对用户的体验没有什么影响

输出相应文档和原型

需求确认下来之后就应该是输出相应的需求文档和原型,需求文档面向的对象根据不同的对象侧重点也不一样,在面向测试的人员,更侧重业务流程和错误流程的描写,面向程序人员应该更侧重业务流程、错误流程、属性说明、交互说明方面的说明,面向运营人员侧重属性的说明、功能要达到的目的和指标。或许这和产品的工作性质有关,文档的目的是为了方便他们的工作。对于原型我个人认为不用做的太细,原型是为了将脑海中的产品具现化出来给团队的人员实现。

项目管理

在整个项目的启动、规划、执行、实施、测试反馈的整个过程当中,需要对整个项目的质量、进度、结果、人际关系、需求进行管理。其中比较常见的是瀑布式开发和scrum敏捷开发管理,可以用一些看板工具进行项目管理工作的开展,这里推荐腾讯的TAPD或者是传统的execl。其中TAPD挺全的,很适合敏捷开发管理,很多模块都是针对于互联网快速迭代更新而设计,也有很多模板,对于没有专业项目管理知识的人员比较友好,如果对数据没有什么保密性建议使用。

通过数据修正和发现问题

正式上线,开始运营,通过数据分析进行精细化运营(数据驱动运营的模式)的方式发现未发现的需求和已经存在的问题,提出改进的意见。

结果与复盘

一个版本的复盘相当于是产品的自我反省,“吾日三省吾身”,在一个阶段规划和指标在结束完成时达到了多少,是否需要调整战略布局,下一个阶段的指标和目标又是什么。

优化迭代

采集新的需求,重复上面步骤,形成一个闭环。

 

自身素养

有意识的培养对事物的感知,培养看产品的高度

纵观原始时期到现在,产品的目的就是为了满足人的需求,举个例子,为了满足人的出行方便需求,交通方式从马车到汽车,为了让出行更方便从公交车到地铁,其本质都是源于出行,用心感受现实中存在于我们身边的事物,都是每个产品人对需求满足所产生的产物。

多接触圈子里的人

产品圈里的人基本都是艺术家,像画家一样,每个人想法不一样,画风不一样,看事情角度不一样,所处的领域和层级不一样,多交流发现其他人身上的方法论和优点,不断完善自我。

自身也是一个产品

自身其实也是一个不断迭代更新的产品,通过计划+复盘(看了几本书,写了多少读后感)、学习不断更新自己,提升自身的高度和价值

保持关注行业动态,多接触不同的用户群体

这里推荐36kr,虎嗅网,youtube,bilibili。对于前面三个可能很多人都可以认同,对于bilibili可能很多人就会吐槽了,一个二次元动漫和漫画的宅文化平台对产品发展有什么帮助。随着bilibili的不断发展,bilibili更向着一种综合性的社区去变化,在平台中可以发现更多类型的视频,也有更多不同类型的内容创造者,音乐、电影、教育、搞笑等,让人感觉B站不再是一个看视频的网站,而是一个各种文化集合的社区,里面有各式各样的圈子,可能是未来某一个现象的孵化地。

 

思维方式

“人人都是产品经理”这句话其实是挺扯淡的一句话,虽说每个人对产品的感知和对世界的感知都存在自己的见解,都可以发表对一个产品的言论和想法,但和很多人交流的过程当中我发现一般的人都会将对产品思维的方式更多的会停留在ui视觉层或者是交互层面,会听到很多话“为什么人家这个产品有你设计的这个产品没有“ 不会去思考这个产品的本质是什么,为什么要这么设计,“我有一个很不错的idea可以改变世界”,停留在发现需求,不去思考渠道、供应链、成本等问题,思考不全面,千万不要有一种错觉,发现了某一个需求脑子一热就觉得自己是个可以改变世界的人。

其中经典的产品体验设计中的层级对我思考的方式影响挺深,在接到一个竞品或者功能的时候我就会由下而上的去解析这个产品,在做自己产品或功能的时候我会从上至下的去构思。

战略层

(企业愿景、产品定位、需求把控、用户习惯、商业模式)

范围层

(主要功能、核心功能、功能架构、业务流程)

结构层

(信息架构、常规功能、特色功能、实际情况、用户流程分析)

框架层

(操作情况、刷新、页面跳转、查询、交互框架、界面设计、标签设计)

视觉层

(排版 布局)

 

机遇

俗话说 “生死有命,富贵在天”当前提条件充分的时候,没有达到自己该有的成就不要灰心,继续充实自己准备好迎接到来的机会,加油。

结语

上述的是我工作的一些经验和总结,展示出一个日常工作框架,没有细节到每一个工作事项去说明。欢迎各位同行和前辈 +我个人V交流 一起学习进步“Dream_4653”(≖ᴗ≖)✧

开发转产品必会基本技能(一)概述