【起点精选】作为产品经理,你可能会忽视哪些实际上很重要的“小事”?

作者:地球科学    来源:未知    发布时间:2019-12-18 21:49    浏览量:

也许对接文档可以让对接方先准备起来;

产品部门工作手册截图

在大前提他们的需求合理的情况下,你是直接根据他们的做了呢?还是多多向他们请教一下呢?

产品从0到1,最需要判断力和执行力

对其他和你合作的人以及他所在的岗位有更深入的了解;

我深知自己的专业度是不够的,所以决定从两个方面来建立新流程,一是基于团队成员以往的工作习惯,二是参考目前常用的开发流程,当然,根据我们的实际情况,会有一些调整。

不同的人,都会站在不同的立场、出于不同的目的,向你提需求或者反馈意见。

产品经理要做什么,具体怎么做,那个时候我都不清楚,我唯一知道的是,整个产品是由我来负责的,有一句话说,明白许多道理但还是做不好自己,足以形容这种窘境。

从历史中了解变迁,有助于需求的管理;

你可以不看书,但是你不能不学习

对于个人,是一种素质的提升。

1.产品调研

有重点,但是都是头脑风暴

作为一个自认有产品经理坚持的人,我始终相信产品内在的自发传播性,也就是说真正的好产品一定能在某个人群中找到它的存在价值。但是在现实中我也常常见到过很多内在品质不错的产品,但是奇怪的是身边都没有人在使用它们甚至不知道它们。这也是为什么这个命题会存在,如果产品不好,运营工作很难开展,如果运营不好,产品就很难找到用户,也很难存活下来,这叫“酒香也怕巷子深”。

刚进公司的时候,我发现公司里居然么有产品文档可以共享。了解产品基本靠多使用;要修改某个功能,基本靠经手人的记忆力。

对从0到1的产品来说,其实“活下来”是件比啥都重要的事情,这就决定了在产品设计之初,切入需求的时候,就得充分考虑产品存活难度,过度依赖运营规模的产品,其实严格来说不太适合资源不多的小团队来做。所以,认准一个核心需求点,排除万难,顺便排除掉一些不切实际的想法,从产品的角度考虑问题,还得从运营能力的角度来评估,这也是为什么产品经理不是一个所有人都能做的岗位。因为你不仅仅是一个产品经理,你还得是一个运营,因为如果连你自己都没有办法做好运营的话,也请不要指望其他高人能帮你把这件事想清楚,你的产品,没有人也不应该有人比你更清楚。

从数据结果可以看出balabalaba……

“这是个挑战,但是这种掌控不了的事情,听起来还不错”。我立刻就答应了,生怕老板反悔。

当然,我并不是鼓励不遵守制度,而是说要灵活的遵守制度。毕竟,情况是复杂滴,人是活滴。

转折点出现在2015年初,公司渐入佳境,准备要做一个APP产品,所以就开始满世界找合适的产品经理。如果大家有经历过,就应该知道一个又靠谱又便宜的产品经理有多难找,招人的工作非常难以进行,最后老板想了想,任性地决定让我顶这个缺。其实也不能说找我顶缺是件完全没有根据的事情,因为我大学是学计算机专业的,12年的时候有去实习写C++,14年初又去实习过需求分析师,不管怎么样,整个团队里,我的过往经历和产品经理的属性相对是最匹配的。

……

产品开发验收上线后,有一个特别考验产品功力的就是数据分析了,做数据分析肯定得要有数据来源。有的团队会自己在产品开发过程中就埋下一些监测点,建立数据模型,通过后台来观察。我们的情况是产品正常开发周期都已十分紧张,所以干脆接入了“友盟”来协助开发埋点和生成数据报表,好处是开发成本小且可视化效果好,缺陷是有时候不够准确(这是统计规则不同的原因)。

老板觉得要提前做某个需求,不要只把自己放在执行的位置,要多想想为什么这么做,对公司有什么好处,公司最近有什么变动,如果想不明白,可以尝试问问看;

如果你还没有准备好,请不要勉强答应

没错,头脑风暴是好的,但是同一件事,如果每次开会都是头脑风暴形式的,那么是非常让人心烦的。

