<strong>以下转录文本是由飞书妙记自动转录而成，未经过人工校对</strong>
<hr />
各位听友大家好，这里是津津乐道与声网联合制作的播客栏目编码，人生这是我们的第一期节目，那么相信大家已经在预告片里面听到了，我们的这档节目会聊什么。那第一期节目，我们就来个拉仇恨的话题。
小白好，今天，让我们一起来聊一聊程序员和产品经理之间的这些故事。
今天的主播和嘉宾除了我和小白以外，还有两位来自声网的嘉宾。请他们分别介绍一下自己，那你们俩谁先开始hello。
大家好，我是毛玉杰，目前在深网主要负责这个相关的技术架构的工作，那个在声网也已经有，五得五年的公工作经验，目前在从事一些浏览器相关技术的一些开发工作。
那你是什么出身技术出身上学学的就是技术对，然后现在做的也是技术对 OK 那云 1 介绍一下自己，大家好，我叫红云，叶娜来自深网。
现在是 LT 行业的产品负责人，那我是曾经是一个个差点，成为航天工程师的辍学fsd，那加入互联网行业已经快六年多的时间了，一直在从事，和 AI 人机交互，实时互动相关的这个领域，然后去做一些我自认为可能是一些有温度的技术产品。
今天这个话题大家听到了，有点拉仇恨了，分别请来了一位程序员和一位产品经理跟大家聊一聊我们所有的开发车其实在日常生活当中或者工作当中其实都会遇到。要一个怎么讲一个梗是吧，小白就是这个产品经理与程序员之间的矛盾。是的，天天都听着说，程序猿跟产品经理又打起来了，对吧，我们会去拉架产品经理又改需求了，程序员要打人了，各种各样的岗位对这种也不能叫这个梗，就是大家总觉得，开发和指挥我开发这两件事情永远是一个矛盾和对立。
是的，我们觉得说，大家这两种工种其实应该是一个合作的状态，而不是说我指挥，你去做什么或者是，我就一定要去听指挥，其实大家更多是一个合作，我们是共同去达成一个目标的人，程序员和产品经理分别说说自己不爽的地儿吧。
程序员先开始，对吧， OK 好，我可以说一些，说几点，因为之前其实那个无论是在做开发，无论是在做架构设计的时候，其实跟产品都有非常多的一些合作。我大概说给几点，那个是一些工作里面的体会，那么第一点的话，其实，我可以称之为校需求变更，那这个变更的话不是说经常变化，他们有的时候会根据自己的一些对于业务的判断，有的时候会临时插入一些需求，那么在客户没有真正地理解客户的需求的时候，她也会去对于这个需求会发生一些变化，理解会发生一些变化，然后除了对于需求之外，他们还非常关注，于是说我们必须要在 1 个星期，把这个需求给做出来OK，OK，除了对于交付时间，程序员其实很多时候，会认为是说我们写完代码就 OK 了，但是你最后我们会从产品音乐得到结论是说，为什么你，你你只是做完了就也就是你没有闻到，你没有交付一个结果，就这个结果不是我想要的。所以对于最终的交付结果，也没有一个比较清晰的判断。
这是我认为的第一点就是一个需求变更，那么第二点，是我一个就是还比较切身的一个例子，就是，我之前其实也做了很多的需求，那么这个需求做完之后也就做完了，完全没有任何的就是体现出来价值，因为就是你觉得你做的东西其实没有被真正的有效地利用起来对，就是这个时候挫败感特别强，是不是出版非常特别强对，所以这个时候我们一般就会说，你看你是产品经理怎么规划的，这个对产品对吧，你看我你你就催我一个礼拜做完，然后做完你就不用了。
什么情况对，你急什么？
对说好的优先级很高。
对，就是说这一点就是我们自己因为做出来东西，就特别希望有能产生人的价值。
对。
就是第二点，那第三点的话，其实就是还是一个比较典型的问题。就是可能是产品经理跟程序员之间的这个思考的角度，对不起那个一个是更多的诚意。
这个互联网名词又来了对齐。
对就产品经理更多地会考虑从业务，怎么帮公司赚更多钱，它这个产品怎么打磨得更好，那程序员可能更多的就是，我今天要用 C 加加做还是用插画做，对，可能我们更多的会去从一些技术的实现的这个圆就是角度上去思考这个问题，所以说那个在这个换位思考，以及最终的交付标准上面我们可能是需要具有更多的沟通和理解的，这是我觉得是说那个我们程序员跟这个产品经理之间会有一些对吧，天然的可能就会有一些这样的对立的对。
对，云义说吧，他吐完你的草，来使劲，我终于知道为什么要毛毛，先说了，我就一直在对号入座，你知道吗？
然后我觉得庆幸我不是被毛毛造成伤害的那个人，但是我也对其他人造成了伤害。然后其实刚才毛毛在说是我也在回溯，就我的三段经历，其实有一个共性的点，首先它都是 to b 端的生意或者是 to b 端的产品，对那其次，我都经历了从 0 到 1 的过程，那所以因为这两个因素，就是所以毛刚才提到的在插入需求和一直得不到价值反馈这两件事情上，其实我是非常有感受，但是这里我要吐槽一下，就是说其实大家平常经常说段子可能，程序员经常说，这个需求做不了，但其实真实生活当中我们不会这么不理性，就是我们会感受到的是那个就是宸汐缘对我们的质疑，说这个需求不合理，或者你为什么要插入这个需求，那其实这个时候我们也很委屈，那我们会觉得说我们可能是梳理了来自客户的十几个需求，我们已经 futile 了很多，并且经过我们的判断对于价值判断的优先级，然后，觉得这个实现的程度已经进行过的梳理了。那这是一类，那另外一个就是对于价值反馈这一点了，那这件事情其实是在创新的过程当中中，拓展新市场人的过程当中，其实是一个非常正常的现象，那可能就是我们最终可能就成为背锅的伤害者了。
那还有一点，就是可能我要反向吐槽了，那个刚才毛毛也提到1，很多程序，非常有自己的一些技术追求，那我也遇到过就是非常自嗨的晨曦园呐，因为我过去就是还比较长的时间，从事 AI 相关的产品的孵化，这些算法工程是非常容易意思对非常容易自嗨，他们对深有体会，对他们经常会说，你看我是用的纯的深度学习算法，我没有用任何的入背，但是，你的效果没有办法比，经过了我们人工一些先验经验，或者经过入味思索索性索结合所产出的这个结果，那你对于客户最终是如何用的，能对他带来什么样的商业价值，你是没有认知的，那这个时候就要跟他进行非常多的battle。这是一种自嗨，还有一种自嗨。那可能也是因为在创新业务相关，那很多演员发其实也会对于自己的技术的实践的预判其实是有误差的，所以我也经常被我的研发放鸽子对，所以这两点可能是我在这个过程当中会想要去吐槽的两个比较重要的点。
是，奢望有一点意思就是二月嘉宾其实从事的都是 1 个 to b 的业务，但是我特别想听听小白，你曾经在大厂做过这个，也不能完全算是 to c，这是在暗示我知道你在的大厂可能是一个有 to c 基因的大厂，对那在他们这个整个的过程当中，你觉得有什么词要吐？
其实整个 to c 这块，我一直最想吐槽的，就是我之前在大厂里面做一项目的时候，然后那项目，是一个对内的项目，对吧，那对那项目，它可能就只是对内部员工那我们肯定就是 to c 的。然后 to c 的时候。公司在给资源的时候没有给到一个专业的产品经理。所以就拉到了一个我们的秘书小姐姐来给我们做小姐姐可还行产品经理。然后那一次合作其实还是挺崩溃的，因为她没有产品经理的相关的一些经验，然后上来就开始给我们去加需求，而且会加一些可能奇奇怪怪的就是我，我会会直接去质疑他说OK，那我们这个活动可能就三天就结束了。然后你这个需求做完需要两天，那我们在这种场景下，我们是去做这个好，还是去做一个另外一个事情可能会更有价值。那这个东西对于他来说你要给人上课，这是就是到这个时候他问题就在于说他可能因为没有相关经验，他不会去思考说，到底哪个东西是我该做的。它可能就直接觉得那这个东西我就要，然后这个时候我们就很容易产生冲突。
就是因为你对这个产品的实现的代价是有一个预估的，你觉得不划算，但是他觉得无所谓你干呗，反正你是马蓉，对他可能就会觉得说，那我现在要对吧，你来给我干活的，你实现不实现，对，你有没有想到是你想太多了，也有这种可能。
因为当时我们最后这个事还是干了，只是说这个是不是我干可能用了一种可能更低成本的，但是可能也是我的习惯的问题，因为我是后端出身，那我会觉得说这个事情，我们如果上的不到位，可能最后会有很高的风险。
其实在国内的互联网公司。我聊过一些朋友。
我总觉得在国内的互联网公司很多的情况下，产品经理和项目经理这个角色是混淆的，你有没有发现确实包括我刚刚忙去吐槽的时候，就比如说，产品经理再差需求，但其实我们如果是真正的一个项目的话，有专门的项目经理会由项目经理来去评估，这个事情到底要不要插，而不是由产品经理来决定。
对，因为如果产品经理来决定，那一定的结论就是我这个需求很重要，明天我就要上线，对吧，但项目经理他可能会从整个项目的结构，包括我们整个项目的情况来去评估这个事情的优先级到底有多高，它其实会成局外人，他会以局外的人的视角来去看，但是产品竞争可能说OK，那这个需求是我提的，我觉得确实对用户很重要，这时候就会有误判。
是没错，因为我总觉得在互联网公司里面，项目经理的没有，要不话语权特别热，但是项目经理这个角色往往又是非常重要的，因为它会在产品需求和这个开发资源上，他是那个天平。他应该去平衡这件事情，但是往往很多公司在这块上做的其实并不是说特别好，可能大家都被敏捷给打残了，对，我是觉得这几年就是我们突出敏捷，当然敏捷也有它的一定的好处。
但是往往，有的时候必要的这种摩擦成本其实是很重要的事的，其实是需要有一个站在外面的人去看这个问题，因为无论我是产品经理也好，我还是程序员好，我其实都是，身在其中，难免会把这个事给放大，但是你可能有一个更高视角，任他去看的时候，他就会明确说你这个可能其实没有那么重要，是咱说回这个矛盾来讲，刚才大家也分别吐了一些。
吐了吐槽是吧。你们觉得，我觉得毛毛钱说，你们觉得就是程序员的跟产品经理的这种我们打引号的矛盾，其实我们都知道，这其实也不是什么大是大非的问题，往往大家都是为了实现这个需求，但是你觉得这个问题的根源会处在哪。
不敢说了，我不打你对，我觉得这个咱应该来一期视频看看这二位的表情。
根源，那个我觉得根源可能还是那个有很多原因，刚刚其实有提到极点，那个我也觉得比较认可，就是刚刚说有收到资源这个事儿那个比如说我现在其实有在大开发团队，那么我其实知道我的人能做多少事情，但是其实你的这个产品一直尽需求，然后你也一直没办法量化自己的这个需求的优先级到底是谁最高，那是有哪些需求可以往后稍微推一推，因为其实基本上产品里面过来的需求，很多时候都是第一优先级，就今年我这个需求是为这个案只有第一，没有第二对为大客户来做的，那这个第二个一需求又是为另外一大个工作的，其实在，现有的人力以及时间的情况下，我们确实没办法能满足那么多。
需求。
所以我觉得是说这个资源这块会是那个比较大的一个点。还有 1 个其实刚刚说的就是那个你真正交付的这个需求的一个结果，到底是个什么东西？是只是把代码写完了，还是说我们还有很多相关的，要帮助客户上线，要帮助客户交付文档，这些东西其实都，是不是在我们研发的周期里面，这一点其实在交付标准这块也是需要确定好的，因为我们后续的话，很多人认为写程序员很多人认为说写完代码之后，OK，我的工作就完成了，但是我后续免不了是说产品是希望你研发是能跟客户对接的，你要帮助客户说能够在它的这个生产环境里面，或者在他的那个那边可以把这个能够跑通。对，所以这个东西都是有一些 gap 的。
对我大概说这两点对，我觉得就是我印象最深。其实很多程序员的吐槽在于说。程序员的工作，其实它是没有办法被打断的。对，因为我们很多时候我们需要去思考一个路世纪沉浸在你的这个实现路径里面，对如果我这个路径被打断，我就必须从头再来对，但是，产品经理不曾想来小白把你的屏幕打开来戳一戳。你要给我改，然后这种情况下，就是导致了甚至现在很多时候，我们说的这个程序员的这种加班问题也源自于此，就是曾经有一个大厂的程序员跟我吐槽，我说你们为什么996，你这没必要，就是一天你有效的工作时间。
谁都知道你不可能 996 的写代码，那写疯了是吧，但是他跟我讲的就是我不是 996 在写代码是我绝大多数的白天时间都在被产品经理抓走开会对我只有晚上产品经理走了，我才有时间写点代码都是这样式的，毕竟我的本职还是写代码，但是白天要被拉去开会，我只能选择在一个晚上人静没人打扰的时候，我好好把我的这些代码给好好写一下对，所以你也不能怪 996 这件事情真的在项目和产品管理里，很多公司其实在这一块，我觉得还是有短板的。
夜深。
其实在这里关于这个需求的问题就是刚才我说的抓程序员拉程序员改需求，这个是我想请云逸去讲一讲，为什么从产品层面总是有这么多的需求，要改。
这个确实是就是刚刚也提到一个关键词是敏捷，我觉得敏捷这件事情现在已经越来越没有下限了，就是确实是商业变化的，这个节奏很快，可能有来自外部市场大环境的，也有来自竞争对手的，也会有来自于我们自身的优先级的讨论，所以其实很多时候真正当这个需求在我们，像陈轩去阐述之前，其实可能已经经历过很多的内部的栽头，或者说我们自己的内心的这个歪头了，那所以这我觉得是一个必然的过程，但我觉得这个矛盾的根源其实可能还是就刚才大家也说黑话叫对齐，那我觉得可能就是大家没有达成共识，那其实很多时候我们的这个需求变更，其实也是为了能够交付更好的产品，就能够去帮助客户，去解决问题，那特别是 to b 端的产品。
其实我这对他是以交付到客户手上，真正用起来才算结束的，而不是说我们研发开发就开发完了。所以这个过程当中确实就是会出现一些 A 需求的变更，然后需要在特别新产品也需要研发，可能早期跟着客户一起去打磨上线，然后把整个我们交付的过程甚至包括客户后期型使用的一个前期的过程一起打磨顺利，这才是我们一个整体的从埃产品功能到运营的完整的交付过程。
所以这个过程当中，那确实是会有这样的，一些快速的变化，那有一点我也觉得确实可能是包括我自己以及我身边的很多产品经验，我们自己其实就是挺擅长，或者说是也挺善于去做一些多任务，然后多线程的一些工作的确实可能思维方式包括工作方式，跟宸汐缘有天然的这个差别会导致这样的原因。
我觉得这一块其实最关键的是需求改，我是可以接受。
的。
但是不要一改就马上实现。
因为对这就是一个进度管理的问题。
对，因为很多时候我们手上可能就还是我们刚才说那个问题。我有项目官有项目管理的情况下，我可能确实有一些高优先的事情去做，但问题是我们可能碰到需求变更的时候，可能这个是已经拉到非常紧急的，我就不得不一次又一次地去打断我的工作流油来去做这件事情。所以这个事情我觉得或者我们可以再去改需求的时候可以有一个预期，比如说可能他现在正在忙对吧，我可能说我不要求你当现在给我做出来的，但是你可能给我一个合适的预估时间，我好去跟客户去沟通，我说我大概什么时候可以上对吧，可能这样会好一点就害怕，比如说产品经理在对在群里跟客户说没问题，明天上线，结果这边产品这个研发一堆需求做不完，这个时候就尴尬了，你们发现没有，他用了一个非常高情商的说法来说这件事情，但是有的时候我遇到的程序员往往是一些，表达上，各方面他可能考虑的并不是特别多的。
这些程序员云逸有没有遇到过这种程序，经常以一种低情商的方式来回应。
你恶意遇到过来讲讲他们的故事，他可能不会这么直白，但是它潜台词就是你不懂这个很复杂，然后这个没有那么快能够实现，或者她会觉得说就是，这个需求怎么可以这么对吧，点，然后会有这种抱怨声会比较多。
刚才我们在节目之前聊聊天，我觉得我们还是那种高情商的程序员。
客气，那个对关于这一点包括互相的沟通吗有一些体会那个，程序员，是一个这种，我们这种大脑是疯狂运转的，比如在写程序的时候，特别担心特别怕自己被打扰，然后我们其实每天更多的其实会面临的更多的是程序的问题。程序的 bug 程序如果 bug 如果修不掉，那我们会很焦虑。然后又有很多业务的问题，那个有很多客户的问题，我们可能需要修，那么我们还有卡一些 deadline 这些问题那个业务，然后还有这个时间，这三方的压力会导致可能很多程序员会变得非常的暴躁。
其实他们不是，不想好好说话，他们其实如果真的能有，就是比较在比较放松的情况下，她们还是挺愿意沟通的。但是由于是这种长时间，而且是常年在跟一个没有情感的东西打交道的时候，会就是说慢让你变成一个看起来不太会沟通的这样一个人对我觉得这点，就有之前一个梗，就是产品经理怎么去跟程轩爆bug，你可别跟程序员说哥们你有 bug 了，你得说，哥们这玩意怎么不是这样，对吧，你说有 bug 了，成全第一反应你还有吗？
试试对吧？
但是你要说，哥们这个怎么不行，他内心就开始想，**，我是不是写出 bug 来了，
对咱聊会这个话题。
我觉得刚才我们讨论了很多矛盾的根源，那其实我们今天刚想讨论的，并不是说大家互相吐槽这件事情其实我们更想讨论的是我们需要什么样的产品和技术的团队，以及我们怎么补齐在沟通当中的这个短板，因为我会觉得说其实不同类型的公司或者不同的产品，其实对于产品经理的这个素质要求是不一样的，但是会有这几个共性，或者说是基本的条件。
就是首先我是觉得产品经理可以不懂技术，真可以不懂，但是必须要有的是边界感，就是，我以我自己来举个栗子好了。我刚才说到我其实是从一个。其实也是一个完全外行人进入互联网的角色。那我也不会coding，我唯一会用的就是metlife，那在呈现眼里，这不算 coding 对，但是我是一开始如果太容易了，这些说法那我加入互联网公司的时候的第一个工作职责其实是 CEO 助理。
那我是怎么从 CEO 助理逐渐地去深入到这个，产品的管理定义这个角色当中的其实我就是因为我过去是学自动化的，那所以我就是很清晰，当时我们在设计对话机器人，那我就是很清晰的知道，我们每一个模块每一个算法，它的边界是什么，它的极限是什么？我可以通过什么样的产品设计交互的体验以及数据运营的方式，把技术边界在有限的范围之内，把这个产品的商业化的价值发挥到最大的极限。那我觉得这个是一个从算是技术手段上，或者说是一个，战术上我觉得是一个必要的一点，那第二个，可能同理心了。我觉得这个同理经济，包括就是说对客户或者是对需求的这种理解，当然也包括对于就是每天面对着机器的程序员的理解就是要会沟通。那第三个的话，我觉得是领导力了，就是其实大家刚才一直在说怎么提需求怎么接需求，你看提根西这两个词就把这个关系变成了一条流水线上的一些分工，或者是更有更说得更简单，粗暴一点就是甲乙方那所以我觉得如何让这个看起来是一个产品经理的个人决策，变成一个集体，愿意向同一个方向去努力，对给大家制定一个共同目标。
我觉得这个特别重要对，然后就是集体决策让所以我觉得这三点可能是我觉得从这个就是比较宏观视角去看比较重要的，那剩下的就是一些技巧性和学习能力的问题了，在能力上包括你对于整个就是市场分析的能力，洞察的能力，然后时刻保持好奇心，能够去对整个技术趋势能够有一点点的感知。那然后就是包最重要的是沟通能力了，因为其实很多时候。然后，程序员在表达你的需求不清晰的时候，其实是你的价值传递没有表述清楚。
对，就是你没有真正得告诉程序员，我的目的是什么，而是告诉你把这个需求给我实现了对或者我再解决什么问题。
我可以说一些我的个人的体会，其实我之前那个也是会感觉自己，不会沟通，情商低，每天也只会写代码，其实这样这个状态其实有持续了好几年，从毕业之后，大概有前五年时间基本上都是每天在做，比较重复的一些事儿，因为为什么会这么想，因为一方面其实很多程序员的性格都偏内向，他其实本来就不太希望去沟通，你给我一个电脑，你给我一台手机，我可以办个月不出门，那个这都是程序员其实比较想达到的一个状态，一个境界对那个，但是后面的话我会发笑，但是我不是说这样不好。其实我们也有认识很多人，那他真的是有非常深的技术追求他，甚至每天可以在研究比如说开源代码可以通宵的去研究，对于技术非常痴迷，他认为是说我能够创造出来一个，比如举个例子操作系统，可能能够给自己带来的愉悦感，超过跟别人去沟通，或者是说交付一些就是具有很具有商业价值的东西。那我觉得这种人他其实在进入这块它其实沟通不好，他也对于社会也能对于这个或者是自己，也带来更大的一个价值。
这一点我觉得我是这样的，所以我们会强调是说在第五年的时候我有思考过，就自身的一个基础的发展的路径，因为现在比较典型的其实就是程序员吗，那个有很多人能成为一个技术专家，他就是说他其实可以沟通不算特别好，那他只要能把技术给做的非常深入，做到行业的第一，也可以，那么第二条路其实就很多人他会到达一个瓶颈，就是说比如说那个会有很多焦虑感，因为它自身在技术这块没有很高的追求，那么到了一个时间点，他就会觉得是说。
现在有这么多年轻人，他们又能熬夜又能这个加班，反正就是 996 或者是 997 都可以，那么事实就是随着你程序员年纪越大，那他的经历可能，就不太够了，所以说它会有那种所谓的程序员式的焦虑，就是我的学习能力跟不上，我这个身体又跟不上，那么我很担心会被这个行业，或者会被社会所淘汰。所以这个时候很多人他如果没想清楚自己自身未来的发展的话，那就会比较焦虑。
那我个人是在这个第五年的时候有考虑过，所以目前我觉得程序员其实还是可以通过，比如说学习新的东西，包括沟通，包括一些行业知识，那他可能去可以实现一些转型的，比如说一个行业的技术专家，这些我觉得也都可以的，所以那个还在码代码的程序猿确实可以根据自身的这种实际情况，可以看看，自己的未来可以往哪个方向发展，更适合自己，所以确实我认为是说，每天陷入不在，学习新的算法，学习新的技术，然后不停的刷一些题，那个不一定对自己来说是一个很好的选择。
对，我觉得这一块其实还有个很重要的点，就是我们一定要意识到我们的各种语言也好，各种技术也好，它其实只是我们的工具，它是我们解决问题的工具，你工具用得再熟练，其实你也只是里面很小的一个部分，我们更多的其实是因关注这些技术以外的我们去和人协作的这个部分，因为这些东西是可能真正能够产生价值的一个部分。这就像一句名言说的吗，你可不要用战术上的勤奋去掩盖你战略上的懒惰，对吧，我们可能觉得说，那如果你不停地去学语言，但是你不去关注可能更有价值事情那这个事情可能从某种意义上来说，就是用在用战术上的勤奋去掩盖你战术战略上的这样的一个懒惰。
对，而且这个话题有点大，就是其实已经讨论到了这个程序员的自我成长这个问题。这个话题可能会在我们的这个栏目里面不断地被提及，甚至可能我们会拿出一个专门的节目来跟大家来讨论。因为我们知道这个程序员的所谓 35 岁危机，这件事情其实在这几年是愈演愈烈了，然后，但是我们会发现最近，像某个老师，老高，他们也在招人，然后再看简历，她们给我一个反馈就是，我们看到了确实有很多，在 35 岁被公司淘汰的这些人回到社会上来重新找工作，但是往往这些人我们如果看他的职业经历的话，可能更多的就是刚才嬷嬷说的，他在那写代码研究算法，其实它并没有达成他自己与真实物理世界的这个连接。
所以在这个时候，你如果想给自己设定一条成长路径的话，人这个因素你是永远绕不开的，所以这个就对他的这个职业在职业的成长其实带来了很大的一个混账，但是今天我们聊的其实产品的话题，这个扯的有点远，所以咱们把话题拉回来。其实有的时候我们聊产品就不得不聊到另外一个跟产品密切相关的话题，就是运营。运营这件事情，其实在这些年大家对运营可能有了一些又不太一样的认识可能，这些年我们再说增长，我们在说私域流量等等，这些可能看上去都用烂了的一些词，但是在这个背后，我觉得体现出来的是大家在产品利用上的一个焦虑，犹如这个产品做完了，我们怎么把这个产品真正地投向市场，让用户把它用起来，我们能获得愈来愈多的这些用户和使用量，在这个时候往往运营的角色就提出来了。当然在这个时候，我们会发现有两种观点一种观点，是产品经理就应该了解运营，甚至这个运营的过程。产品经理应该完完全全地参与。那另外一种观点是说运营应该是一个专门的岗位，他应该是这个产品的使用者。我不知道小白你作为一个跨界工程师也承担了很多运营的任务，你怎么看这个事。
对于我来说，我还是会更倾向于运营是单独的一个岗位。原因其实并不是说产品经理不能去做运营的事儿，而是说我们如果想把一个事情做得足够极致，你是会要花很多精力的，这个时候如果你想去兼职去做，其实是很难去做好的，所以我会更倾向于我们有一个人，他去专职去负责运营这块，因为刚好，我上一份工作就是干运营的，所以说，我在这方面其实还有蛮多的，感受就是说其实我们会看到现在大家都在做各种各样的产品，我们其实会希望说我们的产品去产生价值，但说句实话是我们去看，无论是工程师也好，还是产品经理也好，其实他们可能不会去关注我们如何去获得更多的用户，或者说我们如何把这个产品去放大它的声量及那这个时候其实就是运营要去思考的这个点。
当然运营这块其实也有很多的考量和讲究，比如说我前几天还写了一篇文章，就说我学到的关于运营里面最核心的几个点，就比如说好那运营是什么，运营是对资源的调度，我如何去调动我的资源，把我的这个产品的声量放得更大，去触达更多的用户，对吧，那我如何运营，就是如何去让产品和用户之间的距离可以拉得更近，那这些都是我在从事运营当中去觉得一些比较有价值的点，或者说我们作为一个运营，我们应该去感知自己的工作应该是什么样的。
但是我其实在工作中也会发现有很多问题就是运营，很多时候他在接触到这个产品或者接触到这个需求的时候，已经到了最后七这个产品都实现完了。那这个时候我们其实就会发现运营其实就很难做。或者说我们运营为什么到了最后我们又查出来要改需求很大的一个点是说产品经理他再去做的时候，他可能不会去考虑说我如何去设计我的一些运营的指标来去为我的这个产品增长去做贡献。
对吧，那但是我们运营很多时候我们的工作，其实是基于数据来去评估我们下一步要做什么，如果这个产品在实现上没有去加入这部分的能力，那我们就不得去不去逼研发说你给我加 1 个指标，方便我去看说我们的这个产品到底有多少用户在用他们的留存率是什么样的。那这些时候我们会觉得说，那如果运营能够在更早期去进入到需求的时候，那可能大家都会轻松一点。
对吧。
我可能一开始我和产品经理说，比如说这个需求，那我觉得这几个点可能需要给我们加一些指标，方便我们后续去做增长，这个时候，陈那个研发一起直接给做了，大家可能直接就往后直接去推进了，研发出来，运营帮助去产品经理帮助严，研发去把这个事的声量扩大，然后我们用户，我们一起去获得反馈，这样的话，可能我觉得大家其实可能都会更有成就感，因为你也可以看到数据你也知道。
我这个功能有多少人用了对吧，那大家可能都会很开心，对你说的这一块，可能更多的是数据运营和增长这一块的事情对，但是其实我觉得，有的时候更多的是运营这边的负责人。他并不知道除了数据以外，还能做什么。
块，我觉得那可能还是这负责人的问题，因为我干运营其实只干了一年，因为我是从研发跑到运营那边去转岗了，我去干了一年运营，那这个时候其实我自己就会发现说，就还是我刚才说的问题，就是运营的核心是拉近产品和用户之间的距离，但你如果从这个大的目标去出发，其实里面会有非常多可以做的事情，比如说我们说刚才提到了私域流量，这个什么，这是用户运营对吧。
对那还有比如说我想要去拉近产品和用户之间的关系。那文档其实是一个很好的方式，尤其对于 to b 产品来讲是吧。对这个时候文档是什么。我们叫内容运营。对吧。还有，有时候我们可能说，我们想和用户关系更近一些，我们会把工程师拉到线下去，和用户做线下交流，那这个是什么就变成了活动运营。其实我们想要拉近产品和用户之间距离的路径有非常多，条大路，通罗马那每一条路，你只要做了细，它就会成为一个独立的细分的运营岗位。
对，所以我总觉得就是现在很多程序员会遇到一个麻烦，就是产品经理提了一堆需求，一会运营的负责人又来了，来咱改，咱家数据咱家个买点，我要知道数据往往都会是这样，所以我总觉得是不是应该让运营的，相关的这个工作要提前介入到产品的这个生命周期管理里面去，而不是说我产品出来了。
我在想我怎么去运营这个产品，对，这个是肯定还是越早介入越好，因为大家一起去思考这个问题，省得大家最后都返工。还有另外一个问题就是其实运营也要懂一点技术，就是有很多时候这些增长的点，其实并不一定非要在自己的产品里埋点，其实有很多埋点的方式，可能我可以借助一些第三方工具，我同样可以统计出来数据，那这个时候，可能
开发之间的这些关系，那我们可能刚刚我们会把这些视角都放在一些国内的公司，那我们其实也知道声望是一个硅谷范儿的技术公司是吧。所以其实也想聊聊，在海外这些互联网公司或者是产品型的公司，在这一方面他们是怎么做的，那这一块云逸有什么经验和以及或者说跟他们沟通当中你觉得有一些什么不一样的地方。
对那分享一下，就是我可能虽然没有在海外工作的经验，但是有过两段比较硅谷范儿的公司的文化的经验，然后我先说一个小事，就是其实有一段时间很流行，应该说至今还是八，大家都很喜欢去再招产品经理的时候去套用 google 的这个产品经理的面试题，那 google 特别喜欢问的问题，就是比如说，一个房间里能装多少个网球，或者说一个 100 层的摩天大楼，你要装多少个电梯？
那。
其实这些问题它没有标准答案，但是他其实在考验的就是候选人。你的工程思维思考过程对你的思考过程。你的调整条件设计，你的建模过程，那在这种郭思，所以我觉得这个可能是在硅谷的工程师，在硅谷的产品经理，他的工程思维就是一个必要的特质。那另外一个，就是商业思维了，就是其实硅谷也有非常其实硅谷有非常多工程师转产品经理的，然后也会也会有需要一些 nba 背景的。所以我觉得硅谷的公硅谷的产品经理可能会对于这样的对于技术有认知，然后对于商业有背景。然后一些多元的能力在身上一些特质会非常的强调。
那然后再说回我刚才想说的就是硅谷团队的这种文化，其实我觉得深网就是一家非常典型的这样的公司，就是我们是一个被要求，你必须在你的专业领域为你负责的。那我记得我刚加入神往的时候，那个我的老板就跟我说了这么一句话，他说在声望。如果是 1 个tony，赵斌本人我们的 CEO 提的需求，你没有经过判断，或者说是 A 经过你的分析而直接地把它按旧题给程序员做了，最后如果这个产品失败了，是你的责任，那所以在声望就是每个人都会就我觉得这是一个非常幸运，非常有挑战的事，你都会在自己的专业领域有非常强的话语权，包括刚才提到的项目，基金经理在我们公司也是非常有话语权的，对，所以就是如果这一硬广一下，如果说你对于这样就是，多元的文化，然后比较比较这个平平就是扁平化的这种组织，然后能够希望有一个土壤去发挥你的专业能力，接受这样的挑战和文化的话，欢迎加入身亡。对。
没错，因为我总觉得在海外的一些公司，其实我也跟，因为经常去这些硅谷的公司去跟他们聊天，然后我们会觉得一部分公司，做得更极端一点，就是说我们没有产品经理这个职位，我们的职位都归于运营和增长，那产品经理应该是三方，共同定义的这样一个产品，而不应该有产品经理这样一个专门的角色。而另外一些公司，就像刚才云逸说道的，他有产品经理，但是他对产品经理的要求会非常高，就是至少你要有工程或者商业的，这样相关的背景，你才能去胜任。这件事情其实是这样，所以跟国内就不太一样，国内是什么情况？
大量。
咱不点名是吧，大量的互联网公司的产品经理基本都是不是技术条件出来的，因为很多时候程序员其实不太愿意去做一个，我们说产品经理或者是运营这样的岗位，因为他们会觉得说做这个其实不如我做工程师的这个社会地位，各方面会更高一点，所以大家可能会觉得说，这个转转行的，这就是逃兵可耻，但其实大家可能更多是到了一个新的岗位去，实现不一样的价值。其实没有什么高与低和对于错之间的这样的一些纷争。
对，尤其在国内还有这个鄙视链的问题，就是我总觉得，我写代码的，我去做产品经理是不是有点降级了，有点降级的感觉。因为在中国的文化里，总在讲就是这个怎么想学好数理化，走遍天下都不怕是吧，他总觉得理工科就会高人一等，而我回到了产品经理这个职位，我去做这些相对偏重于文档文科的这样一个事情，觉得，这是不是跟我的预期有一点不符，对这个我觉得可能是一个文化的问题，就是这几年大家受到的这些熏陶，从我们小时候可能就会选受到这样熏陶。你应该学理工，你应该学理科等等，这种我觉得会有这样一个感觉。但是说回到这个经理，产品经理的职责其实是要解决一个实际问题的，别管是商业上的问题，还是说，是一个个工程上的问题，它本身是要解决一个问题的，所以这个时候，在国内某些公司里面，我们看到的一些乱象就是往往产品经理的这个职位其实是有一点模糊不清的，甚至我们有过一个段子。
产品经理过来给程序猿讲了一通说你别说了，你就告诉我抄那个经常，尤其在 to c 的产品里经常会遇到这一类的问题，所以感觉上就是大家在对产品经理或者是在对产品经理与程序员的这个沟通的定位上，往往会出现一些偏差。你觉得。
我觉得很多时候是我们其实可能对于产品经理这个东西过于神化，但是到了具体做事的时候，可能又会过于细节，这个可能很多时候要么就是我们可能对这些人的能力要做一些提升，它能够同时思考多个方面，要不然的话我们可能确实需要去明确，有些人他可能确实不适合去做，很宏观的事情，你可能让他去思考一些细节，然后把这些宏观的人来去负责更加高级的这些，比如说我们说商业实现也好，或者是，更宏观的思考上，可能我们还需要对于产品经理这一个岗位进一步的去细分让大家去做，更适合自己的事情，对一个就是职能上的戏份，一个就是能力上的戏份，可以是这么说，比如说我给你举个例子，我去硅谷去网飞公司，王菲那个公司，大家最近也是非常推崇，往往非的这样一个企业文化，我相信你们也都听说过，就是我们只招成年人，我们个人要对个人负责，等等，他提出了很多的这种企业文化，当然网飞它负责增长的这个同学，就是我们的。
听友，然后所以我们过去跟他聊过这个问题，我说你们有产品经理吗，他说我们产品经理这个职位并不是说这么明确，我更多的比如说像他的职位，他是一个既不是技术出身，也不是商业出身，他是数学出身，他是搞数学的，那他负责的工作就是每天统计这些数据，用数据做出渐渐出模型来，然后为增长服务，就做这么一件事情，但你说他是程序员吗？可能不能完全的定义，那你说它是产品经理吗，更不能这么定义，但是往往最后做出来的工作成果其实是为这个产品的增长和往前走去服务的。所以我是觉得可能我们也需要类似的这些更细分领域在产品上的一些定义，而不是我们很笼统的说这是产品经理应该干的事情。那其实产品是一个非常泛在性的定义。实现 UI 是一部分。
增长是一部运营，是一部分都不一样，对很多时候我们的这些工作，我们说给他放一个人身上不是说不行，但是如果你真的想要把这个事做好，就是一定还是会有专精的。其实这个事，我们在除了产品经理以外的很多领域，我们都看到比如说我们说工程师，那工程师前端有的是后端，然后包括前端的可能我们也会分不同的客户端到了客户端层面，我们可能还分比如说像毛毛做的这种实时音视频对吧，那你可能你让毛毛去做GUI，可能就又不合适了，但是我们会看到说产品经理，大家脑门里脑海里就四个字，产品经理，你很难去想说，产品经理是不是还有什么一些具体的细分。我是觉得产品经理这个职位，未来的细分化可能会越来越突出，对现在大家定位模糊，导致你很多时候做事的时候你也不太明确，到底什么是我该做和什么是我能做的事情，反正都坚持做，都兼着做这个事儿，很多时候可能就做的不。
太给力，甚至说可能这个时候就出现了跟开发岗的一些冲突。是的，因为开发党更没法反而理解你最终的决策过程到底是怎么做出来的，你只是让我说今天，你把这个图片给我变成绿的，为什么他说不出来是吧。
很多情况，但是这个例子有点极端，但是很多情况下都是这样，我没有办法去让开发的同学完整地去理解我的意图和思路，你就让他去改，但是你没有理解到他，他也不是一个机器，我们总说这个程序员，没有产品思维或者程序员就是一个没有感情的机器去实现业务的机器，但是其实并不是这样的，很多程序员的脑海里，其实它是有一个对产品概貌的印象的，他也是希望这个产品能够被推动往前走的，但往往这个时候，产品就是我觉得国内这一说的又多了，我总觉得国内产品经理这个词的定义是有问题的，所以他 12 级以上的才能叫经理以下的全球产品策划别重要就是经理这个词，往往给了某些同学一个不切实际的高级感的定位，这个时候，他再去让开发这一港去，你去实现一个东西或者怎么样开发岗就觉得很不爽，就是这个不是在平等的对等的语境下的沟通，往往也会出现很多的问题。
讯不是改了吗？
所以我觉得这件事情应该说你首先作为产品经理，应该去理解开发者程序员对这件事情的以前同步这件事情中一个流行词叫对齐。是吧，你们俩先把这个是对齐了，然后我再说说这个具体的策略实现，这些东西可能在沟通的过程中就会好很多。我感觉是这样，这也是我们津津乐道这些年实践下来的一个比较重要的经验。
大家知道我们津津乐道的程序员。产品经理其实也都是有技术背景的，包括伯伯，其实它也是计算机专业毕业的，所以在这个时候我很容易地把一些策略性的东西我们先商量出来，这个东西的目标是什么，我们再说怎么来实现。对陈经理也要利用程序员的这个聪明才智是吧，他也在想事情，你不能把它当成一个机器，程序员自己也不能把自己当成一个机器，这刚才我聊到了这个还是有一个职业成长的这样一个问题对，所以我倒是觉得这个互相理解蛮重要的。
我一直的原则就是你产品可以不懂最细节的技术，因为最细节技术其实不应该是你去懂的，应该是工程师去搞明白的，但是你一定要去了解技术的边界，因为技术的边界可以确保你不会去提出那些完全不可能实现的需求。对吧，当然，我也有一句我自己名言，我就说没有我实现不了的需求，只要你给我的资源足够对吧，有什么不能做的吗？有钱咱们就什么都可以做，但是有了这个技术的边界感。你会去做很多事的时候会更加轻松。比如说我和宁绍老师，我们俩合作对吧，那他以前它是品牌设计师，对吧，用户体验设计师背景。后来他也去研究了，比如说什么产品设计，产品管理，还做了产品总监，但是他自己，就是在不和我合作之前他自己也去学了前端 ppr 数据库一些技术也可以自己去改一些开源代码，然后去搭建自己的网站和产品。
有了这样一个好处，这个经历就让我们俩交流，有一个非常好的点，就是他知道这些技术的边界是什么，对吧，他可以去提出一些合理的诉求，那可能这些诉求对我来说可能还是有实现的成本。但我们都知道这个事儿可以做，无非就是说我可能花多长时间的问题，那对于他来说，他知道这个东西什么是边界，那就可以让我们合作起来，效率更高，包括我们其实给到更多的不管是设计师也好，还是产品经理还是其他的职能也好说技术这个东西，它其实就像我们在中国去学英语，对吧，你不学英语，能不能活还是能活的。
但是你学了英语，你可以和更多的人去沟通，去合作去交流，那这个时候我们的效率各方面都会有所提升。如果你不会对吧，那你只能和中国同学去沟通，那比如说我们说放在声网这个公司对吧，你只能和中国本部的同学沟通，那海外公司的同学们，你没办法沟通，那这个时候你们的合作效率一定会非常的低。
所以我会觉得说，如果你不是一个技术岗，那我还是建议你去学一些技术，知道技术的边界在哪里，这样的话大家可以合作起来，效率更高，然后，水平也会更高。然后如果你是那个先掌握了技术，或者说你是那个能够去掌控别人的这个思路的，你知道别人是在想什么，那你就可以去控制最终的这个合作的效率。
对，而且在这里面就是你爽，这个例子也给了我很大的启发，就是在跨界思考这个话题上，就是往往我们去和很多的同学沟通。你觉得跟他沟通的非常 OK 配的这个人往往它是具备一个跨界思考的习惯的对，这个是不？
就像我们之前在群里聊吗，就是有同学说，我就觉得和我那些年龄特别大的朋友聊的特别好，然后旁边有人就是就甩了一句，你觉得聊好是吗，那其实人家向下在兼容你对吧？那我们放到跨界，这个事情就是一样的，就是你觉得你跟人家聊得好，那是因为人家跨界跨到你这边了，所以你们聊得好，如果他没胯间，那你们俩搞不好还得掐对，或者甚至说两个人都有这样化解思维可能沟通起来就会更加容易。
是的，对，再有一个我觉得还是一个好奇心的问题吧。
对，很多时候我们的同学其实没有那么的好奇，大家觉得可能就是我把我门前这个自扫门前雪，我把我门前这点事给干了就 OK 了，但是这个事，就是说如果你只做你自己的事情，就像刚才毛毛说的你就是那种最强的专家，在这种情况下，我觉得OK，但是我们也要认清的，现实是我们大部分人其实是没有那样能力的，这个时候，这种好奇心，这种会计思维其实是可以让我们去把事情做得更好，我们可以解决更多的问题，而不仅仅是简单的说完成我们的任务而已。
对，因为我总觉得这些年来我们有很多的关于程序员和产品经理的烂梗，你今天不想提一出来，就是觉得太俗了这件事情，但是，在实际工作当中，别管是大公司还是小公司，而且小公司可能这些问题出现的更深一些，因为它的管理边界比较模糊。那在这个时候，真的是我觉得从今天开始，程序员和产品经理应该有一个非常好的跨界的沟通，或者是我们可以教互相理解和共同成长，这才是一个正确的方向。你不要说每天我坐在那就跟产品经理欠着我两百万块钱的事的，咱先对一对咱不，今天咱部队情时候咱今天不要干活并不是这样，因为大家都是顺着一个目标去努力的，你说这种我们没有意义的这个摩擦和内耗，倒是我倒觉得没有特别大的必要，你一定要争个谁对谁错吗？有的程序还是确实是他比较钻牛角尖，我就要蒸了一个，谁对谁错，我就要证明我想是对，但是这个问题有用吗？在一个具体实现的过程当中，在产品生命周期的场合里面，你觉得这个事情有用，我倒觉得意义并不是说特别大，但是今天并不是为我们的产品经理说话，但是往往确实是看到了一些在我们日常工作当中看到了一些我们的开发者，不知道是可能是因为从这个网上的这种风气这些，所谓的开发者的这种社区，论坛里面得到了一些负能量，但我倒是觉得这些负能量真的是不利于你成长的。对，反正是今天，不是给大家上课，但是从产品经理这个角度也是这样，我是觉得产品岗的这种细分未来可能真的会是一个趋势。
好那最后我觉得，最终我们可能还是给大家是我们说美好祝愿，就是对于我们每个人来说，我们都希望大家能够借今天这个机会，其实大家去听一些我们不同岗位的视角，然后大家可以聊一下，别人知道一下别人是在怎么想的，那我们当然不能听见，就算对吧，我们听了，但是大家也可以仔细想一想，那我自己在工作当中，我能不能去和我的这些趴在哪对，我得和我这些伙伴们，我们一起去把事情给完成了。
很多时候，我们的争论是源自于说我们没想清楚什么对我们是最重要的，如果大家一开始我们把我们的目标对齐，对吧，我们今天就把这问题解决了，好，那我们所有事都对事不对人，这个事其实过得很快，我们没有那么多可以争论的点，因为事情是有对错的人的话你想去评判这个事其实还挺复杂的，但如果说我们的关注点还回到世上，那其实我们可能都不需要去开一个很长的会，我们可能几分钟，大家把逻辑一书理清好，这事就可以开始干了。
对，这也是我们这档节目的第一期节目。这档栏目的第一期节目，大家可以从我们的第一期节目里面听到一个风格，就是我们可能不会在节目里讨论一些非常高大上的理论技术的一些专门的技术。因为这期节目我觉得是给所有人听的，而不仅仅是我们的开发者，对，所以在这个过程当中，我们希望通过我们的节目，真正的以一个比较接地气的方式跟大家去做一个有效的沟通，或者是一个人的人文和文化层面的沟通，而不是一个技术和代码层面的沟通。所以在我们的节目里可能没有高大上的各种产品。程序的一些理论，我们讲的就是人，我们讲的是人与人之间的沟通和交流，这个才是我们别把人生节目最重要的一个目的。
对，当然大家如果觉得说有什么东西，你可能平时在工作当中不太好说，那也欢迎大家告诉我们，我们来去帮大家把这样的人拉到一起，我们一起去听一听别人都是怎么想的，对吧，那我们去听一听别人对于这个世界的看法别人对这个问题的看法，那对于我们自己来说也是触类旁通。我们可以去有一个更好好的方式来去解决这个问题。
没错，如果你想参与我们的讨论，可以加入我们编码人生的听友群，大家可以加微信号 dao 约 60301 在添加的过程当中，你说，这个认证信息你就写，我要加编码，人生的听友群就可以了，我们会把你拉到群里，然后我也希望，这档节目是我们与听友一起众创的一档节目。行。那我门的这第一期节目，算是就跟大家聊到这里。简单的聊一聊这个产品经理和程序员的battle。然后也希望这样的风格我们可以持续下去。
大家如果对我们的一期节目有任何的意见和建议，也可以通过各种各样的渠道告诉我们，大家也可以从各大的音频平台来搜索编码，人生这四个字来加入我们的节目，来订阅我们的节目编码。人生那声是声音的声，大家可以搜索做这个，建议大家可以单独的去订阅这样一个栏目，因为在这个栏目里面的我们的更新是最新最快的，因为，我们这次的首发季有三集节目会一起推送给大家，大家在这个栏目里面就都可以一次性的把这三期节目都听完，对一次听过瘾。一次听过瘾，然后也你也可以加入听友群一次喷过也是吧，行，那我们的这个第一期节目就先聊到这里，感谢大家的收听，也感谢二位嘉宾的参与。
好，谢谢。
我们下期节目再见拜拜。感谢您收听本期节目，同时你也可以收听我们制作的更多博客节目，科技乱炖，品质生活津津有味，厂长来了拼娃时代串台科技先生和蓝海之下，在您收听的平台上直接搜索即可找到以上这些节目。如果您觉得我们的节目对您有帮助，欢迎已购买周边产品的形式来支持我们关注我们的微信公众号，津津乐道播客天津的津欢乐的乐道路的道进入周边产品菜单购买即可。如果您愿意参与我们的更多讨论，可以加主播的微信号。 dao 约 6030 要加入我们的听友群。本节目录音设备由罗德麦克风友情赞助。
