问题来源：
在另一个话题中
佬，我想问下你对餐品经理的画像。我自己看到的，这个职位就是统筹资源 转述需求，但是最多的还是催开发和测试。但是之前发的帖子“为什么不让技术领头人替代产品经理”的帖子中，很多人都反驳说技术人员不懂产品，不懂需求是问题，也即技术人员转产品是较难的。
但什么是“懂产品”，这太抽象了，我不知道他们是利益相关，还是这是客观事实。
三个角色一锅粥
很多公司——尤其是那种人少事儿多的团队，经常把三个角色搅成一锅粥：产品经理、客户经理、技术头儿。
听着像三路人马，实际上呢？
一个萝卜三个坑，仨人共用一个脑子，只是脖子上挂的工牌不一样。
老板传话：“客户催得很急，想要这个功能。”
客户经理赶紧陪笑：“没问题，这就安排。”
产品经理吭哧吭哧记档：“插个队，排上。”
技术头儿两眼一黑：“这破玩意儿没俩月根本搞不出来！”
接着会议室死一般寂静。老板轻飘飘甩下一句：“不管，客户等着要。”
得，乾坤大挪移开始了。
产品经理去圆那些根本不合理的文档，客户经理去前线疯狂安抚，技术头儿一边骂娘一边拆活儿、改接口、随时准备背锅。
活脱脱一个取经团队，只是没有白马，只有半夜还在闪烁的钉钉群。
这三个岗位到底有啥区别？ 说白了：产品经理琢磨的是“路往哪铺”，客户经理操心的是“金主爸爸还给不给饭吃”，技术头儿盯的是“这路铺完明天会不会塌”。
但在现实的中小公司里，边界一糊，产品就成了传声筒，客户经理就成了催债的，技术就成了全栈救火队。
最后做出来的东西就像一锅东北大乱炖——啥味儿都有，但你根本说不清它是道什么菜。
产品经理要干什么？
产品经理的活儿，真不是画画原型、写写PRD，更不是在评审会上提一句“这个按钮能不能再灵动一点”。
那都是皮毛。
产品经理最难、也最值钱的本事，是下刀的准度。
什么必须做？什么打死也不做？什么需求看着像肉其实是毒药？这些判断才是立身之本。
合格的产品经理心里盘算的是：这功能为啥存在？给谁用？跟公司大方向对不对得上？会不会把系统搅成一坨意大利面？
而大多数二把刀产品经理操心的是，这按钮搁左边还是右边，这提示词能不能再亲切点，这需求客户明儿就要验收，研发今儿能不能先怼上去，反正是客户要求的。
这情景，谁看了不PTSD？
产品经理最难的地方，是敢当坏人。
客户说要，销售说要，老板说要，同行好像也有了，群里还有人甩张截图说“看，别人家都做了，咱们怎么不做”。
这时候产品经理如果只会点头，看着是挺合群，其实是推着产品往功能垃圾堆里滑。
多少产品后来变得臃肿、卡顿、四不像，不是研发突然手潮了，也不是设计脑子进水了。
根因在早期，每一个看似不痛不痒的小妥协，都是给系统的柱子抽支块。
今儿给张老板加个专用字段，明儿给李总开个定制流程，后天给王处插个独立审批。
过个一年半载，系统就成了“需求考古现场”，新人点开后台，表情跟看天书似的，二丈和尚摸不着头脑，“我靠，你到底在说啥？”
产品经理该干的，是把客户嘴里说的功能，翻译成背后藏的问题，把问题提炼成方案，再把方案收敛成一个能打的产品功能。
客户说：“我要导出一个特别复杂的Excel。”
三流产品：收到，新增“复杂Excel导出”功能。
普通产品可能会多问一嘴：您导出后给谁瞧儿？为啥系统里看不了？离线还要加工啥？这里头哪些字段是真有用的？（咱老北京的
就是，说话就一个字，地道）
好产品最后可能发现，客户真正要的不是Excel，是一个能留底、能给人看、能定时发送的经营报表。
这就是产品经理和需求搬运工的云泥之别。
一个只是在兢兢业业搬砖，一个在琢磨为啥要盖楼。
客户经理该干啥？
客户经理这词儿，各家的叫法五花八门，有的叫客户成功，有的叫大客户经理，有的叫解决方案专家。
衣裳可以换着穿，但底层的活儿都差不多。
客户经理负责的是，让客户觉着这钱花得值，让合同能续下去，让关系别凉，让有了麻烦有人扛，让做出来的价值能被看见。
这个位子，天生就是站在客户那边的。
客户今儿上线卡壳了，他得扑上去。
客户老板拍桌子了，他得去灭火。
客户提了个听上云山雾罩的需求，他得先稳稳当当接住。（雇了个人形GPT）
客户明年还签不签，他得提前闻到味儿。
客户群里半夜有人吼一嗓子“系统又崩了”，他得比研发醒得还早——虽然很多时候，研发才是那个被从被窝里薅起来的。
客户经理的看家本事，是伺候人的本事、把预期管住的本事、证明你有用的本事、四处调兵遣将的本事。
他得知道客户那边谁拍板，谁干活，谁看热闹，谁虽然天天登系统但其实是徐庶进曹营——一言不发。
他得明白客户买这玩意儿，是为了降本，为了增效，为了合规，为了面子，还是为了让大领导觉得我们部门终于也数字化了。
他还得知道，哪些问题必须立刻摇人，哪些抱怨可以顺顺毛，哪些需求背后藏着不续签的坑，哪些需求其实就是用的人今天心情不好。
所以客户经理常说：“您的意思我明白了，我马上去内部协调，尽快给您个说法。”
翻译给公司内部听就是：兄弟们，甲方爸爸举刀了，谁来接一下。
这活儿不丢人，也不简单。很多搞技术的容易瞧不上客户经理，觉得他们就知道催、传话、发长语音、在群里@所有人。
可真正
的客户经理，是公司离钱最近的人之一。
他得知道客户为啥买，为啥犹豫，为啥骂，为啥续，为啥突然失联了。
这些信儿，要是能被产品经理消化了，就是顶级的产品情报。
要是只拿来催研发赶工，那就是催命符。
好的客户经理和王牌销售等同，一人可以养活一个公司。
技术头儿要守山门
技术头儿也容易被误解。
很多公司以为技术头儿就是那个码代码最生猛的人。
手速快，修bug快，线上炸了能顶雷，需求来了能硬扛。
给个头儿的帽子，顺便把开会、评审、排期、带新人、救火、背锅这些活儿一股脑儿全塞过去。
这就像看见一个人能扛煤气罐，就让他去管整个燃气集团。
技术牛，当然重要，但技术头儿真正的价值不是自己撸袖子干得多快。
一个人再能打，一天也只有二十四小时。
技术头儿的核心价值，是让整个队伍能用一个风险更低、活儿更细、更能长跑的方式，把东西交出来。
技术头儿，不是高级码农的皮肤，也不是人肉甘特图插件。
他要干的是把需求翻译成工程路径，把藏在旮旯里的风险摊到桌面上，把一团乱麻的问题拆成能下嘴的活儿，把团队从一人救全场的低级模式里拽出来。
产品说，我们要整个权限系统。
普通开发可能会问：页面长啥样？
技术头儿得问：权限细到什么程度？菜单、按钮、数据行？要不要支持多组织架构？角色能不能一层层往下传？临时的权限给不给？操作日志存多久？老数据怎么挪？接口咋兼容？缓存怎么清？越权的测试怎么搞？
产品说，我们要加点AI能力。
普通开发可能会问：调哪个模型？
技术头儿得问：这AI到底干啥使？给啥料，出啥活儿？说错话、干错事儿了咋收场？慢点能忍不？烧钱能不能扛住？用户数据能不能出域？日志要不要脱敏？提示词怎么管版本？怎么知道它变好了还是变傻了？
这就是差别。
技术头儿眼里的世界，是隐形的成本。产品文档里一句轻飘飘的“需要支持多端同步”，在工程视角下，是账号体系、数据一致性、冲突咋处理、消息队列、离线缓存、新旧版本兼容、灰度发布和数据修复的整套全家桶。
客户嘴里一句“能不能加个审批”，技术眼里的画面是流程引擎、权限边界、回滚方案、通知机制、历史记录，以及未来一堆会追杀自己的特殊分支。
所以技术头儿经常显得煞风景，也经常吵架。
客户经理说：客户火烧眉毛了。
产品经理说：这需求是重中之重。
老板说：先来个简易版顶一下。
技术头儿说：这个简易版以后会变成祖传代码屎山，根本维护不了。
然后全场人盯着他，就像看一个在人家婚礼上提醒新人要不要先聊聊婚前协议的人，有点没眼色。
三者的不同，在于屁股坐在哪
想看清这三个角色，别光看他们写啥文档，开啥会，挂啥头衔。
先看他们屁股坐在哪条板凳上，所谓屁股决定脑袋。
产品经理的屁股，得坐在产品的长远账上。
客户经理的屁股，得坐在客户的关系网和钱袋子上。
技术头儿的屁股，得坐在工程的地基和交付的确定性上。
三个人都听客户，但屁股不同，听法不同。
客户经理听，是为了稳住码头，嗅到风险，推动续签，让客户点头。
产品经理听，是为了找出最大公约数，判断市场风向，提炼出产品的拳头能力。
技术头儿听，是为了摸清边界在哪，盘算实现的沟沟坎坎，把交付的风险掐死在苗头里。
三个人都跟研发打交道，但目的不同。
客户经理找研发，多半是处理个雷，兑现个诺言。
产品经理找研发，是为了碰方案、估优先级、推着产品往前拱。
技术头儿带研发，是为了让方案落地，让代码能维护，让系统别动不动就瘫掉。
三个人都得为业务负责，但心里那根时间线不一样。
客户经理更惦记：这客户这周能不能跑通，这个月会不会投诉，今年底会不会续签。
产品经理更惦记：这个山头未来半年到一年值不值得扑，这能力能不能多卖几家，这条产品线能不能长出翅膀。
技术头儿更惦记：眼前这套架子能不能扛住明年的流量，队伍的本事跟不跟得上，技术债会不会在下一个版本集中爆发，来个大清算。
所以，他们仨是天生的冤家，冲突是必然的，也是不可避免的。
客户经理想着快点给客户个痛快话。
产品经理想先盘盘这需求跟大方向是不是一码事。
技术头儿想先探探这事儿底下有没有暗坑。
冲突本身不叫事儿。
要命的是，公司把三种冲突硬是揉成一团，最后和稀泥说：“大家都是为了客户嘛。”
这话非常的正确，正确的废话。
因为客户有眼下的火急火燎，产品有长远的排兵布阵，工程有现实的钢筋水泥。
三者能重合，项目推进就像大年初一吃饺子——顺顺当当。
三者互掐了，公司的真水平才会暴露无遗，所谓做大蛋糕的时候什么大问题都不是问题，蛋糕不变的时候什么小问题都是问题。
低段位的组织，直接让嗓门大的赢。
稍微上点段位的，让老板拍板。
更成熟的，让数据、战略和现实约束一块儿进来开会，定盘子。
至于很多中小公司，通常是客户合同快到期了，于是什么产品规划先放放，技术债以后再说，“先把这单老爷给伺候舒坦了~~”。（这就是服务业 
）
这也不能一味骂街。
活下去，是中小公司的最高指示。
但你得门儿清，如果为了活下去，身子骨长期扭着，时间久了，筋骨会畸形的。
很多中小公司的产品，都活成了客户经理
好多中小公司的产品经理，干的活儿，说穿了，更像一个高级客户经理，甚至是客户需求书记员。
客户提需求，他得记。
客户要草图，他得画。
客户来验收，他得改措辞。
客户说你们这系统真难用，他马上回去就让研发优化一下。
客户说谁谁家都有了，他立马截图发群里。
这一套流程看着也挺忙叨，甚至忙得脚不沾地。天天有会，天天有需求，天天有文档，天天有排期。
忙到最后，产品经理自己都信了：“那我可太产品了。”
问题在于，这套活儿的本质，是在响应，是应声虫，不是在经营。
中小公司为啥容易掉这坑里？
第一，庙小，客户少，单棵树上吊死。
如果公司就十几二十个客户，其中三五个财神爷贡献了多半营收，那所谓的产品路线图，很容易就被大客户牵着牛鼻子走。
客户一句今年续签得看这个功能，内部优先级立马原地掉头。
所谓的规划，听着是战略地图，实际是大客户点菜单，点啥做啥，没了就换人。
第二，销售和交付的压力，直接会往产品身上压。
没人，没完备的售前、交付、客户成功团队，产品经理就得被迫补位，赶鸭子上架。
售前要去讲PPT，售中要去拍胸脯，售后要去擦屁股，验收要去对材料。
日子一长，产品经理的主战场，就从市场和产品，变成了客户会议室。
第三，老板对产品的理解，还停留在堆功能卖钱。
不少老板觉得，产品嘛，就是客户要啥我们造啥，先落袋为安。
这个逻辑，短期内是捡进篮子都是菜，尤其在项目制、定制化、政企交付的买卖里，效果立竿见影。
客户掏钱，咱就开干，年底回款，皆大欢喜。
可放长线看，这会把一家产品公司慢慢做成一个高级外包，把产品经理做成客户经理，把技术团队做成定制工坊。
第四，缺数据，缺市场研究，两眼一抹黑。
真做产品决策，得靠用户行为数据、市场风向、同行在干啥、商业模型、成本结构和长远打算。
中小公司通常没这些，或者有也没人正经看。
最后，最清晰的信号源，就只剩下客户的一张嘴。
谁出钱，谁嗓门大。
嗓门大，需求就进池子。
那哪是需求池，分明是个许愿池，大家都往里扔钢镚，产品经理在旁边负责捞。
第五，组织里缺一个说不的机制。
在成熟的产品组织，拒绝需求，需要理由、数据、替代方案和一整套沟通打法。
在中小公司，说不经常变成一种风险。
产品说不能做，销售觉得你不挺业务。
研发说做不了，老板觉得你能力不行。
客户说不满意了，所有人开始互相甩锅。
于是，最安全的保命手段出现了。
先答应着。
先排上期。
先做个简易版。
先兼容一下这个特例。
先特殊处理一下。
每一个先字，都是给未来签下的一张高利贷。
只是当时没人觉得要还这个债，当然了以后就要看后人的智慧。
当产品和客户经理串了味儿
第一种灾难，叫客大欺店。
一个大客户贡献了半壁江山，结果他的内部垃圾流程，就成了你们产品的标配。
他们那有五级审批，你们也整上；他们有个奇葩报表，你们也加上；他们有个历史遗留字段，全公司没一个说得清啥意思，但你必须支持。
最后产品看着功能越来越多，实际上越来越没法卖给别人。
每个犄角旮旯的功能，都带着某个客户的指纹。研发一改就扯一片，测试一跑就崩溃。
第二种灾难，叫狗熊掰棒子。
今天给A客户搞个仪表盘，明天给B客户整导出，后天修C客户的权限漏洞，大后天给D客户加个诡异的消息模板。
每件事都有充分理由，每件事都能回点款，每件事都急到嗓子眼。
半年后回头一看，产品没形成任何核心能力，只攒了一堆零碎补丁。就像有人天天去健身房搬器械，忙得满头汗，最后没练出腱子肉，光练出了找器械的嗅觉。
第三种灾难，叫产品经理自废了武功。
当产品经理长期只处理客户反馈，他会形成条件反射。
客户说有问题，那就是需求。
客户说不好用，那就是体验优化。
客户说别家有，那就是竞品差距。
客户说领导很重视，那就是最高优先级。
这时候的产品经理，已经放弃判断了，只是在应激。
他脑子里没了产品导航图，只剩一个客户情绪的雷达，滴滴滴叫得挺欢，但图早就丢到九霄云外了。
第四种灾难，叫狼来了。
研发彻底不信产品经理。
研发最怕的，不是产品经理不懂业务，而是今天一个想法，明天一个方向，后天又说“昨天那个先别动了”。
技术团队对产品的信任，是靠一次次稳定、靠谱的判断攒出来的。
产品经理要是总被客户牵着鼻子，研发就会默认：所有需求都可能改，所有文档都是临时的，所有排期都不算数。
最后，工程团队会进入全面防御模式。
能不改就不改，能少承诺就少说，能把风险藏着就先捂着，能做成配置项就绝不写死。
配置越来越多，系统越来越像个弗兰肯斯坦。
最后连产品经理自己都说不清，后台那堆开关是干嘛的。
为啥技术头儿最容易转行做产品
这三类人里，技术头儿通常最容易转型成真正意义上的产品经理，前提是，他愿意补上商业、用户和把话说成人话这三门课。
原因不复杂。技术头儿天然就站在产品和落地之间的结合部。
他知道一个想法是怎么一步步变成系统的。
他知道PPT里一句话背后，是几十人月的血汗成本。
他知道哪些功能看着简单，实际能压垮服务器。
他知道哪些方案现在能跑，未来必定“埋雷”。
他知道研发为啥抵触，测试为啥崩溃，运维为啥沉默不语，客户为啥嫌慢。
一个好的产品经理，未必要亲手写代码，但一定要懂得技术的脾气秉性。
因为软件产品的很多战略级的选择，最后都要落到工程结构的地基上。
你想做平台，就得懂抽象和扩展点；你想做SaaS，就得理解多租户、隔离、计费；你想搞AI，就得明白模型的能力边界、时延、成本和风险。
技术头儿转产品，有几样压箱底的优势。
第一，他更懂柴米油盐贵。
很多产品经理提需求，只看用户价值，不看请客吃饭的成本。
技术头儿习惯看投产比。他门儿清一个需求值不值得做，不能光听客户叫得响，还得看它对系统、测试、维护、性能和团队节奏的拖累有多大。
第二，他更懂边界在哪儿。
他知道系统哪里能撑一撑，哪里是老虎屁股摸不得，哪里短期能绕，哪里一绕就会形成黑洞，未来填坑的代价远超想象。
这种边界感，对产品是无价之宝。没边界感的产品，很容易把产品设计成空中楼阁。图是真漂亮，逻辑也完美闭环，研发看完只想说一句：“干不了。”
第三，他更懂抽象。
好的技术头儿做架构，本质上就是在提炼共性，隔离变化，降低耦合。
这和产品经理从一堆客户叽叽喳喳的需求里，提炼出产品的核心能力，完全是同一种脑力活动。
张总要审批，李总要流转，王总要复核，赵总要归档。
二流产品会记下四个需求。
技术头儿出身的产品会想，这背后是不是就是一个状态流转和任务分派的通用模型？
第四，他更容易拿到研发的信任票。
产品转型最大的阻力之一，就是研发不信你。
技术头儿转过来，至少天生会说技术黑话。他能把为什么要做讲清楚，也能把怎么做的大致路子说明白。他不会轻易说这很简单，因为他知道这句话在研发耳朵里，约等于今晚通宵。
第五，他被真实的交付毒打过。
大多技术头儿，都被线上事故教育过，被客户验收折磨过，被历史代码恶心过，被临时需求偷袭过。
这些经历，会让他对产品有一种工程现实感。
好的产品判断，需要这种现实感。没这玩意儿的产品，很容易沉迷于概念。今天中台，明天平台，后天生态，大后天全链路闭环。
词都挺大，转眼地基还没打。
当然了，技术头儿转产品，也有自己绕不过的坑。
最大的问题，是容易钻牛角尖，看啥都是技术问题。
他可能看到啥都先想架构，忽略了用户的体感。
可能觉得用户不会用就是用户傻，看不见操作门槛。
可能太沉迷于技术上的优雅，忘了商业世界常常需要一个先能卖钱的版本。
可能把产品路线图画成了技术演进图，客户看完，除了肃然起敬，心里想的是：那我这月的问题，到底谁能给我解决？
所以，技术头儿转型，必须恶补三样东西：
第一，补人味儿。
别看系统怎么转了，要看人在什么场景下、带着什么情绪、为什么那么干。
第二，补生意经。
别看能不能实现了，要看能不能卖、能不能续费、能不能变成大买卖。
第三，补讲故事的能力。
产品得让不同的人信同一件事。客户、老板、销售、研发、设计、实施，每个人听到的人话版本都得不一样，但内核必须一致。
技术头儿要是把这三样都补上，就有极大概率成为一个重要人物。因为他既能看到天上的战略蓝图，也能看清地底下那些乱七八糟的管线该怎么埋。
理想好搭档是怎样
一个理想状态是，产品经理、客户经理、技术头儿，能形成一个稳固的三角阵。
客户经理，把一手、鲜活的客户现场情况带回来。他就好比前线侦察兵。
产品经理，把这些情况，提炼、抽象、判断，变成产品的进攻方向。他好比作战参谋。
技术头儿，把产品定的方向，变成一条条可执行、可维护的工程路径。他好比工兵营长。
客户经理说：最近有三家客户都在问数据导出，都说现在报表不够用。
产品经理不该马上写导出需求，而该追问：都是谁在用？导出后干些啥？报表哪里不够劲儿？是不是都牵扯到给老板汇报？是不是某类行业的通用场景？
技术头儿不该直接说搞不了，而该判断：现在这套数据模型能不能撑得住？报表这块要不要单独抽象出来做个引擎？权限能不能控得住？导出是不是得走异步？哪一步先做能让后面的事儿都简单？
这才是金三角式的协作。（并非“金三角”）
客户经理，负责把火情报准。
产品经理，负责判断这是真火灾、做饭的烟、还是有人在群里制造紧张空气。
技术头儿，负责告诉大家，灭火器在哪儿，水管够不够长，先救哪一层，以及这栋楼当初为什么没装消防通道。
三个人缺一不可，但绝不能互相客串。
客户经理干了产品的活儿，产品会被客户牵着鼻子走。
产品经理干了客户经理的活儿，产品会沉溺于安抚和承诺，变成画饼高手。
技术头儿硬充产品经理，要是补不上用户和商业的课，产品会变成工程师的自嗨。
产品经理冒充技术头儿，要是不懂技术边界，迟早会把一句就加个字段，变成全员加班的祭天仪式。
照照镜子
判断你是那种人并不难，看几个信号就行。
如果产品经理的日常，主要是陪客户开会、整理客户需求、催研发排期、陪客户验收，那他骨子里是个客户经理。
如果产品经理能门儿清地说出：目标用户是谁，核心骨头在哪，为啥这类需求先做，哪些需求我们就是不做，未来三个版本的能力演进图是啥样，那他才更像个真正的产品经理。
如果产品经理的需求来源只有老板和客户，没有数据、市场情报、竞品分析和战略推演，那他大概率是个需求分拣员。
如果产品经理从不敢对任何需求说不，只会在文档里把优先级从P0排到P0.5、P0.05，那他已经进了产品经理的重症监护室了。
如果技术头儿总是在评审时，追着问边界、问规模、问异常、问兼容、问指标、问以后的打算，这人可能有点烦，但他大概率是在用一己之力保护整个团队。
如果技术头儿只会说“搞不了”、“没时间”、“架构不支持”，却给不出任何能凑合用的替代方案，那他只是在把技术能力当成了免战牌，本质上还是避事儿。
如果客户经理只会催进度，那他就是个会移动的复读机。
如果客户经理能带回客户的组织架构、真目标、拍板链、用起来的卡点和续约的风险，那他就是高价值的情报源头。
一个组织最怕的，就是把低质量的客户输入、低质量的产品判断和低质量的技术交付，串成一条流水线。
客户随口一提，客户经理激情转发，产品经理连夜画图，技术头儿被迫接锅。
最后快上线了，客户来一句：“这跟我当时想的，好像不是一回事儿。”
写在最后
产品经理、客户经理和技术头儿，看着都围着客户和产品打转，但他们解决的是三类根本不同的问题。
客户经理，解决的是关系和生意能否继续的问题。
产品经理，解决的是方向和取舍的问题。
技术头儿，解决的是实现和工程秩序的问题。
三者没有谁天生就比谁高级。真正的高低，在于你有没有把自己的这摊事儿，做出专业度，做出门槛。
客户经理如果只会传话，那就是个移动的聊天记录。
产品经理如果只会写需求，那就是个带工牌的许愿池管理员。
技术头儿如果只会救火，那就是个高级移动消防栓。
可反过来，客户经理一旦能洞察客户真生意，他就是公司最前线的情报系统。
产品经理一旦能独立完成判断和取舍，他就是产品长期价值的守门员。
技术头儿一旦能把一团乱麻的复杂性组织起来，他就是产品能否落地的压舱石。
现在很多中小公司的产品干得像客户经理，根子上是商业压力、组织阶段和产品认知一起作用的结果。
客户少，现金流紧，老板急，销售急，交付急，产品自然被顶到了客户前线去堵枪眼儿。
短期利益不能进入长期决策，如果就一直停在这儿，公司就很难从项目作坊进化成产品公司。
技术头儿之所以最容易转型产品，是因为他已经站在了产品、工程和交付的三国交界处。
他知道一个想法怎么变成系统，也知道一个系统怎么在现实里崩掉。
只要再补上用户、商业和表达这些能力，他就有机会从一个技术负责人，蜕变成真正的产品负责人。
最后说一句。
一个公司到底有没有真做产品的本事，不是看它有没有产品经理这个岗位，也不是看它有没有一摞摞厚如砖头的需求文档，更不用看它开会时喊了多少次用户价值。
要看它敢不敢拒绝客户的错误需求，敢不敢为了长期的产品形态放弃短期的容易钱，敢不敢让技术的边界参与商业决策，敢不敢把客户的声音变成产品的判断，而不是直接变成研发的工单。
能做到这些，产品才开始像个产品。
做不到这些，头衔再新，流程再全，工具再贵，最后也只是把客户经理、产品经理和技术头儿关在同一个会议室里，大家一起听老板说：
“这个需求，先做个简单的出来看看。”
PS：写的比较急，也没什么查的资料，有一部分是copy之前的草稿，算是给佬友 @Humpy 的一个解答。
PPS：关注一下我的表情包系列吧，助力孩子出道 
[表情包] 分享自设表情包第二期
搞七捻三
没想到上次刚发没多久就被Google收录到了[image] 目前已经上架了表情包，但是不知道是不是搜索的问题，暂时可能是搜不到
表情包 往期表情包
![[image]](https://cdn3.ldstatic.com/original/4X/a/7/d/a7d45a694dd70a9f5a300cedab35bcd6d3ff49cb.jpeg){kind=link}
2 个帖子 - 2 位参与者