不久前,我在日记本里记下这句话来鼓舞自己,从2015年开始到2016年底,为了实现产品从0到1,我几乎爬过了数不胜数的坑。我把它们记录下来,希望同行看到后引以为鉴,也希望能够从这些经历中总结出一套普适性强一些的方法论来。

长久,大家会更有团队的感觉。

6.产品功能开发

4、执行想法成功落地本身比想法更重要

由于外包团队在西安,而我在上海,很多时候沟通成了一个最大的问题,我往往很担心我提出来的改进到底执行了没有,到了哪个地步。一开始我会以一天一更新的方式来要求开发团队每天生成一个测试包发给我,但是很快发现一个问题,就是问题太多根本改不完,我加入的时候交付时间就已经非常紧张。有经验的产品经理其实已经看明白,这个其实就是需求管理,我们需要从数不清的坑中选一个最致命的来填。稍微明确了下现状后,我调整了一下沟通方式,每天晚上我会拿到最新的测试安装包,然后赶紧测试,测试结果写成excel表格,我暂时叫作buglist,这就是我的第一个需求管理文档了。我在buglist中规定了几个简单规则:1.写清楚bug;2.标明bug的优先级;3.规定交付截止日期。远方的开发团队拿到我这张buglist后,可以按照他们的分工来分别解决问题,每天交付给我的安装包,修复情况也是按照交付截止日期里的规定来执行的。这里面有一个无法被避免的问题,那就是有很多bug,我明明确确地知道,是无法在规定时间内修改完的,能做的只有砍掉它们,心无旁骛,把最核心的事情做好。

个人思维方面1、不要害怕变化

接下来做的这件事情,我认为非常重要,那就是做排期计划。

……

5.技术方案设计&排期

很多产品经理很唾弃产品之间相互借鉴这件事,不管三七二十一,看你产品长的差不多就说你像素级抄袭,这其实是很呆逼的行为。(电商都长一样,你能说他们抄袭吗?)

4.UI效果图验收

……

这里没办法和大家详细介绍每一个流程中的工作细节,因为那是因人而异各有所长的,就不在此献丑了,想给大家分享的一点是我们实际工作中的沟通方式。前面图中其实可以看到,产品定下需求后会出一个原型,务必强调核心功能点和逻辑合理性,画原型的工具有很多,一一尝试后我还是选择使用老牌的axure作为主要的工具(原因后面会讲到)。然后就是拉着技术和设计来开会讲解需求,我一直相信专业的UI和技术在很多时候可以给到很好的建议来避免一些坑,这个会开完以后,技术(后端/前端)基本上可以理解需求中涉及到的数据逻辑,而设计也可以明确原型背后的实际需求。

经常在各种地方看到产品人在各种吐槽,例如:

2.产品立项&原型

对整体产品好、对团队成员好;

大数据是现在非常火的话题,学习了以后,我也想来分享下我的思考,我构思的下一个想写的话题,就是和数据有关的。本文中提到的所有文档和工具,我这里都有存放,有需要的朋友可以在评论中留下你们的邮箱,无偿共享给大家。

这些都是宝贵的各个角度的实践知识啊,都是需要看专业书才有可能看到的东西或者有可能连书里都没有。现在,你通过一个个需求,就慢慢都了解了,这么一个大好的补充各方面知识的机会摆在你面前,怎么能浪费呢?

与此同时,我会着手撰写产品需求文档,将包括页面交互,全局变量,用例图,排期等都写到文档中以便团队成员共享。很多人喜欢用word来写需求文档,但是鉴于个人的使用习惯,我还是会用axure来写文档,一来方便共享和修改,二来也便于将前面画的原型直接写进来,大家就不需要存很多文档了,前前后后只用到这一个。使用axure画产品需求文档的方法比较多,也不在此多做介绍了,大家嫌麻烦的话可以直接找我要模板。

跨界的借鉴从行业上来说更具有意义。

7.测试

2、多和团队伙伴沟通业务

这段经历使得我一直认为,产品经理更多时候是一个承担责任的人,想要担得起这个责任,抛开专业性不说,判断力和执行力是最重要的。

4、产品材料一定要文字留档

