C端产品经理转B端，最常犯的错不是不会画原型，是不知道原型画对了也没用。
杨堃做B端产品十几年，开头就说了一句让很多人不舒服的话：B端产品的核心工作不是设计用户体验，是理解业务流程并把它翻译成系统架构。你画的每一个页面，背后必须有一条完整的业务链路支撑——如果链路断了，页面再好看也是废的。
为什么C端方法论搬不动
C端产品有一个隐含前提：用户可以随时离开。所以产品经理的核心能力是留住人——靠体验、靠情绪、靠习惯。用户不喜欢就走，你得想办法让他喜欢。
B端的逻辑反过来。企业客户不会因为按钮颜色不好看就换供应商。他们选一套系统，签约、部署、培训、迁移数据，换一次的成本可能是几十万。留住他们靠的不是体验，是你的系统能不能跑通他的业务。
杨堃花了大量篇幅拆解这个区别带来的连锁反应：需求管理不一样——B端需求来自业务流程分析，不是用户访谈；优先级不一样——B端先保证流程跑通，再优化体验；交付方式不一样——B端产品上线只是开始，实施落地才是关键。
业务架构能力是B端产品经理的分水岭
杨堃把B端产品经理分成两种：画图的和搭系统的。
画图的产品经理，接到需求就开始画原型，画完交给开发，开发过程中不断被业务方追着改。改到最后发现，不是原型画错了，是业务流程从一开始就没理清楚。
搭系统的产品经理，拿到需求后第一件事不是画原型，是画业务流程图——谁发起、谁审批、什么条件流转、异常情况怎么处理。流程理清楚了，原型只是流程的界面化表达。
这两种做法的差距，在小功能上看不出来。一旦系统复杂度上升——多角色、多流程、多权限、多租户——差距就是做得出和做不出的区别。
读完以后带着走的判断
杨堃不教你成为更好的"画图选手"。读完之后留下来的是一个判断入口：拿到任何B端需求，先问"这个需求对应的业务流程是什么"，再问"这个流程在系统里怎么跑"，最后才问"界面怎么呈现"。
这个顺序搞反了，后面所有工作都在返工。