从事产品经理的工作之后,你的思维有哪些变化?

1,024 阅读6分钟
原文链接: www.jianshu.com

      随着工作时长,我们身上都难免带有自身职业的标签属性和思维习惯。近期很想进行自我梳理的一个话题是:“从事产品经理的工作之后,你的思维有哪些变化?”

    关于这个问题,曾经在知乎上刷到一个精辟又不失尴尬的回复——如下图:)

竟无法反驳

    除了“耐撕”度强了,也许还有以下这些吧:

一、“新事物保持好奇心和猎奇心。”

    一开始也许是八卦之魂作怪,不过也由于产品日常工作的需要和习惯,例如行业动态或竞品分析,会下意识地关注、学习新事物、新趋势,再结合自身工作的关联性思考如何改善/应用到自身的项目或产品中来。早期做运营策划的时候,会定期收集和总结各种线上线下新鲜有趣的活动设计案例~而现在更多可能是行业的一些新趋势、尝鲜近期有意思的产品或个人知识扫盲等等。

    抛个之前猎奇心大于羞耻心的小栗子:

      自从体验了一把附近超市的无人收款自助服务后,对无人超市的模式大感兴趣。搜刮了小区附近有一家……成人用品无人收款自助体验店,然后大大方方地走进去研究了一把~emmmm,一切为了调研。

有时好奇并不总是害死喵呜~

二、趋向于“目标化”思维。

    在公司桌面上的常驻小贴士是:“带着目标去沟通和解决事情”。这是近一年感触和受益最深的一点。产品经理这个岗位往往需要对接各个不同的业务部门或其他不同的职能岗位,然而不同部门不同岗位的同学其实关注点和目标都是不同的。在对接沟通的时候,需要把握和确认的一个核心问题是:需求方的的目标或想解决的问题是什么?这样才能通过融合彼此的目标来提供对应的解决方案。

    来个别人家的栗子:

    曾经有一位BD朋友比较困扰,他和团队内的产品经理沟通,对方总会和他说许多技术上的细节(接口、回调、异步处理等等),自己听了云里雾里,半天都还没可以明确是否可以实现,沟通效率和结果产出都比较低。而其实对于商务BD同事来说,他们最关注的是目前的产品功能是否能满足支撑其对应的商业化模式,具体的产品如何实现的技术细节问题,他们往往并不需要了解。在沟通的过程中,往往只需确认以下几点关键内容:

1、现有产品功能是否能支撑实现这种商业合作模式?如果不能,改造大概需要多久(排期)?

2、需要对方协助支撑事项

3、产品侧的风险点和建议解决方案(优选和备选)

除了通过理解需求方的目标外,还有一个好处是,带着目标化去解决事情,某程度上可以时刻提醒自己做事情的正确方向,起码不会偏离目标太远。

我的目标是:小鱼干:)

三、“结构化”思维。

    早期做产品时,也许只会想到怎么去实现某个功能,有哪些关键逻辑点、交互细节、体验等等。后续会慢慢发现,“结构化”思维对产品经理非常非常重要。在产品/项目立项初期,对产品的定位、结构、业务模块的整体把控具有重大意义,这也是为什么许多规模稍大的公司都会配有一个“大产品经理”。带着系统化、结构化的思维去进行产品规划,往往会考虑得更加全面,业务兼容度、可拓展性会更强,避免多次重复做无用功。

   最后再来个个人黑历史栗子:

    某次咱们有个运营需求是针对某个省份的项目进行个性化的改造,当时直接根据具体的需求规划功能安排上线了。两周后,又有另外一个分省需求,和之前的需求有70%雷同,但由于之前规划功能时没考虑配置化、拓展性,结果又需重新调整,等于是耗费研发资源做重复的事情,同时也不能更快速地响应运营侧的需求。吸取这次的教训,后续相关的需求,都会养成一个反思的习惯:产品、接口能否进行配置化?模板化?

    谨记,好的结构化思维如同“偷懒”思维,一劳永逸有时效率更高。

四、“项目经理”思维。

    项目经理思维的特性是:对项目结果负责,对进度、质量、风险敏感。当公司、产品尚未形成规模时,往往没有“项目经理”或“QA”职能同学的介入,这时产品经理同时需要承担项目经理的角色,从立项到上线,各环节资源协调、进度、风险都要跟得比较细致。实际上,即使公司有项目经理,往往对方手头都同时负责着N个项目并行,难免会有兼顾失衡的时候。项目经理不一定是产品经理,但产品经理一定是项目经理,因为我们是产品项目的最终负(接)责(锅)人~

    除了这些其实还有许多其他或奇葩或神奇或常被吐槽的特性,例如:容易怀疑否定、偏执狂、习惯性焦虑……每次接到紧急需求需要熬夜加班出方案时不禁会怀疑自己当初的选择,然而当凌晨上完版本后看着自己规划的产品上线后,却又一脸心满意足,抖M体质暴露无疑。

果然是抖M,撒猫粮TOT

    无论是哪种思维的变化,愿我们都不忘记做产品的初心,愿我们一直在进步的路上。