“我之所以还能够对未来充满信心,是因为我相信从0到1是一件尽管艰难但是有意义的事情!”

举个例子,这个版本的需求都已经确定,版本上线时间也已经确定了。但是,运营和投放因为某种原因,要在下个版本做一波大活动和投放,需要产品这边配合开发一些东西,这个时候怎么办?

小团队,所有工种就坐在离你不超过5米的范围内,沟通基本靠吼,尽管如此,也还是得有自己的章程。为了方便大家理解,特地把我之前写的产品部门工作手册截图展示下。

尽量把对接控制在可控制的范围内,而不是任由发展。

9.发布上线

本文原创发布于人人都是产品经理,未经许可,不得转载。

接下来我面临的尴尬境地就是,居然没有人可以指导我如何做产品。那个时候的产品开发是交给一个外包团队进行的,因此也没有开发人员可以来告诉我他们目前的项目进度。最可怕的事情是作为产品的负责人,一开始很多时候我对自己下的决定都表现出一种不肯定和不自信,身份的转变也并不能让我迅速适应这种转变带来的一系列其他影响。一个基础为0的产品经理和一个基础为0的团队以及一个基础为0的产品,我想这也是非常少见的吧。

如果仅从产品岗位考虑问题的话,会觉得这个太临时了。如果应承下来做的话,不但要临时给自己增加工作量,还需要和设计师们、开发们重新沟通时间、调整计划。他们也可能因为临时的工作量而导致一些负面情绪的出现,你还得理性/感性的进行安抚。

技术这边,前后端的同事会分别按照需求提到的功能点做任务拆分和时间排期,这是负责后端的同事带来的方法,叫做时间片管理。把需求中的功能点尽可能拆分成一个个任务片段,给每个任务片段分配时间(story),一个story差不多是2个小时。开发的同事可以按照story来分配自己的工作时间,平均1天可以完成3~4个story是比较合理的速度。有了这个方法,所有人都可以量化自己的工作成果,做出来的排期也相对比较合理。

一个简单的功能,代码狗们都搞不清逻辑,实在是太弱了;

我开始后悔接下这个活儿,但是这个自己给自己挖下的坑,含着泪也得往下跳啊。

你用这种对立的心态去看待你的伙伴、你的组员,那么你和大家的关系怎么会好呢?人家跟你关系不好,更是不可能愉快的共事啦。

身为产品要重视结果,但是身为经理要重视流程

伙伴们能够在愉快、相互尊重的气氛中工作;

于是我们马不停蹄地开始对产品进行迭代,因为之前赶进度我砍掉了许多需求,现在我认为总算可以把这些缺憾弥补起来。我把我的想法和老板沟通后他表示同意,但是在和开发团队进行沟通时我却遇到了一些麻烦,因为团队刚组建,我们的很多工作都还是基于各自以往的经验,在相互沟通的过程中总有尴尬和不到位的地方。正是因为这些零零碎碎的磕磕碰碰,让我原以为可以很快执行好的需求,总是遇到延期和执行不下去的问题。

虽然不需要那么有节操,但是底线还是要有的。违法乱纪相关的事情还是不能做滴,这个就不多加赘述了。

预告:我们和数据的不解之缘

5、需求要对接完整

篇幅有限,所以简单介绍下流程:

我个人认为的最重要的四个素质:沟通能力、业务能力、理性思维、逻辑思维;

产品如期上线,当然问题还是很多但有了喘息之机。经过前面的项目外包经历,老板也意识到,如果真的想要好好做一个产品,不能依赖于外包团队,所以开始自己招开发团队。几个月内我们组建了一个集UI/产品/IOS开发/安卓开发/后台开发为一体的小团队,可以说是麻雀虽小五脏俱全。

可能因为开发实现某个相关功能的时候,实现方式的不同,导致连带影响到数据偏高或者偏低,从而出错;

10.数据跟踪&迭代

这样是非常传统并且不科学的方法。一旦出现经手人离职的情况,接手人分分钟懵逼,说不定得让开发们找对应的代码才能仅仅解决了解概况这个问题。

