作者abc5555 (前进)
看板Soft_Job
标题[心得] PM做产品背後的折腾
时间Sun Oct 24 18:10:04 2021
Hi,大家好~
想抛砖引玉分享一些产品相关的经验,如果有大神也再恳请指教!
--
medium好读版
https://reurl.cc/V5Ymmn
--
这篇主要想分享的则是我们产品人在产品路上的过程,和这中间的爱恨交织……
如果你问一个产品经理喜不喜欢做产品,大概会有三种答案:喜欢、不喜欢、爱恨交织。
能说出喜欢的只有两种人,一种是大师级、另一种是Jr.PM。
大师级可能是早已 "行至水穷处,坐看云起时"。知道公司战略与市场需求怎麽找一个平
衡点然後试着推进;心中对於用户心理的琢磨也有很好的直觉,有较高的机率在规划与设
计出产品架构时,能够较精准的切合需求。也知道产品该迭代的方向;同时累积足够的产
品经验 与 知识框架结合,沟通并说服有资源支持的管理者。因为几乎已了解所有可知的
方向、接受不可知的情况,然後以自己的生命力不断的推动产品生长,能够真正的发挥自
己,而这样的情况下,产品就是自己生命力的展现,谁能不爱自己呢?
而Jr.PM的喜欢,可能是刚进去的几个月内还没有遭受到产品形成的折腾。只看到大家沟
通讨论然後形成产品,还未能感知里面规画的细节;或是还在做一些执行层面的事情,只
看到产品与用户互动的情形,还未能感受到找寻产品方向的迷惘;也可能是已经做了一些
时间的PM,但是公司的战略网铺的太安稳顺遂,高层的注意力并不在该区块上,所以可以
一定程度的创造,且屏除产品形成的初期给的充满冲突与未知的不安感。
喊不喜欢的,基本上过不了多久大概就会自动被洗刷掉,或是继续做着不怎麽样的产品,
然後在公司的保护伞下过活,而这样的PM基本上是做不出任何好的产品的,因为好产品需
要不断的琢磨与迭代,必须要很大量的心思在产品路上探索。只要不喜欢就无法聚焦,不
能聚焦就无法用合理的逻辑来建构规划,没有合理的规划那产品就只会是一团糨糊。
接下来就来聊聊,会说出爱恨交织的产品人们,实际在运作产品上的情况吧。
正常一个产品大概可以用底下几个流程来区分:规划、提案、画面UX、设计、工程、上线
後迭代,这几个阶段来进行,不过不同公司的运作模式和实际情况会有些出入,就参考用
即可。
规划、提案:
通常这件事还可以再分成商业分析、竞品分析、老板拍脑袋、既有的商模下推出换汤不换
药的新产品等等。然後这件事通常是一个产品人的崩溃起始点XDD,因为通常一件事情总
会有正反两面,随着复杂度提升它可以分裂成更多面向,例如说一个人看书的习惯,有些
人习惯一口气看完,有些人习惯一个章节一个章节看,有些人就是散漫着看,当这样的习
惯你要锁定什麽人群做出App,这时候老板、其他协作部门可能可以提出不同面向的问题
来挑战你,然後如果你没能提出相对合理或是明确的逻辑来针对你的规划来做解释,如果
是细节还可以说回去想想,如果是主架构那就是打包回去继续想。
不过大部分的公司,应该会偏向於老板是优秀的战略者,提出一个方向的概念然後由产品
PM去做Survey,然後老板再根据你提出的资讯来做判断跟评估,不过即使这样,洗脸还是
很轻松写意并自在的喔^.<。
然後主架构如果在被摧枯拉朽几周订下来之後,接下来会是使用者流程的定义,这时候你
会遇到UX部门、业务部门、设计同仁的确认,我的实际情况是这样,简单画了几个
wireframe之後,cue业务相关同仁来看,
—
我:欸,你看这样设计OK吗?
业务同仁:嗯...好像还可以,不过这边比较不清楚
我:好,那我再去调整一下流程…(一段时间过去後)
我:那如果根据某元素,然後我再带画面到这里,再如此如此的…
(然後讨论过一段时间之後…)
我们:嗯…不过这边可能会让一部分的小白用户不知道怎麽用、资深用户看了也会疑惑。
我:好…那我再去调整过。
—
通常我们都很希望自己可以第一次就带出无懈可击的逻辑和脉络,来让产品直接上线,不
过通常牵涉到感知经验、接触业务、甚至是公司模式的局限下,我们只能根据片段的合理
逻辑,往更大的一块来探索。然後这时候我们只能当个发动点,不断的往合理的逻辑方向
产出画面、架构,来让大家讨论与延伸。很多时候,我们可能做了数天的逻辑推演、架构
思考,只是为了在下一个会议的时候,给业务同仁灵感 或是 跟相关同仁讨论後自己的灵
感,不过通常这些探索过的方向不会白费啦,它没有消失,只是变成事实上合理的形状
(?),这也是产品人又爱又恨的地方,因为有时候规划方向总是不容易一步到位,但这其
实也是迷人的地方,你在开始规划之前,总无法想像到真正成形的样貌是什麽,因为我们
典当思想脉络,唤出某群用户需求的未来。
接着在规划方向定案之後,如果你想要让产品变得更好,那就是继续下一场吵架或是崩溃
修正。因为接下来是充满优秀的用户感触 与 情怀的设计师,你必须和他们针对画面上某
个东西收进下一层与否,或是用折叠或是展开的形式,进行讨论与吵架(无误),虽然有时
候会吵的心很累,不过通常设计师提出的UI/UX的想法和论点,总是会让我惊觉到,咦?这
个用法真的有可能,我倒是没想过。然後有些会是"X(心里讲,消音),我就觉得你这个流
程不合理"。不过越好的设计师,越愿意扞卫他们的想法,而这时就要从用户场景与逻辑
上,有时甚至拉业务单位来扛一下,在使用流程上去说服设计师,然後後续用数据来佐证
你们彼此的想法与做法,以此养成与设计师相爱相杀的关系!
接下来下一个环节,经过一开始规划:老板的摧残、相关业务部门的探讨。设计:与设计狮
的产品页面抢粮(?),接下来…怎麽可以缺少产品产出环节最核心的人:工程师。
通常工程师会比较偏向於逻辑性、循规蹈矩的个性,至少在看着你的文件在进行工程时会
是这个属性。通常会有的是,我们在写一件事情时的逻辑如果不够扎实,通常会被打回来
重练。例如说:一个使用场景有A情况、B情况、C情况,然後你终於明确写好逻辑,然後给
工程师了!工程师开始实作之後,突然就反馈给了你D逻辑,然後这件事显现後,你可能会
反思欸干我怎麽没有想到这麽显而易见的情况,轻则文件补个逻辑,30分钟就好。重则欸
你们可不可以先跳过这部分,然後你就边崩溃边加班把缺失的架构跟逻辑补上。
另外,可能有些拐瓜劣枣的PM太多,我有遇过RD一开始是抱着嘲讽的态度在对PM的,不过
他们却也是很可爱的生物(?),因为只要你描述的事况,与说明的逻辑合理,他们就会开
始正常的尊重你。不会像职场政治上,有些人只是因为某些点,就diss你到底。所以好的
PM带RD上天堂,坏的产品人RD就会让你去抢狗粮,好像合情合理?
产品在跋山涉水、千辛万苦终於可以上线後,产品在市况的反馈後有些功能要做调整,或
是要再迭代不同的主题,那…
我们就再把上述的流程再走过一次吧^^~
产品人让人又爱又恨的地方,就在於你会是一个产品方向的发动点,如果你有神一般的逻
辑(正神),那你可以提着明确、弱点少的逻辑来创造出一个能存在於这社会上的服务模式
。但我们知识、认知、感受都有一定程度的局限下,我们就只能把每一次被产品洗的灰头
土脸的经验内化,然後不断的让自己成长,随着每个产品、每个迭代运作之後,我们建立
更多团队的信任感、建立更多对用户真切的感知、建立更多好的知识架构,让我们在产出
产品的脉络可以相对更合理,不被天生的主观所局限。然後由此来产出更好的产品,更多
的结合企业资源和自己天马行空又合理的想像力,来造出一个匠心独运的优秀产品。
在相对合理的企业环境下,当一个产品历经千辛万苦上线时,你看到用户实际的运用,不
管有人对你的产品爱与恨的分享後,你就会觉得这一切真的都值得了!
愿还没成为产品大神的产品人们,共勉之~
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.161.58.7 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1635070206.A.E22.html
1F:→ MoonCode: 你说工程师偏向逻辑性、循规蹈矩 这什麽刻板印象 10/24 18:28
2F:→ MoonCode: 要做好一个产品 团队哪个人是可以没有逻辑的在做事? 10/24 18:29
3F:→ MoonCode: 把某个职位做些特殊的形容(可爱生物?)完全没有意义 10/24 18:32
4F:推 abccbaandy: 楼上,老板/PM阿,很多时候听到他们的想法真的想跑... 10/24 18:50
5F:推 j0958322080: 真的这麽不爽 pm 建议 rd 自己兼 pm 10/24 20:09
6F:推 BignoZe: 满多PM过得满开心的呀 10/24 20:44
7F:推 carzong: 不好说吧,如果比起很多奇奇怪怪的 ops/mkt/pm,工程师真 10/24 23:23
8F:→ carzong: 的是平均起来比较有逻辑的。 10/24 23:23
9F:→ carzong: “要做好一个产品,团队内哪个人是可以没有逻辑的”,问 10/24 23:23
10F:→ carzong: 题是一间公司里面,没有逻辑的人,比你想的还多… 只是 10/24 23:23
11F:→ carzong: 因为工程师都只碰到工程师跟PM而已.. 10/24 23:23
12F:→ MoonCode: 当你怀疑别人没有逻辑的时候 先确定自己不是那个鱼 10/25 00:23
13F:推 MDay56: 辛苦啊!! 10/25 09:47
14F:推 fanatics5566: 会补文件跟Skip的PM还是给推。看过 PM Lead 不补文 11/01 01:09
15F:→ fanatics5566: 件,叫RD直接改Code,事後还装失忆,让RD改规格重 11/01 01:09
16F:→ fanatics5566: 工的废渣PM 11/01 01:09