产品人的路也走有一段时间了，分享当初刚到新创时遇到的震撼教育供大家参考~ -- Medium好读版： https://reurl.cc/vWgAky -- 前言 在产品路上走久的人，一定遇过各种坑，不管是从被别人指着鼻子骂、或是规划许久的产 品最後难产、又或是遇到各种设计陷害或是光怪陆离的事，只要你也是矢志於推动产品面 向的世界的人，那麽这种坑，对我们来说，初期遇到一定躲不掉，因为很多事情都超出了 认知边界，只有经历过并纳入经验库後，才有能够参考的逻辑框架。 因为在推动产品时，你可能没注意环境的限制、文化的影响，或是产品在推动时剥夺到他 人的资源种种，当然我们做产品有时真的无法面面俱到，但在做好一个产品人的立场下， 把伤害减到最低，也是在组织架构内累积正向的信用循环的一个很重要的点，有时候产品 架构想法再好，只要身边的人、事、物无法有效的协助，那产品的效益可能会大打折扣， 更严重可能危害到团队气氛或是自己的职涯。 所以整理过去踩过的坑分享给大家，一方面是有架构的汇整这些情况，看能否从中再挖掘 到让自己成长的东西；另一方面是产品人的业务层面过广，所以藉由自己抛砖引玉让大家 收集不同的资讯，在某些决定上可以有不同面向的思考，尽量达到双赢或是减少双输的情 况。 — 这次分享的是我第一次进新创，就给了自己一个巨大的当头棒喝。 冲突 那时候是一个资深UI从头diss到尾，起因在於以下几个点： wireframe画的很烂，那时候还在用axure各种剪贴图片，没有理解到wireframe的更本质 的意义，一些对齐排版都不懂，也还不会做互动 对於产品的运作流程没有很全面的认知，当时还不知道persona、roadmap、user jouney 等一些产品流程中的知识工具 交付产品求快次求严谨(这看产业别，不一定是坏事) 冲突最後越演越烈，後来UI不想和我合作，直接抹黑我不想沟通、没有交付文件，後来主 管保了UI，而我最终的情况是黯然离开团队。 人物背景 UI是从严谨的电商出来，对於团队夥伴的能力又非常的要求、个性也比较苛刻，和她合作 的沟通成本非常的高。她对於产品UX的部分可能有片面的理解，但其实也不全面，但我也 因自己能力、经验的不足，没办法有逻辑的跟她说，哪些阶段并不适合做哪些事情，连吵 架怎麽跟别人吵都不知道(笑)，所以很理所当然的她就会觉得我不配与她共事。 我的主管也不是做产品出身的，是某科技大厂的专案经理，所以也不知道如何做产品。他 挂的title是产品总监，之前在大厂内并没有着墨IT产品的推动与运作，比较多的技能是 在大组织底下的政治生存，实际和产品比较相近的经验只有听过梁宁的产品思维30讲，很 毛骨悚然吧…但其实这也是一般新创环境的日常，至於新创整体情况比较细节的探讨，未 来会做一话特别跟大家分享~ 我那时候的产品资历大概只做一年多、待过一间公司，对於做产品的知识、经验、架构所 知甚少，对於商业、组织该如何推动产品也是很有限的认知。 前公司虽然做产品的方式和流程有点胡来，却是构筑了获利的商业模式与架构，所以在某 些产品的运作流程上是值得借监的。 而从那个架构出来的我，自然看新创很多事情会觉得不对劲，但又不够厉害，无法条理的 说明阶段性任务的运作，所以在团队中做事情就处在很别扭的状态，知道某些环节不对， 但又说不上来。发生了冲突，却没有足够经验能说明化解，导致情况变得恶性循环。 状况分析 我自己在做产品时，基本上还是以产品推进为最终目的，所以很多的沟通妥协在所难免， 但基本上不是一个跟别人对着干的人。也许遇到过度偏激的设计师和自己能力不足是一种 极端处境，但还是会习惯反省从这样的架构中，自己领悟到了什麽，尽量不要再犯同样的 错，或是避免这样的处境。 现在的我来看过去冲突中的几个点： 1.wireframe 2.产品运作流程 3.产品交付 然後从这些点中，试着从更广的视角来看这些很基础的产品概念。 wireframe 因为也经历了不少组织，我遇过这几种做wireframe的情况： 1.我的Jr.PM时期，很少在用Axure原生的线框，大部分都用截图的方式在拼贴，整体来说费 时费力，因为那些拼贴的调整不像axure本身的元件调整这麽方便。 2.老板说用ppt做也没差，设计师接的做APP或网页文件是ppt…这某种程度上是惊世骇俗的 ，因为ppt无法呈现Figma 或是 Axure的灵活性，基本上是做线图的人痛苦、做图的人也 痛苦、做工程的人也痛苦。 3.当开会工具、设计文件、工程文件，全部混在一起，这种做法会有点混乱。 4.和主管开会时，就要把所有的互动完全做出来，但是没有先确认过流程和架构，所以主管 只要更动需求，一个小小的功能你可能就要花几个小时修正… 5.交付的互动性、相关的元件尺寸比例都要有，包括对於栏位的限制、状态等等。 wireframe其实只是一个交付想法的过程，怎麽做对我来说是一种进到组织内嫁鸡随鸡的 概念，因为wireframe背後对市场的观察、产品的战略、组织的协调，这些才是产品人的 重点，而如果在讨论过程中，你大量的精力都是花在调整wireframe，那真的很浪费产品 人的才智，与其调整线图的边边角角，或是哪边没对称到，哪边互动没做好，不如思考这 个功能要运作的本质是否真的切合用户的需求了。 我遇过很要求wireframe的公司，要做成几乎是高仿真原型，但是这样PM交付的时间却是 一般时间的4~5倍(也许更多)，而且这不是为了客户端需要先进行验证，只是那个产品总 监个人的坚持。我现在还是不能理解。因为市场上类似的竞品，开发功能数量已经比该公 司多了好几倍了，但公司做产品的速度还是上不来；另一部分，人员离职後交接成本很高 ，因为新进的PM大部分没有这种原型功力，平均PM在位时间可能不到半年，所以才能符合 原型需求，人就又要离职了，後来就继续无限循环；我从商业跟组织角度真的无法理解这 种高仿真的意义在哪，还是我太弱了还不能意识到这件事的高深(怕)。 而在当时新创的情况下，被要求做互动式的wireframe在那个时空背景下其实是没有必要 的，因为整体产品架构甚至是公司自己本身的商业模式都还没有建立，在这种产品末端的 地方做细节的刻凿确实有点过头了。 产品运作流程 在那时候另外一个被diss的点在於没有其他的产品知识工具，後来意识到这件事情其实颇 重要的，因为产品人是一个产品战略、框架、用户体验的发动点，我们必须有条理地说明 产品想要走到哪，为什麽。 通常在已经有商业模式营利状态下的中大型公司，对於产品人来说会比较有运作空间，因 为组织的权利比较有机会下放给你去运作，如果公司的产品有一定的生态系的话，那对於 要跨出Jr阶段的产品人比较有机会看到不同产品间的串连，还有公司在产品上的战略布局 与运作，但这种位置有时候看求职的缘分、另外一种是自己的缘分，因为自己如果没有拉 高层次看产品，也可能永远只是一个功能型的产品人。 而在有办法挖掘、探讨的情况下，我通常会用数据说明目前产品的情况，因为数据在某些 程度上是神圣的第三方，避免产品被大家的主观拉扯而无法进行。接着再用路线图去定义 我们可能要前进的方向，让大家可以比较明确知道产品要前进的方向，要讨论或定义战略 也能够有锚点可以讨论，不会让讨论偏掉。 如果产品比较稳定，但求发展出新的机会，我会用user journey或是更深度了解和相关业 务同仁的单位讨论，觉得怎麽样的发展方式可能会比较好，取得某些程度上的共识之後， 再进行产品推动，这样有时候产品运作会顺利很多。 产品交付 在当时的新创公司，被要求什麽东西都交付的很严谨。但自己经过大大小小的公司後，且 思考过产品与商业的本质，我的看法是：绝大多时候，交付的逻辑要严谨，但文件就尽量 清楚明了，有模糊点就口头沟通，除非已经合作的很熟悉，不然别指望PM能交付很完整且 钜细靡遗的文件，这时有赖於产品人能和自己的团队明确沟通，做产品这件事情的本质和 我们要前往的大方向，而不要让团队成员纠结在你哪个小逻辑怎麽没写好，那边怎麽漏了 。基本上是以快速进行、互相信任包容的方式在推动产品，这样让做产品的过程中阻力降 到最低，大家在一个又一个产品或功能上线後，就能够越来越有默契，团队关系也能越来 越好。 我要加个但书，在现有的产品环境下，有时候确实公司策略或文化下，不一定好达成，但 我们还是要清楚并知觉地与产品团队沟通，才能即使不在这样的环境下，渐渐地推往我们 想要的处境与方向。 小结 当时那样的情况，心情上确实是很巨大的打击。一方面觉得遇到了神经病，另一方面也深 感自己在产品路上还欠缺了很多很多的能力，也因为当时的情况不断地去思考各种不同的 工具、运作模式在产品路上该怎麽执行，渐渐地会发现自己可以在不同的团队组织下去沟 通，也可以在不同的产品阶段采取相对应的手段去帮助组织推动产品，而且也能凝聚团队 讨论该进行的方向。现在即使换环境、或是换团队还是会不断地去思考怎麽在这些流程上 达到最大效益，这是一个需要不断调整和思考的概念，希望有帮助看到这些议题的大家。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.137.108.233 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1659878472.A.E18.html 感谢反馈，因为PM比较多会遇到各种面向的情况，所以想说描述清楚一些 之後会试着文字再精炼些 认同，但PM在做某些团队沟通和产品探索时，没有这些工具还是窒碍难行 同时我也认同MVP的精神，但我这几年的产品路走下来，即使想MVP，但可能面对的情况是 组织内其他人根本还没有这层意识，这些都需要PM去做沟通跟说明的桥梁，台湾的产品环 境并不如外国那麽成熟友善，所以才需要很多的沟通说明 逻辑上是UX，但台湾的环境、跟组织意识大部份(我遇过的互联网公司)都由PM来负责QQ ※ 编辑: abc5555 (223.137.108.233 台湾), 08/08/2022 12:01:21 ※ 编辑: abc5555 (223.137.108.233 台湾), 08/08/2022 12:04:50