UI这边会按照低保真原型(如果团队有UI的话,尽量不要做高保真的原型,这样会限制UI的发挥)来出效果图,每个设计师习惯用的工具都不一样,photoshop和sketch都是不错的工具,其中sketch的使用门槛比较低,我建议产品经理也可以学习一下。一般来说,UI同学花1~2周的时间就可以完成一套完整的UI效果图。

2、要把锅背起来

2014年8月,我来到现在的公司,以实习生的身份,公司成立刚好4个月。初来乍到,我的工作任务是打杂,没错,哪里需要我,我就去哪里。客服,项目助理,运营人员等等,3个月内,我基本上把公司里所有的能接触的活儿都做了一圈(那会儿体力真好)。当时还没有毕业,觉得自己是有无限可能性的,职业规划这个事情,那个时候是没有什么概念的。

这么做的好处:

所以,如果你正在做一个产品从0到1的部署,我会诚挚地给一个建议:无论排期计划是多么紧张,无论人手有多么的不足,也请先将产品运营规划考虑到整个版图中,因为在大多数情况下,找到你的用户并用一个点子吸引他们,比完成你的产品更重要。

3、看数据结果前,辩证数据的真伪

3.UI设计&交互设计

对接完成的时间相对可控一些,从而计划好的上线时间也相对可控一些。

8.产品打磨&验收

个人学会承担也是一种极大的成长。

到底是产品成就运营,还是运营成就产品

对个人发展比较好,不断的锻炼自己的全局观思维。

最后说一点,是关于产品经理的自我修养。大家都知道产品经理这个职业,属于自己个人的时间真的非常少,很闲的产品经理严格来说是不够称职的,因为一个产品要操心的事情真的很多。尽管如此,我希望大家可以养成不断学习的好习惯并将此作为自己职业生涯的技能之一。学习能力,很多人有,但是自我约束力大部分人没有,而产品经理如果不能很好的和时代潮流,市场环境保持一致甚至领先的步调的话,很快就会被其他更会学习的人超越。学习的方式,很多人都说要看书,我现在也开始恶补许多,是为了强化自己的系统性,但是从实用性来考虑,网上也还有许多碎片化的知识,善于归纳总结筛选信息的同行们也可以在网上找到适合自己的学习方法,互联网产品经理这个职业出现并不算久,很多东西也没有非常标准化,希望大家能够共同进步,思考,分享。

大家都是成年人了,也不要太执着于自己的爱豆是乔布斯了,并不是人人都可以是乔布斯。

这是个非常非常非常重要的事情,请一定要记住。

更容易得出真实的数据结果。

产品人要端正几个态度,那就是:

和你合作的开发们会比较舒服一些;

当然,我也清楚,不是所有的开发们、设计们都对为什么要做这个需求有兴趣,但是如果连懂都不懂,你怎么指望大家设计、开发出你想要的东西呢?

不要不看重想法,但也不要把想法看的太重。真正创意意义上的想法,我认为注定是少数。而绝大部分的产品经理,你要清楚,你也许是暂时没有这个能力的。

这都快成为一种口头禅了。

5、节操不要太高,但底线一定要有

这个时候,你该怎么办呢?

想让别人尊重你的前提是,你得尊重别人。

基于前2点好处,相互之间的沟通会越来越顺利;

也许要配置的接口可以让对方先设置起来;

不要把运营、投放、商务、老板等人当做只会提需求的臭傻逼。

有时候,能看到产品人抱怨他们的团队成员。比如,我们组里的人都不关心需求、他们只知道做,做了又做错,真是无语。

有些产品觉得既然是技术对接,那么所有的事情就都可以等技术对接的时候再去做咯,然后就把所有的东西都丢给技术了。但实际上真是这样吗?

不妨在每个版本沟通需求的时候,顺便把每个需求这么做的原因也和他们沟通一下,不管是从数据分析结果、用户反馈,还是公司高层出于战略考虑,都可以说一说。

越是工作到后面,越是讨厌开会,有时候甚至讨厌小撮人的讨论。为什么呢?

觉得这个问题很有意思,所以,这篇文章就根据我的角度来尝试回答一下这个问题。

我其实理解很多人会因为个人原因去拒绝这种变化,大家都是人,怎么会不明白呢?

