作者以一个错误提示问题为例，介绍了他认为比较核心的三类产品思维工具及其在项目中的应用，分别是本质思维、结构思维、系统思维。具体是如何进行的？欢迎感兴趣的伙伴们阅读~
在业务工作中，我们经常会讨论到：处理这个问题你需要运用产品思维；我想要提高一下自己的产品思维……我们知道产品思维是帮助设计师更好地推动项目的重要能力，但当想要进一步学习时，又会发现关于产品思维的各种维度的解析。
什么是产品思维？产品思维是如何在我们设计中发挥价值的？怎样体现产品思维？怎样学习产品思维？始终会有些说不清道不明的感觉，缺乏很具体的定义与行动指导。
我自己也在这块苦恼过，各类资讯书籍一看，怎么有这么多类型的产品思维？大家讲的还不一样。但之后我开始反思，也许不存在绝对定义的产品思维，不同的岗位（产品/设计/产品负责人/业务负责人等）、不同的业务、目标、经历、认知……不同的人对如何做产品、做设计其实会有不同深度的理解与运用，进而提炼与总结出可以帮助他们更好的「洞察机会、解决问题、创造价值」的思维工具组合，即为他们的产品思维。
所以相对于学习某种产品思维，我们更应该建立自己的产品思维体系，在学习与实践中不断补充与提升。
今天的分享，以一个「错误提示问题」为例，介绍一下我认为比较核心的三类产品思维工具及其在项目中的应用。
某一天，技术同学过来和我提到：“之前的一个错误码只定义了邮件登录场景下的错误文案，现在发现用户遇到在发送场景下没有定义的问题，你给个文案，这个版本补充一下？”
当下，我也是直觉的反馈说：“好的，稍后给你。”
但随后我追问了自己几个问题，发现并没有这么简单：
为什么这个错误定义会遗漏？
为什么之前统一文案的规则没有生效？
还有没有其他也会在发送场景触发的错误没有定义？
要修改错误码，只能通过发版本的方式吗？
为什么没有做成实时配置实时生效？
于是我拉着技术又进行了一轮沟通，我们发现，之前的错误梳理是分散且单一维度的，即：登录模块的产品梳理登录模块的错误，发送模块的产品梳理发送模块的错误，而实际邮件登录、收取、发送等诸多过程中，都需要验证帐号的有效性，所以部分登录时的错误，在发送验证时也会发生，而两个场景下的提示在文案与操作上有所差异，无法单纯的复用。由此，原先的问题被重新定义为：
如何完整定义所有的错误场景？
如何实现错误提示配置的实效性？
就像我们的身体出现了症状，需要去医院检查，请医生明确病因后才能对症下药。体表显现的病症，有时却是内部系统根源出现了问题的反应，如果仅仅是针对表征进行处理，并不能真正解决问题。
与人体系统相似，产品也是由一系列系统组成运行的。那么当我们发现表现层出现问题的时候，就需要提醒自己进一步思考下问题的影响范围有多广？是不是系统底层逻辑出现了问题？比起解决表征的问题，我们更需要去优化引发问题的系统。
问题本质探究的思考方式：
问题溯源：不断追问why，从根源解决问题，避免复现。追问的方法很简单，但很多时候是我们忘记问或问的不够深。
审视目标：重新审视产品目标，明确现状与目标的差距在哪里，为什么？
回到系统：把问题放回到它所处的系统中去重新思考，找到系统中起决定性作用的核心因素。
重新定义问题后，第一步，我们希望可以收集、梳理完整的产品错误码，并定义其内容。
但是邮件服务涉及多个不同的邮件协议，加上不同产品端（移动、电脑）、不同场景（登录、发送…）的相互叠加，相关错误有几百个，该如何梳理？
结构化思维方法可以帮助我们：
结构化的过程，首先是拆解的过程，分析问题的对象由哪些部分组成，将这些部分拆解出来。再将子项再进一步进行拆解，不断细分（实现MECE规则中提到的 不遗漏、不重叠的效果）。案例中的错误提示便经过了以下的几层拆分：
第一层：协议，如IMAP、SMTP等；不同协议之间的错误码相互独立；
第二层：产品端与场景，不同端、不同场景下的提示样式、内容规则会有差异；
第三层：内容组成，拆分错误码、错误提示的组成，如：cause、code、形式、标题、操作等；
拆解后，需要再将这些要素重新分类组合，以便于我们梳理和不断补充错误码。
此处，我们利用表格工具建立二维管理表：
每个Tab是一个协议；
纵向是需要梳理的每个错误码；
横向是错误信息组成与不同场景下的需要定义的内容；
而他们组成的每个单元格就是我们需要完善的内容。
借助此工具，每一个错误码，都有了一个梳理的框架，可以明确需要定义哪些内容，避免场景与内容的遗漏。
在拆解梳理的过程中，会发现内容之间会存在一定的相似性与复用性，通过找到这些共性内容，又可以逐步形成一些标准化规则：
相似场景的提示形式是否可以统一？
好几个错误码都在描述帐号风险问题，他们的文案提示是否可以复用？
一些常用文案，如：确定按钮是用「确定」还是「好的」，是否可以统一？
常用关键词的翻译是否可以统一，避免后续翻译混乱？
通过这一步，可以总结和输出：错误提示组件规范、文案规范等标准化工具，一方面是保障用户体验的统一性，另一方面也是为后续设计提供参考降低成本。
结构性思考是产品设计中很重要的工具，可以帮助我们将复杂的问题转化为简单的行动，将混沌的问题转化为清晰的描述。
常用的结构化方法：
图表化：展现复杂问题的结构，帮助更全面的完善细节，也是我在整理信息是特别常用的一种方法。但其难点是在于要将问题拆解充分，最终每个单元格只有单一的「是与否」信息为最佳；
模型化：将问题思考的过程提炼，帮助我们进行更全面的分析与思考，设计常用的分析模型如：用户体验地图、用户增长模型…
公式化：找到核心变量及其影响关系，明确工作与结果的关系，对于数据结果导向的工作特别常用。
梳理错误提示的同时，我们还需要搭建一套系统，以实现灵活配置与实时生效的目标，即：将我们的设计构想进行产品化落地。而此时，系统思考之一，便是关注系统的动态性。
“系统能运行多久？”
系统的设计需要满足动态的需求变化，单以错误提示为例，发生变化的情况有很多：
虽然希望能够完整定义所有错误，但事实上是比较难做到的，未来的内容新增不可避免；
相关方对于服务的调整，有可能会造成错误提示的修改要求；
提示上线后，发现文案效果不佳，会带来优化需求；
随着产品能力与技术的迭代，一些过去的内容与操作可能不再适用，需要调整；一些过去的未知错误有了新的解决办法，需要补充…
之前的错误提示，是伴随着每次功能迭代，在设计时定义好，在研发时写在客户端，因此造成每次修改都需要发版处理的情况。在优化方案中，替代原先在客户端管理的方式，将错误内容配置放到服务端，客户端获取服务端错误码与配置内容进行匹配，展示相应内容：
“一定需要提示吗？”
我们常听到一句话：最好的设计是「没有设计」，转化用在这个项目中却相对合适，最好的错误处理也应该是「没有提示」。
当我们在专注于梳理错误操作内容、设计错误操作配置，不妨可以再问问自己：
这个提示真的有必要展示吗？—— 是否可以通过自动重试或其他策略优化，避免错误的发生？
这个操作真的有必要让用户处理吗？—— 是否可以提供一键检测、一键修复的方案，帮助用户完成一系列的复杂操作？
“你能发现未知的问题吗？”
前面提到，提示系统的作用之一就是便于后期将未知错误转化为已知错误？但是如果是未知错误，我们要怎样发现它们？如何决定哪些未知错误需要优先处理？
考虑到这个问题，我们在配置系统外，同时还搭建了一套线上报错监控系统（虽然还做不到识别高频未知错误主动预警），定期复查高频错误，补充定义新的未知错误。
至此，错误提示问题的解决方案设计才算告一段落。
邮件系统的错误提示有其复杂性与重要价值，借助产品思维工具，避免了掉入「这个问题很简单」的陷阱，找到问题根源与最佳目标，从复杂繁多的错误中找到规律，进行结构化梳理，建立标准，最后建立错误提示配置系统、自动化策略、监控机制，为产品的错误提示管理建立系统方案，为产品与用户提供长期价值。
有同学会问，如果要搭建这么一套系统的话，投入大时间久，那这个之前的问题就一直放着吗？
当然不是。在实际工作中，处理问题需要同时考虑解决效率与投入价值。
从处理问题的效率上考虑，最开始的错误提示当时也是先及时做了补充的。但是此时，这个文案的补充并非孤立无序的，我们能够清楚，它将是错误信息管理表中的一项重要信息，也是配置系统的一项重要配置，是未来错误提示系统的重要一部分。我们并非在零碎的做事情，而是在逐步完善一个产品系统。
