(17年工作总结)
产品的准备
关键词:业务、用户、需求、市场
立项目
产品的工作其本质是项目管理的工作,只是产品更多的是靠功能去满足需求,而项目的适用范围更广阔。从项目管理的经验考虑,一个产品最开始的工作是确认立项,即”公司的哪些业务能够转变成产品“。
要将其转变成产品,首先我们要明白这个业务是否真的需要做一个产品,也就是在内部调研是否有更好的解决办法。
举一个例子,比如手游推荐平台。由于现在市面上的应用市场琳琅满目,再加上大厂手机都有自己的手游应用商店(如华为应用市场、锤子游戏中心等),因此开展这个业务走线上产品app路线并不是最佳选择,接踵而来的问题是如何拥有装机量,如何形成自己的差异化,如何比自带商店更方便靠谱?并且,该领域的第三方竞品也是种类繁多,如PP助手、安智等老牌商店已经拥有足够庞大的市场份额,想要从中突破更是一项艰难的工程。
因此,当公司拥有或者打算开展这一项业务时,产品经理有必要首先思考这个业务是否值得转化为一个产品,而不是盲目听从公司领导决策。
比如上面说到的例子,既然线上app面临如此考验,何不另辟蹊径,做线下手游推广平台呢?
是否需要转化产品,可以从下面三个点考虑:
- 是否有更好的解决办法
- 产品的成本在哪
- 业务的服务对象是谁
产品的成本是什么?某些领域业务转变为产品是很不错,但是面临的成本是高昂的。比如直播领域目前已经到了行业成熟阶段,两大细分内容素人与游戏已经出现了细分行业领导者,拥有绝对的品牌壁垒,这就是产品所要面对的成本。
一个行业如果走到了细分领域,那这个行业无疑是走向成熟的。所有行业的规律在笔者看来都是从一个或两个公司占领大市场的绝大部分,然后发展到大市场被一个个细分小市场公司漫漫分解,大公司走向衰败;又过一段时间,细分领域某些小市场公司开始拥有绝对的品牌优势,进军大市场,最终重新形成一个或两个公司占领大市场,周而复始。
除了蓝海,产品面对的成本在这个时代是巨大的,因此要考虑公司的现有实力与未来的实力。未来的实力很大程度上由公司现金流这个指标去衡量——《从0到1》。
第三点:业务的服务对象是谁,即用户的需求是否大于业务的服务范围。产品的核心功能并不是公司的主要业务,公司的主要业务是包含在产品的功能范围之类的。市面上很多成功的产品几乎都是如此:苹果的iOS系统是一款成功的产品,他的业务可能只在硬件与软件商店上(未来要加上音乐板块等);谷歌搜索的核心功能是搜索,但是他业务本质其实是一个广告投放渠道商。这些核心需求并不赚钱,他们的业务盈利点仅仅是一个相关或者弱关联的地方,但是这些小业务却是整个产品的能量来源。
我们可以惊奇的发现,仅靠公司的业务是无法满足消费者的核心需求的。因此,产品经理的思考模式在笔者看来应当是:业务>功能>需求。
我们应当从业务的角度出发,去提炼核心功能,再来挖掘其中蕴含的各种需求,由此确定公司的服务对象,面对的目标人群,解决的核心需求。产品存在的价值首要是商业价值,其次才是功能与需求价值。一个好的产品一定是能赚钱的产品,否则他就没有可能成为一个真正好的产品。
挖掘需求
确立了项目之后,我们首先要做的就是挖掘需求,挖掘需求是根据公司的业务来决定的。真正的需求一定是基于现实,而不是从网上看数据以及找各种指导老师来确定,也不是全部由用户说了算。
我们从上一章可以得出一个结论,用户的核心需求中必定有一部分是我们的业务,因此在这个时候产品经理需要调研公司的业务部门,明确业务满足了用户的哪些需求,根据这些需求来推导整个产品的核心功能。
用户的需求是无法完全满足的,也就是用户的需求一定大于业务的服务范围,因此,界定这个范围要根据我们的服务以及用户真正的核心需求来确定。
举一个很简单的例子,第一辆汽车是用来替代马的,但是在当时的用户只需要一匹更快的马。其核心是快,而不是一匹快马,这就需要我们挖掘事物的基础属性。不过从辨证的角度思考,用户可能真的需要的是马,即骑马这个运动。
用户只会根据现有的东西来推测更好的东西,而不是从基本出发创造一个更能满足的东西。这也是乔布斯在初期为什么不愿意做用户调研的原因,因为用户只看到眼前的东西,不会向更深层次的东西挖掘。能够将更深层次的需求中的某个部分与我们的业务相关联,或者从我们的业务角度出发去拓展这个更深层次的需求,是两种基本的思考模式。
在解决了核心需求,我们还要思考用户还需要哪些配套需求,这些额外的需求可能就是你形成差异化的一步。
如何判断一个需求的优先级可以从三个方面来判定。
- 第一是高频。核心需求一定是高频的,一定是常用的。
- 第二是广泛度。一个核心需求不可能只针对一小部分人群,应该是大部分都需要的东西。
- 第三是不可替代性。这个核心需求是不可替代的,最好是生活中经常需要或者是在某种场景下必须用到的。
挖掘需求所要做的本质是哪些需求能够筛选出来变成功能。将需求变成功能,并从业务的角度出发,笔者认为是这个时段最重要的一件事。
市场调研
市场调研是一个比较模糊的问题,它不是做一个项目,需要前期、中期、后期的规划与执行;也不是开发一个产品,需要各个不同职能的协调互动。也许就是一个人,一个能上网的工具就能办到。
调研市场,需要知道三个数据:规模、发展、竞品。
获取市场的几种方式有:
- 企业业务部门的经验总结
- 互联网平台的调研报告
- 竞品的运营情况
笔者一直强调实践大于理论,只有从现实情况中才能提取到有用的信息。
了解市场,首先一定是从身边入手,从公司的前沿业务部门入手,最好拿到公司的销售报表或者采访公司的业务主管,他们手上有很多新鲜的数据与当前这个行业的数据,这是我们前期了解市场的基础。
网络上有很多第三方的调研机构,以及很多指数类风向标,能够一定程度上客观的(“装机量数据”)反应当前这一领域的成长与规模。
面对网上各种文章的时候,一定要分清什么是事实,什么是作者的观点。一般像互联网媒体网站:虎嗅、36kr。经验分享网站:人人都是产品经理、PMCAFF等更多的是分析阐述观点和经验,并不是客观事实。面对这些内容不要放弃自身的独立思考,也不要照搬应用。
常用的指数有:
- 百度指数(搜索方面)地址:百度指数
- 头条指数(事件方面)地址:今日头条 - 头条指数 - 首页
- asou(应用搜索方面)地址:ASOU 阿搜 - 多点科技旗下ASO数据产品, 应用试客
- 易观千帆(产品方面.付费)地址:首页-易观千帆
调研报告有:
- 易观博阅(行业方面)地址:易观-研究报告-行业分析报告-分析报告
- 腾讯移动分析(硬件方面)地址:腾讯移动分析|免费移动应用APP统计| H5统计|渠道统计|用户画像|免费移动应用APP统计| H5统计|渠道统计|用户画像|免费移动应用APP统计| H5统计|渠道统计|用户画像|免费移动应用APP统计| H5统计|渠道统计|用户画像|免费移动应用APP统计| H5统计|渠道统计|用户画像|免费移动应用APP统计| H5统计|渠道统计|用户画像|免费移动应用APP统计| H5统计|渠道统计|用户画像|免费移动应用APP统计| H5统计|渠道统计|用户画像|免费移动应用APP统计| H5统计|渠道统计|用户画像|免费移动应用APP统计| H5统计|渠道统计|用户画像
- 企鹅智酷(热点方面)地址:企鹅智酷
竞品的调研是一个长期的过程,一个优秀的竞品产品一定是一个差异化的产品。这就需要我们回避这个差异化,为自己添加标签。
定位就是在潜在顾客的心智中实现差异化,它注重心智的工作原理。——《重新定位》
每一个产品之所以有用户用它,是因为这个产品诸多特点中的某一点是不可替代的。换句话说,用户在手机里面保留这款app,是因为这个app有一个地方与众不同。
我们在分析竞品的时候,更多应该寻找它的差异化在哪里,而不是照搬理论讲一遍功能,发表一些见解,最后再提一些建议。这对我们市场的理解是没有任何帮助的。
在知道了规模、竞品、数据等硬性内容,还有一个需要特别审视的地方:当前这个市场是否站在风口。
- 15年移动支付+电商+互联网金融
- 16年移动直播+知识付费+VR
- 17年共享经济+人工智能+游戏
风口在哪里,市场就在哪里,资金就在哪里。一个市场的发展永远是一个大企业的出现被细分市场的小企业分割破灭,然后其中一些小企业脱引而出变成新的大企业,如此循环便是发展规律。
产品的规划
关键词:目标范围、功能、MVP
目标范围
我们在经历了“产品的准备”这个环节后,也就是确定了要做产品(立项),做哪方面产品(市场)这两个顶层问题,接下来需要讨论“怎样做产品”(策略)。
怎样做产品,第一步,确定目标范围。
- 谁:产品的具体是为谁服务 目标用户是不是你的业务用户,还是其中一部分?目标用户如果不是业务用户,那你需要知道他们有哪些特征,尤其是一些连他们自己都忽略的特征,这里需要一些用户调研,如果是小型公司没有条件,建议首先通过行业经验入手;如果是业务用户,不用怀疑直接去调研业务部门,数据会更详细。
- 用:产品具体有哪些核心功能 前期我们提到,核心功能很有可能不是业务功能,因此在前期产品规划阶段我们需要知道用户的核心目标是什么?通过怎样的方式解决我们之前归纳的核心需求。 同时,需要思考这一这里是列表文本群目标用户是否能够接受非认知模型情况下的功能与交互逻辑。//举一个例子:qq、微信代表广泛用户的im或sns(关于他们的定义众说纷纭)功能与交互逻辑,针对的是广泛的用户目标(虽然他们前期定位并不是);而像新时代的same(官网被黑了)、探探等,虽然同是im或sns,却因为不同目标用户群而采用新的功能与交互逻辑,这也是取决于这群用户能够接受非认知模型的情况。
- 需求 核心需求,不一定是业务需求,但两者有联系(前章已讲述挖掘方法,这里不再赘述)。
第二步,同类竞品分析
为什么要分析竞品,用处有三点:
- 矫正我们定义的核心需求:知道别人眼中的核心是什么定义,他们是通过怎样一种形式来解决这个需求的,与我们的定义是否相似。
- 明确当前用户的认知模型是怎样的:认知代表两个方面,一方面是交互操作逻辑,用于我们具体设计功能实用步骤;另一方面是产品在用户心中的映像,用于我们为我们自己的产品找到定位(可参我的专栏文章:《定位》x《重新定位》x 产品 - 知乎专栏)
- 确定差异化:不管是产品还是品牌,需要做到的就是差异化。只有差异化,敌无我有,才能拥有存在的价值。我们分析竞品的核心目的就是这点。
第三步,需求范围
前面两步得到的结论,就是我们的需求范围。
它包括:目标用户的范围、核心需求的范围、基本功能的范围、交互认知的选择、产品的差异化范围。在规划的初期,这些最核心的资料需要形成文字整理成文档,用于今后的需求增加与功能迭代的衡量依据。在一个产品生命周期中,最大的失败就是越过产品的范围,特别是在运营加入之后······
需求转化为功能
功能的确定需要判断两个方面:
- 业务需求第一阶段需要涉及吗
- 用户的核心需求是什么
前文我们已经论述过,产品的业务需求应当包含在用户需求之中,而不是包含在用户的核心需求里。因此,大部分产品在产品前期是不涉及业务的,也就是一个产品的初期可能没有任何盈利模式,最好的情况是拥有一些小的广告位。这里建议在产品初期不要直接涉及业务功能,而是先规划能够容纳业务的板块。
比如常见的“发现栏”,用于功能扩展。举例:喜马拉雅FM、微信、知乎等
另一部分,业务需求涉及到产品的属性:工具还是平台
工具类 app 除了上面所说的”发现栏”,另一种盈利模式是通过付费解锁更棒的功能,比如常见的:泼辣修图、网易云音乐等。这一类 app 往往拥有一定的精准目标客户或特殊功能(核心需求就是业务),为了给用户提供更好的服务因此采用收费提升品质。面对工具类 app ,业务需求的功能可以在产品设计初期就一起规划,通过迭代开发逐步进入付费升级模式。
平台类 app 能够自己生产或整合渠道资源。这一类 app 往往一开始就需要业务模式提供支持。平台的核心是流量,流量大业务自然有,产品本生就是一个业务。
用户的核心需求直接决定产品的功能。这里需要采用一种名为“MVP”的方法。
“MVP” 方法出现在《精益创业》中,是一种广泛的产品检验方法,其基本意义是:开发团队通过提供最小化可行产品获取用户反馈,并在这个最小化可行产品上持续迭代。
这个方法对我们产品有两个启示:
- 小成本检验产品
- 产品是逐步完善的
我们在确定核心功能时可以通过这个法则来检验用户的核心需求,即不管用哪种形式(甚至视频或者手绘)制作 demo 然后投入用户中获得反馈,来矫正我们对核心需求的把握。但是这种模式存在一个问题,创业公司或者资源不够的公司无法获得足够的样本来检验产品,怎么办?借助其他平台。不理解电商就去其他平台开一个电商,不理解内容需求就去自建一个公众号来挖掘内容,不理解社区就去各大论坛参与体验。
“MVP”的小成本是一个广泛的概念,不单单是指产品的表达形式,更指获得用户反馈的成本控制。
产品是不完美的,也不会完美,这是一个过程。我们在研究前端产品的时候更需要规划后端配套产品,这是双向的。每一个前端的功能必定对应一个后端的操作模块,前端的功能驱动后端的迭代,这是在产品需求转化为功能时期容易被忽略的问题。从某种意义上说,前端的产品用户与竞争者都能看到,而后台才是真正的知识产权。
产品的设计
关键词:原型、交互、UI
原型设计
如果说前期的准备与规划都是“纸上谈兵的话”,那么“原型设计阶段”才是产品经理真正进入“实践”的第一步。
工欲善其事,必先利其器。用什么软件画原型?
答案是随意。
你喜欢什么?会用什么?程序员与设计师会看什么?可以从这三个方面去选择。
用纸质,考验人们的想象力,不太推荐。用你效率最高、他们接受度最高的方式才是最好的。笔者之前见过用execl表达原型的,一样能做出很好的产品。所以,放下所谓的axure教学培训,放下所谓的动效精进班,用文字能够清晰表达的就不要用复杂的动画,浪费时间。
原型设计的目的,是为了检验我们的功能与逻辑。
如果这个时候还会对需求和功能之间的转换摇摆不定,建议重新走一遍之前的流程。既然已经到了原型阶段,产品的核心功能是不能轻易动摇的。
我的习惯,是从用户打开app的第一个界面开始入手,建立一套完整的使用流程,当然也可以从核心功能的界面入手。我们的大脑里要时刻提醒自己是一个小白用户,也就是我只用过一些主流必须使用的app,没接触过其他东西,我的使用方式只有简单的点和滑动,甚至连滑动都没有。我只对界面上最显眼的东西感兴趣,我的注意力只集中在中间和左上角,我只考虑我下一步要去哪,并且这个过程不会让我点击超过三次。用这些标准来判断我的界面逻辑是不是合理,是不是符合用户的认知模型,是一个非常有趣的事情。
这样一个过程下来,你手上就会有一个初步简单的原型设计图啦。它可能只有5到6个界面,可能不需要登陆,没有什么文字或者全部是字,可能只有一个核心功能,比如播放app就是一个播放页面而已。
下一步,开始扩展这些页面,可以从这几个方面去考虑。
- 我要完成这个核心功能,还需要其他什么辅助功能吗?(如播放列表,上一曲,下一曲,进度条,暂停等)
- 我需要知道哪些必要的信息来帮助我使用功能?(歌名,收藏歌曲,上次播放位置,歌词,作者等)
- 我要重复使用这个功能,还需要知道哪些?(歌曲推荐,歌单,搜索,上新等)
- 贴心的小设置?(操作环境,功能自定义,安全隐私等)
扩展页面的思维,是一个不断发散与不断收拢的思维。我们可以无穷举例日常中常见的该功能,然后给他们一一做验证,最后筛选收拢成几个次级必要的添加。当然还有很重要的一部分是通过竞品建立的一套认知模型规则来设计,这是大部分中小公司很实际的做法。
核心思维还是遵照之前MVP方法论,用最小的成本让用户一步到位得到需要的功能。前期不太推荐建立新的认知模型,也就是使用不同的交互使用方式,这样只会在验证可行性时增加没有必要的成本。
第三步,建立规则。
规则就是标注,就是对页面的隐藏说明。这个时候不要纠结文字显示多少行,也不要纠结列表一个分页显示多少内容,用户对于这些细节的体察几乎是微乎其微,他们只会感受你给他们建立的这套规则而不是你去研究他们想要的规则,也就是他们只会使用你给她们带来的用法而不是去他们主动去思考还有没有更好的用法,这是前期与其他成员交换意见时最需要了解的一个原则。
如果规则制定不人性,用户自然会从数据上反馈,而不是质疑这个规则该不该在这里建立。比如一个列表结构的界面,你设定10个项目做上拉刷新和设定13个项目做上拉刷新这件事,在用户看来完全无关痛痒。
前期就开始建立规则,是一件比较明智的事情。他不会让你在程序开发时碰到问题临时被打个措手不及,提前把每一个数字、展示、跳转、反馈做好规定,然后结合后面视觉专业设计与程序实际开发两个现实层面做反复优化,最终交给用户去检验。
这里总结三个容易遗忘的必要功能(toc):
- 用户系统(个人页面,收藏,关注等)
- 反垃圾系统(关键词屏蔽,评论,搜索过滤等)
- 付费系统(时刻给这个功能留扩展入口)
最后一个问题,prd文档写不写?
写,检验这一套产品逻辑还有哪些漏洞。
不写,程序员几乎不会看,设计师也几乎不会看(小型团队,面对面沟通更高效)。
所以个人建议,项目边推进边写吧…..
交互设计
交互设计与原型设计是相互穿插的,甚至在需求与功能明确的情况下,原型设计主要主要就是设计交互这一块。
什么是交互
文艺一点的说法是:让“机器”不再冰冷,让人更容易操控“机器”;通俗的讲:交互就是让产品从能用达到易用,最后变成好用的这样一个过程。
用户体验的要素从四个方面提出:
- 战略层:用户需求,产品目标
- 范围层:功能范围
- 结构层:交互设计
- 框架层:同样是交互设计
- 表现层:视觉设计
这是一个教课书般的结构,可以看出从概念到实现环节较重要的是交互设计,不过绝大多数的公司是没有交互设计这个岗位的,大部分由视觉设计或产品经理代替。
交互设计的环节主要设计这几个方面:
- 信息结构:包括层级关系,空间分布,关注点
- 反馈,触发器:这里涉及微交互知识,是交互设计的入门。
- 界面设计:用户认知操作习惯等,涉及跳转、导航、功能使用安排。
- 需求满足:业务需求与用户需求的权衡。
这里建议遵照MVP法则,只做最基础的设计。特别是信息结构环节,意在呈现用户希望看到的。
什么是用户希望看到的,检验的标准只有一个:能够帮助用户提升效率,更快决定行为的信息便是用户希望看到的。这里其实是两条标准,对于工具性产品注重效率,信息性产品注重展示。
举一个例子:
如图所示分为三个页面——“节目”、“下载中”、“专辑“。
这个业务流程可以简单变成:用户点击下载——节目最先出现在”下载中“,状态表示已在下载——下载成功,节目跳转到”节目“列表中——下载完成。
我们拆解基本需求来理清整个思路:
- 用户的需求是:将节目下载至手机,根本是解决无网络环境下的播放问题(弱网无网情况下的使用问题另提需求)
- 用户需要的功能是:下载
- 交互要考虑的问题是:强调节目正在下载,方便用户播放(产生下载后的列表),替用户善后(听完后删除节目,给下次功能使用创造条件)
- 强调的信息有:下载状态,下载完成状态,可播放状态,可删除状态,删除完成状态
最直接分解用户的行为流程,提取关键节点,围绕其展开信息分布,尊重人类自上而下、从左到右的感知习惯,可以按照这一个流程来做每一个页面的信息结构。
微交互触发器理论可查看下图:
平衡用户需求与业务需求是交互设计最重要的一个环节。业务需求基本由产品经理在前期“产品的准备”提出,而用户需求需要产品经理与交互设计师共同整理。
衡量交互的用户需求可以从以下几个方面展开:
- 目标用户的行为特征(比如老年人对颜色感知,字体大小的要求;女性用户对圆润的潜意识喜好等)
- 用户使用的场景(弱网、单手、户外、音频输出等环境,使用是否存在以及匹配等)
- 用户行为(按钮的点击,滚动标签的左右滑动等)
- 用户体验的目标只有一个,简单高效的完成功能
交互设计结束后,会经历几个方面的评审工作。
功能是否表达完整,是否有不合理的跳转;页面数量是否超过了开发预算成本,是否适合目标用户;很多情况下,甚至会将交互稿件直接拿给一些目标用户,让他们无引导体验 各个页面的操作。
对于交互设计师而言,以上的内容只能是笔者拙见的一些归纳,算是不完整基础中的基础。交互最开始是从工业产品中萌芽发展的,这一点可以参考名著《设计心理学》。不过笔者个人认为这四本书都不太值得看,不如看一看国人自己总结的《破茧成蝶—用户体验设计师的成长之路》以及《交互设计那些事儿》,更加直接易懂不啰嗦。
对于产品经理而言,知道以上基本的常识已经完全足够了。在工作中,产品经理除了展现自己在专业领域的能力之外,还要推动项目进程、协作沟通的任务,因此在能够保障业务需求与用户需求的前提下,产品经理最好充分信任交互设计师的方案,肯定其价值与贡献。
视觉设计(UI)
过去很长一段时间,我们定义的用户体验很大一部分就是指视觉设计(UI)的优良,这里笔者理解有三个方面去考量:
- 界面的美观度:是否符合目标用户的审美需求
- 界面的易用度:功能性的视觉是否有效表达
- 界面的友好度:用户浏览获取信息是否顺畅
互联网发展,用户体验增加了“用户认知“、”操作流程”、“服务设计”等更为广泛的概念。当然以笔者中小型创业公司的经验,我们这里只会分享视觉设计这个方面,这也是受资源限制与开发时间成本等关系的影响,用户体验约等于视觉设计。
视觉基本法则
视觉设计的知识对产品来讲,基本只需要了解一个原则:格式塔原则。
- 接近原则:越近越像一个整体,给用户合理提示顺序同时提供视觉休憩,划分了各个内容的区别或并列、延续等。
- 简单原则:复杂让人思考,给用户简单的图形能让他更好的理解。
- 相似原则:共同特性相互组合,给用户区分各个区域的表达和关系。
- 背景原则:色彩对比容易突出色块中的目标,给用户一定的舒适感。
- 闭合原则:不连贯的物体心理补充为一个整体,吸引用户视觉停留产生兴趣。
- 共同区域原则:在封闭区域里的物体更容易想成一个整体,协助用户区分各个板块,我们常见的做法是加入细细的分割线或者框。
- 连续原则:实际不连续但是心理补充为连续,最好案例就是轮播图。
了解这些基本法则,产品经理才能明白设计师为什么要这样而不是那样,才能根据这些原理提出自己的建议。
视觉设计的核心功能是让产品从能用变成易用:基本的一致性能够给产品带来统一感;清晰表达能够减少用户思考与影响从而提升效率,让功能有效操作。这两点比美观度还要重要,需要在设计评审会上注意。
最后还是要多说一句,在审美问题上产品经理应该充分尊重设计师的劳动成果,给予一定的信任与支持,这样会减少很多沟通问题。
产品的开发
关键词:坑、优先级、前后端
兼职角色
正常职责下的产品经理,可能不太需要关注开发技术等问题,只需在功能评审会让技术总监评估一下实现的可能性与开发安排周期等问题即可。
但是,现实是很多公司并没有技术总监这个职务,即使有也可能是公司的合伙人,也就是他并不会特别花心思在这一块。这就牵扯出一个问题,产品经理需不需要懂技术?不用争论,除非你在大公司,否则你必须懂!
那么既然必须懂,懂到什么程度又是一个问题。这要取决于你使用的技术与程序员的水平,这是一个十分微妙的情况,因为有时候程序员甚至要问你这个逻辑怎么判断,前端是写“死”(跟随安装包变化而变化),还是写“活”(后台控制,接口控制)。甚至你在挖掘功能上,还要考虑前后端的数据是怎么调用,需要返回哪些值。这些内容要比写prd更加繁琐和复杂!
因此,在这里还是建议在应聘产品经理职务时,一定要看一看这个公司是否有技术大牛,是否有3年以上开发程序的同事。当然,没有也不要丧失信心,能够在开发中学会一些技术常识甚至是一门语言,是非常增加竞争力的一件事。
兼职“技术总监”的一些体会:
- 非核心功能实现不了一定打掉,可以放在后期迭代中研究
- 功能体验差,可以先选择关闭接口隐藏,避免负优化
- 前端数据尽量写活,可以后端控制
- 一定要把不同场景下的逻辑纳入开发中
- 有问题发帖,晒代码,进群
- 程序员说这里“逻辑很多”实际是说他不想做,陪他加班
- 短信服务费钱够不够,服务器升不升级,带宽需不需要cdn
前面说到非正常职责,充当半个“技术总监”是其一,其二还需要当一个“非专业”的测试。
由于前期并没有投入运营,功能bug等细节问题需要测试,这个测试也只能是产品经理,因为你要对产品负责,这个负责的概念是这样的:“程序员实现不了是产品前期没有评估好,程序员写了bug没发现是产品没测试好,测试出来了没更改就上架是产品的责任。”调整心态,勇于背锅,你不仅自己能成长,也能得到程序员们的尊重与配合。
兼职“测试”的一些体会:
- 用例可以不写,但是以前老问题改好之后的若干版本还是要试一试
- 时刻思考网络环境切换情况下的产品功能
- 站在产品的角度下,非非常用功能的bug可以选择性“忽略”
- deadline,上线优先
坑的问题
笔者一直认为,视觉设计是最没有坑的一个岗位,因为已经足够专业与接地气。而产品开发,则是坑的开始。
产品的坑:
- 用户的心智和我们前期调研的不一样,改需求,上线时间不变
- 程序员答应却实现不了,功能不全
- 运营策略变化,功能先放一放,我们先改版
程序的坑:
- 没有模块,因为用的js,还没提供
- 实现不了,因为官方有bug,反馈要等时间
- 来不及了,明天要上线还要测试
这里只是简单举例一些常见问题,一般发生在中小型公司,因为大企业的决策和审查十分严谨,资源也比较丰富,因此能够从源头避免很多问题。
产品经理在面对资源紧张、排期紧、程序开发难度高、需求变更等问题,可以用以下思路解决:
首先要明白当前问题的根本问题是什么,如需求变更的原因是什么?功能并不能代表需求,在保证核心功能的前提下,需求可以延期往后排,这需要产品经理能够有理有据的协调需求方和开发人员,保证项目的良好驱动。
比如:首页改版这一类的展示需求变更,可以放在之后一个恰当的时间点再更改(节假日等),给开发人员一定的缓冲时期,这也考验了产品经理的综合能力(懂运营、懂营销)。 首页的改动,一方面是业务驱动,一方面是用户认知的驱动,除了需求提交的流程优化外(排期足够,提前协调),还要思考为什么上一个版本没能做好展示体验?这需要产品经理分析用户认知习惯,总结方法和经验,避免下一次还会碰到同类问题(随着用户量的扩大与用户认知的不断引导提升,改版问题是每一个产品迭代都必须面对也不得不一直执行的问题,同时也是提升用户体验的好方法)。
这是一个遇到问题、解决或延迟或变相解决问题、总结问题的自我反思过程。
产品的开发是验收、迭代、妥协、再开发、再验收的过程,不能盲目对标竞品增加新功能,核心功能才是优化目标。
产品的运营
关键词:用户运营、内容运营
产品好不好取决于一个好的运营。产品功能的同质化,功能的完善度在这个时代几乎就是一个“模版”,唯一要与竞品抗争的,除了差异化的特殊功能之外,几乎都在运营方面。
因此,成为产品经理之前,我们应该是一个好的运营。
运营的工作内容很多,理论系统在市面上很少见到比较全面的总结。产品运营的工作不好去评估,有时一些繁重的工作量几乎无法量化效果,但是这些工作又是必不可少的。它大概可以分为四个方面的具体工作:用户运营、内容运营、社区运营、推广运营。作为一名产品经理,笔者建议最基本知晓“用户运营”与“内容运营”的工作。
如何界定产品运营,这里引用《超级运营术》中比较权威的解释:
产品运营是通过用户、内容、品牌等运营方式,将用户和产品更好地链接,从而达到产品的最终目的。运营的价值包括传递产品价值、打造产品生态和创造玩法。
用户运营
- 什么是用户运营?
笔者认为,用户运营就是对用户的引导,让用户能够在产品里保持活跃,长期使用产品的工作事项。它包括:
- 用户社群地建立,可能是种子用户的交流群、也可能是产品反馈群等其他目的的群,总之是一种促进产品到用户的对话渠道与服务。
- 激励活动地开展,可能是针对某个阶段的用户,如新增用户的福利;也可能是对老用户的贡献回馈,正向刺激内容的更新,总之是在产品内有生态循环,在产品外有新血液注入。
- 产品理念地传播,作为直接接触用户的一个渠道,用户运营就好比产品的官方发言人与品牌推广员,通过沟通宣讲等一系列手段传播产品价值,甚至在回答用户的问题时都有文字优化。
也许在产品看来,运营一天泡在各种用户群里左一句右一句的和用户互动,看不出什么成绩,但是实际上这也是用户运营的工作内容之一,并且这种无法量化的工作能够引导用户更好的使用产品,提升留存与活跃度。产品初期的种子用户冷启动阶段,不就是”集中运营“逐个培养交流的吗?
内容运营
- 什么是内容运营?
笔者认为,内容运营就是生产或引导用户生产内容来满足用户的内容消费需求。像今日头条这种把内容变成核心需求,工具外的内容增值本身就是一个工具,可见内容消费是属于基础需求的。
内容需求除了本身满足用户内容的消费需求,还能够传播产品的理念和生态氛围。比如母婴女性向的内容,除了内容是女性话题,还可以从标题的设置、图片的选择,甚至是重点信息标注颜色上做细节处理,强化产品这一特点,形成良好体验。因此,内容运营除了内容上的质量需要把关,还应该做更细致的精细化运营,这一点是形成产品差异化、产品良好口碑的必要因素之一。
17年的工作经验就写到这里,明年继续。
最后总结一下我认知的产品思维:
- 需求为导向
- 业务与体验并重
- 功能解决一切问题
(完)