如果上线后程序有大bug了、某个功能被用户骂死了等等,产品经理都要学会去负起责任,如果负不了责任,那么至少要先把锅背起来。

也许测试环境可以让对方先搭起来;

不同人有不同的选择,但是出于对产品的考虑,是不是选择前者更为好呢?

再举个例子,一些小白产品们总是会纠结在一个公司里,到底产品更重要还是运营更重要的问题。总觉得公司重视运营,不重视自己,从而很难过。

在之后的需求时间预估和项目排期上会更加有把握一些。

想出来了,那之后呢?总要执行的吧。如果执行不了,那么你的想法就等于什么也不是。(当然,这里排除光靠想法去融资的,毕竟你的执行就是找到了人替你的想法买单)

不要把设计师们、开发们、测试们当做实现需求的机器;

一上线就bug反馈papapa,崩溃率papapa,用户差评papapa,这真是你要看到的结果吗?

偏重问题,只是量的问题,并不是质的程度。考虑怎么对产品好,这才是最需要纠结的问题。

本文作者尝试按照不同方面来列列看,到底有哪些事情是产品经理认为同样很重要,但是可能其他人不这么认为的”小事儿”。

而其中最重要的是,产品的增删演变历史以及对应的需求文档。

#专栏作家#

但是我要告诉你,如果数据本身就是错的,那么你所谓的数据结果就是个无稽之谈。

要端正自己的态度,不要出问题就赖开发码太多bug了、测试不给力什么的,毕竟,你才是最终决定上不上线的人。

设计们出设计稿给你的时候,不要一味着收到稿子完事了,多和设计们讨论和请教一下,为什么这么做的原因;

6、要做好准备再拉人开会/讨论

毕竟,我还是坚信,基于理解基础上的需求实现,从长远上看比较“安全”。

今天在知乎里看到一个问题:

如果正向的解释你看不懂,那就从反向想一想:目前这个互联网上,有什么产品功能或者产品形态是真正意义上没人做的吗?如果真的没有,那么你赶紧拉帮人去创业吧。

这么做的好处:

这样做的好处:

借鉴什么功能、适合用什么形态来展现,这些都是需要根据不同产品的特色去选择的、去体会的。即使是借鉴,也是做了大量的思考和改良的。而这个差别,就是有些产品能够借鉴成功,有些不行。

你觉得我看死了你的能力?并没有。所有的创新其实哪里是凭空想出来的,都是基于对大势或是对环境或是对行业或是对用户的深刻理解,没有一定的经验是出不来的。我个人是不相信偶然事件的。

运营投放们需要你配合的时候,不要以为自己不相干,要多看看他们的活动类型、多思考他们的投放渠道、多问问为什么这么选择;

数据出错的可能性很多,因此,在说出“从数据结果可以看出”这句开场白之前,先去了解清楚数据本身是否出错。

对整体产品比较好,不会因为产品的私人考虑而有所偏差或者停滞;

可能因为不同平台的不同算法,导致数据和你真正想要的算法不同,从而出错;

……

就是简单的移动一下位置、放大一下,想不明白为什么美工做不出来;

工作中,会经常出现要和第三方沟通对接需求的情况,这个第三方有可能是公司外部的,也有可能是公司内部其他小组的。

往往没有一个讨论重点

合作方面1、合作过程中多积累

可能你会很疑惑,数据怎么会错呢?当然会啦:

我们就尝试按照不同方面来列列看,到底有哪些事情是我认为同样很重要,但是可能其他人不这么认为的”小事儿”。

以上,对于“产品借鉴”的看法,是为了说明在很多事情的思考上,并不需要一板一眼,能够解决问题的方法就是好方法,而不需要给自己设定一条无形的线,这个不可以做,那么不可以做。那样,你会把自己给累死。

慢慢积累自己对各方的大概知识框架;

题目既然说的是小事,那么我就不说产品经理最重要的一些事情,例如:

出现问题或者需要相关需优化的时候,可以根据文档找到具体参考;

这么做的好处:

对数据分析会有更深入的理解;

可能因为开发埋点的时候不小心弄错了,从而出错;

也许流程可以先梳理起来;

产品经理基本工作内容的落地执行;

老板只会哔哔哔的提需求,太坑了;

