产品和技术有着不同的方法论，但有些东西是相通的。那么，产品设计的逻辑，能否代替代码构建的逻辑呢？这篇文章，我们看看作者的分析。

一、产品始终以业务为基

互联网行业软件研发领域中，核心的协作角色通常包括：

• 产品经理
• 开发人员，含前后端程序员
• 技术人员
• 往前延伸，还会有流程建设人员，往后延伸还会有测试人员、运维、安全等

每个节点的职责有层带般的区分，分别会衍生出来以下架构：业务架构、产品结构、技术架构、IT结构。

没有一开始就有的产品结构，产品一定是在业务发展中催生出来的。

这就是为什么字节跳动催生了飞书，OKR这一套在字节内部如此好用的东西，当飞书要推向其他企业的时候却屡屡受挫。这也是为什么，当年腾讯张小龙带队的微信刚面世时候，四面楚歌，小米的米聊一开始势头很猛，却在后续的大数据大用户处理上、在社交产品的认知上节节败退，不得不退出社交领域的竞争。一众对手眼睁睁目送微信一步步高奏凯歌。

产品随着业务需求不断拓展，催生出来更合理的分层架构

产品逻辑的背后需要程序代码的支撑，再底层有需要技术架构的支撑。每个支撑层带都希望能够尽可能准确的掌握业务演进的方向，这里面包括：业务板块、用户规模、业务模式等等。

二、产品连接着商业与技术

首先产品团队成员需要对商业、具体业务的深刻理解、对用户场景的感知，才能设计出/找到产品实现路径当下的最优解。

产品经理应该能够根据业务的发展 、产品路径的演进，判断出来一些核心逻辑的设计、区分和预留。形成所谓的产品规划、产品实现路径，也可以简单叫做“产品节奏”。

这个节奏的基调引导了代码的架构，这也就是产品逻辑、功能逻辑、到代码逻辑、数据逻辑的层层衔接了。

简单到一个功能点，代码逻辑需要在产品功能迭代路径的支撑下才能更好的实现，产品经理不去和程序员探讨功能与实现、业务与产品，难道指望程序员自己就能理解业务吗？

可能有，太少了！优秀的程序员会有更好的业务和用户共情能力，但是多少思维上还是更偏向于“实现思维”的，它们是实现的可行性、复用性、简洁性、高效性。

三、做起心动念的人，也做攀爬的人

作为一名产品经理，绝对不是简单的我想要什么，剩下的交给开发者。想要什么很重要、路径演进的可能性同样也很重要，表达清楚绝对是为自己的产品路线铺路。

相信任何产研团队都不愿意看到产品极速发展的过程中，代码逐渐臃肿不堪、跟不上发展的步伐，最终不得不面临重构，要不就是产品的妥协、用户价值/商业价值的大打折扣。

当你愿意和开发者、技术人员共同分享产品设计的逻辑、产品节奏的时候，你得到的将会是一群愿意支持你、为你的产品方案主动思考的开发者、技术人员、测试工程师们。

看看下面的故事吧，开发者也会和产品经理主动分享代码的设计逻辑咯！这不就是最好的局面吗？

四、跟着攻城狮看feature背后数据构建的心路历程

开发者的思维对于产品经理来说是非常值得进行一些了解的，作为产品的设计者，谁不想做到由表及里的透彻呢？了解实现模型，才能更好的结合产品模型、用户心理模型。

产品可维护，用户使用可维护，触发功能设计背后的数据构建逻辑，值得探索。

特别是涉及到算法逻辑的部分，需要有对应的数据过程记录和沉淀，满足可追溯、可查证。产品设计中，我们会自然地认为，一切应该怎么发生，向何处发生。沿着正确的路径用正确的方式向前，记录下来我们认为重要的东西。

就像我们的大脑够复杂吧，那些不起眼的决定、意念、下意识，都简单的我们甚至察觉不到它的存在。其实细微之处可以将一次常规的对话展开，接收者解码、接收者自己的知识匹配、判断、识别、结果输出，还有环境、地域的各种影响加持。这指引我们向世界交付价值时候需要考虑到，比较显性的价值流完善健全，也有比较隐性的支撑性的存在不可或缺。

2023年操盘一个小项目中，当产品方将产品逻辑、业务逻辑透彻的和开发者达成共识之后，开发者竟也反过来极其耐心和我探讨对程序逻辑实现、数据表设计的细节和思路，想要记录的数据等等，以此来确保他的理解和产品设计的一致性。特别是策略算法过程中，会用到几个数据计算指标来确定最终的匹配推荐结果，这几个数据计算的过程数据的存储，程序员主动提出来要做存储支持数据回溯，也可以支撑业务一些验证需求。

一个程序员能够思考到如此细节，还是让我眼前一亮，为他竖起大拇指！这不正是产品设计逻辑和代码构建逻辑两者的珠联璧合吗？这里并不是要产品经理钻入到实现思维里面，而是从产品视角之外，也可以去看看一个程序猿面对需求时，他实现的设计和背后的思考，从中获得到开发者提供给自己思维的反哺。