这也是开发让产品懂技术的一个主要原因。同样的对于运营、市场、销售各个环节都是一样的道理，这些细节往往是数据库架构、接口规则制定时必须要考虑的，产品架构与传统产品经理以用户为中心的基本精神虽然是相通的（只不过这里的用户不再是公司产品的用户，而是公司内部的运维团队、产品团队甚至是技术团队），只不过因为系统的复杂程度和扩展性要求，比起做一个支付流程、做一个评论功能来说大得多，所以一般的产品经理很难有机会接触到。
1、在你看来什么是销售？做销售的人有捷径可寻吗？
把具体的物质如商品推销出去，或将抽象的事物如知识、经验、技术、文化推广传播出去，发扬光大，资源共享，都可算为销售。如果说有，就是:1.提高产品质量，保住企业和品牌的公信力，2.加强精细化管理，重点做好产品的包装和推销工作。3.不断推陈出新，人无我有，人有我优，人优我新，人新我特，致力于扩大产品的影响力和知名度，
2、什么叫做产品架构？
首先我对“产品架构”的理解，就是在充分理解面向用户的需求之后，从0开始设计完整产品体系方案，并将其实现的过程。这里面包括一个产品形成的全过程，包括数据层的数据库表、后台数据处理平台和运营维护平台、前后端数据交互体系，前端的基础产品框架等一整套系统的构造和运转逻辑，这也就是所谓一个产品可以诞生之前所需的“骨架”。
当这套骨架完成后，大家熟知的前端功能、数据接口等等实体性质的产品开发才正式开始，有两点可以概括产品架构的特点：1.架构最大的特点在于，眼中没有产品形态的概念，只有数据流转的过程产品架构的工作本质是在梳理数据流。如果梳理的顺，那么未来产品会做的非常顺畅，用户需要的功能可以快速实现，产品的稳定性也很高，同时可以有效支撑几年甚至十几年的业务发展，
而界面只是对数据的窗口或者入口而已，那是未来各位前端产品经理或者后端产品经理考虑的事情。2.需要深刻理解不同岗位的职责，以及他们工作的内容，也要深刻理解最终的用户简单来说，如果开发、运营、产品、市场的目标都是打造好产品，那么架构师需要考虑的就是如何让这帮人打造出好产品，知乎经典问题“产品经理是否需要懂技术”，并不是需要产品懂写代码，而是理解技术对于实现需求时的优势、劣势、风险。
同样的对于运营、市场、销售各个环节都是一样的道理，现在回到问题：如何提升架构能力？产品架构与传统产品经理以用户为中心的基本精神虽然是相通的（只不过这里的用户不再是公司产品的用户，而是公司内部的运维团队、产品团队甚至是技术团队），只不过因为系统的复杂程度和扩展性要求，比起做一个支付流程、做一个评论功能来说大得多，所以一般的产品经理很难有机会接触到。
除了产品经理的常规能力要求外，还有几个重点感悟想单独拿出来说说：1.好奇心，主动性，比如负责做注册的，至少可以接触到注册的数据存到了哪里，怎么入库的，中间经过了哪些技术实现环节，增删改查可能会有什么场景，未来其他部门或功能哪里会用到用户信息，一般会有哪些使用维度等等。这是一个相对完整的数据流程了，理解数据流程后，再进一步思考业务发展点，比如未来运营部门可能会用到这部分数据做用户运营，比如会有精准的运营内容推送，就涉及到数据关联，那么用户数据这块他们如何调用可以最高效合理。
带着类似的问题去和相应的开发或运营部门去沟通，不经意间也许就可以蹦出啥火星子来，领导觉得考虑没准就让你去牵头搞了，。，不关心？那除了每个月的工资其他都和你没啥关系了。，。不主动，上哪儿知道这些东西去，。，2.对于养成考虑极端情况的习惯。现在的产品经理设计功能的时候，都是正向思维，正常场景下没有问题，但是对于一些极端情况很少考虑，
这也是开发让产品懂技术的一个主要原因。int不能为空值，最大数量上限多少，主键这些基本的概念如果产品懂一点的话，未来产品的稳定性可以大大增强，需求返工的概率也大大降低，而这些细节往往是数据库架构、接口规则制定时必须要考虑的，3.一定要懂数据一定要懂数据，一定要懂数据，一定要懂数据，只要能把一个产品还原回一个动态的数据形态和流转过程，就可以去架构师的副本去练级了。