你这个时候再去因为这些papapa去修复、去重新再上一个新版本,这又是多曲折。

基于理解的设计和开发,可能能够在照顾到现有需求的前提下,考虑到一些可能的坑和未来的改动;

产品经理是需求的开始,也是需求的结束。只要上线了,那么就说明你是允许这个上线行为的。

产品工作本身1、多从整个产品的角度考虑问题,而不是仅从产品岗位角度考虑问题

不会把时间浪费在错误的数据上;

顺便锻炼自己的应变能力和心脏承受能力。

killifer,微信公众号:killifer,金融资讯&工具类产品经理。脑洞大、笑点低、间歇性“有毛病”的理工科实力逗比少女。

好啦,暂时想起来这么多,如果觉得有补充的,可以在评论中告知哇~

合作过程中,多问为什么,这个在之前的文章里有解释过,这里就不在多说了。

这个时候,其实你要反思一下,是不是你从来不和他们沟通为什么需求要这么做,才慢慢导致这种情况的呢?

既然,暂时无法做创新,那么就该把当下的事情做好,在执行的过程中积累,为未来做准备,同时,从结果论上来说,也对结果负责了。

这么做的好处:

开发们围在一起沟通技术细节的时候,不要以为不关自己事儿,要多听听、多了解下他们是如何实现需求的;

其实,这种想法并没有什么意义,如果站在整体考虑的话:需要强运营的产品,自然偏重运营;需要强功能的产品,自然偏重产品。

和第三方对接,本来就存在很多坑(文档不齐、接口不ok、对接时间超长等等),产品最好要能够在对接前期先准备起来,这样开发们在对接的时候也会比较方便和省时间。

但是,从整个产品考虑的话,这又是一件需要并且最好做掉的事情。毕竟,在整个团队有数据压力的情况下,需要用一些外在方法来带来新增和日活,这样对整个团队都好。

不说好处的都是耍流氓,这么做的好处如下:

因此,无论是开会还是讨论,都应该在之前就列出讨论的主题、围绕主题的一些点。这样大家就可以根据列的内容进行有条理性的讨论了,从结果上,也更容易有效果,搞定事情。

……

有助于项目的交接。

很多产品经理会经常说:

很多人会说,“我想法多”、“我思维活跃”,但是想法多真的有你想象中那么重要吗?

团队对你有信任感;

大家都是成年人了,就不要相信什么抄袭可耻了,应该认为借鉴有益才对;

这么做的好处:

这么做的好处:

2、摆正和各方关系的心态

举个例子,产品比较小的时候,需求可以有很多,面临的方向也可以有很多,大家都在进行不断的调整。这个时候,有可能会因为某些因素(公司要求产品盈利等等),而出现你原本安排好的下一版需求没办法做了或者需要推迟做,要优先做其他的。可能这个时候你已经做完了所有的需求分析,一旦改变,那么就要赶时间做新的东西了。

我不是为了反对这些人的想法而反对,而是说:

但是,做产品人不可以这样,因为有可能会因为你的执意,导致团队在做错的事情。

3、灵活看待制度

举个例子,一般公司都会规定版本上线的时间。但是如果App临上线前发现了一个大bug或者比较影响体验的bug。那该怎么办呢?是推迟上线,等修复后再上线呢?还是不管三七二十一,制度说要上,那就上呢?

既然是已经存在的事物,那么人家坑都帮你踩平了,你何不借鉴一下现成的东西,再根据自己产品的情况去改良一下呢?还非得自己去全部踩一遍坑才满意吗?

作为一个产品经理或产品负责人可能会忽视哪些实际上很重要的小事?

这个时候,需要考虑的不是个人增加工作量的问题,而是对整体产品好不好的问题。如果确定对整体产品比较好,那么就该摒弃个人的负面情绪,顺势好好的执行下去。

产品经理经常需要和不同的人进行沟通和对接需求,例如公司领导层、运营、投放、商务、业务、设计、开发、测试等。

这么做的好处:

下一篇:没有了

相关新闻推荐

友情链接: 网站地图
Copyright © 2015-2019 http://www.kai-wang.com. AG亚游国际有限公司 版权所有