2022 年大概春天的时候，我写了一篇我在 fouding team 创业生活的开端 （我的“半创业者”生活）。不知不觉，作为一个 non-technical background 的人，做这么一款开发者产品的产品设计，还有 go-to-market 的探索已经两年多。这篇文章总结一下我对于开发者这一群体的理解，还有开发者工具设计（偏 infra 产品）的思考。

如果有说得不到位的，各位程序员朋友们不要打我 🤣 文中引用了很多英文，不知道怎么翻译，还是保留了原始 term 准确的含义。

全文约 9000 字，阅读需要...我也不知道多少分钟，确实写太长了。

然后，让我再重新介绍一下 logto.io（给自家产品打个广告，方便了解上下文哈哈哈）

我们是一家针对开发者的工具产品：主要做新一代的身份验证和鉴权的 infrastructure。同时具备社区开源和 SaaS 版本。只要你做产品，就一定会用到这部分（登录注册，用户管理，权限管理，单点登录等等）的模块：我们提供从开源代码，到 API，到 SDK，到 out-of-box UI components，不同深度和灵活度的方案和服务。

Logto 从第一天就目标海外市场。国内没有投入专门的运营和推广，但在开源已经有足够的影响力

在真的做一款开发者产品之前，我自诩还挺了解程序员这个群体的：我生活里很多亲密的程序员朋友，非常欣赏和尊敬他们的日常：他们理性，自信，慕强，务实，善于解决问题，有求知欲，自学和动手能力强，追求自我成长，喜欢在互联网上激情分享和表达… 他们的职能分工和技术栈，每天都在用的工具和关注的事情，一些 stereotype 的性格特征，我大体都有感知。

上学学交互设计时，我们都会总结一些很感性的 persona 去搭配产品设计，但工作迄今，可能是一直做工具和 2B，我其实并不是很认可用户心理特征对产品设计可以产生所谓的巨大影响，更重要的还是目标人群 day-to-day 的工作流。后来发觉，我忽略的一点在于工作和人群性格彼此之间会相互塑造，有些性格特质可以追根溯源到他具体的日常行为中去，而这个恰恰是我需要关注的内容。

"Taste"

我之前听到我的程序员朋友跟我说 taste 这件事，我会不屑地撇撇嘴。在解决问题上追求这么虚无且看起来很装逼的“品味” —— 在我眼里感觉挺幼稚的，后续我理解 taste 其实包含了很多层含义：

开发者每天要使用大量的工具，各个工具彼此链接，他们细颗粒度地，独立地在各个工具之间高强度执行，在这个工作流中势必会产生自己的 personal preference：从感性上认知这个工具是不是酷的，美的，到理性上，小到代码风格， editor 的字体和大小，darkmode 的开关，大到数据库和框架的选择，人和人，团队和团队、公司和公司之间形成的“差异”，这些都可以用 “taste” 来抽象地概括。

所以基于此，我总结出作为 creator 的一些 guiding principle:

1. 理解并尊重开发者的 “taste”

2. 相信他们对于自己技术能力的判断

3. 让他们拥有选择工具的权利

理解这些后，自己做产品的时候就会有意识地有一些行动来提升所谓的“开发者体验”（后文会展开），例如：

1. 支持更多的与其他工具的集成（integration）

2. 提供更多的语言框架 (language frameworks)

3. 在产品上给到开发者更多的“控制” (control)

Devs typically want lots of control

主要展开上文所说的第三点，什么叫给到他们更多的控制。

有一次参加线下活动的时候，我提了一个问题，怎么才能高效 reach 到产品的开发者用户，有一个创业者说的话让我印象深刻，developer 不喜欢被教着做事，希望有自己的做事方式。

哈哈，是不是开发者是一个听起来脾气很大的样子，其实不是。

因人而异的任务复杂度

许多开发人员希望对他们的 tech stack 各个方面进行细粒度控制，并不仅仅是 get things done. 有的时候会考虑到附加的安全性，scalability 和性能优化，对于 standards 的遵从，还有对于其他服务的集成等等。我们不能理想化地期待我们产品的默认项，还有 suggested solution 不需要任何 tweak 的情况下就可以覆盖他们的 special context。所以产品要留好给到开发者 tweaking 的空间。

因人而异的技术能力

虽然开发者有专家，也有小白用户，但对于这个职业群体来说，大部分的开发者对处理复杂度和解决问题的能力普遍高于常人（不要杠，杠就不是开发者工具了，是低代码工具了），同时按照技术能力区分，开发者们像光谱一样（Specturm）分布在这个市场中，不是一个 yes or no 的问题。

作为产品经理或者设计师，不要预设我理解不了的东西开发者就理解不了而 over design，也不要预设我觉得很简单直接的东西，他们就可以用得很开心，并乐此不疲地进行重复性操作。

信任他们的技术能力非常重要，要做到“放权”。

何为信任他们的技术能力？就是针对他们的技术水平，给到他们不同程度的控制。

何为控制？就是支持不同 interface 层面上的操作，让他们有自主权。以下面的 interface 进行举例，我的理解，从控制度大小排序：

APIs (Application Programming Interfaces) > Command-Line Interfaces (CLIs) > Configuration Files > GUI (Graphical user interface)

其中 CLI 和 configuration files 都可以理解为 text-based interfaces。

上述提及，是我做开发者产品 top 2 感受的第一点。

如果我们面向的用户是传统的 2C 用户或者 2B 的非程序员群体，大家对于 interface 的理解程度是齐平的，都需要一个 GUI 的控制台去给到机器命令，让机器去执行任务，甚至 GUI 复杂一些都没有什么所谓，毕竟我不会写代码。

开发者工具往往都配有一个控制台，我个人认为，控制台的出现，并不是解决开发者小白用户不会写代码的问题，而是为“所有人”解决效率问题，一个开发者工具并不具备技术扶贫的使命。

开发者工具产品设计的本质在于如何合理 combine 不同的 interface 整体提升开发者的效率 （efficiency) and 效果（effectiveness）。比一般的 2B SaaS 工具多了好几个 touch-points and surfaces。

见过不少国内的开发者产品，产品经理想当然地觉得 GUI 可以解决所有问题，后台复杂得像一个杂货铺。

首先定位你产品的目标客群，之后做好“简单易用 vs 给到有经验的人足够的控制”这两者之间的平衡。

在后面一段我想详细和大家讨论下 multi-surfaces interaction：每一个 interface/surface 适合放置的功能特点和判断原则。

书面表达的沟通方式

之前做 growth，onboarding 后立刻跟进用户约聊天，在普通 SaaS 产品中是一个非常常见的手段，面对面的聊天不仅能增进用户和产品的信任，我们还可以通过观察和提问，挖掘出更多潜在的问题。早期我非常努力地想要 reach 我们的用户做 interview，但效率和之前经验相比差太远了。

开发者如果选择和你沟通，他们能键盘打字的，就不会面聊。甚至有些想要走 Enterprise plan 的客户，开启“对话”的职能线都不是开发者。这个特征是无国界的：开发者的工作大多都是 solitary work，沟通通常通过书面的形式，例如 code comments, issue tracker 等等。不会像产品经理和设计师一般经常会有一些身体力行的发散讨论和即兴。

积极想要和用户聊天的我，后来开始学会利用不同渠道收集信息，社区，邮件，github discussion，甚至 hacker news 和 reddit 上的讨论帖。

Features, scenarios, or best practices?

SaaS 行业内广泛流传着一个共识，你做的不是产品，而是最佳实践和针对于企业提效的方法论。这个结论其实没有什么问题，但是对于我做开发者工具，且从零到一的工具开始，这是一句正确的废话。这一点，是我做开发者产品最重要的 top 2 感受的第二点。

所谓的最佳实践和方法论，对于从 PLG 甚至 DLG 开始做起 0-1 的产品，这个饼太大了，也太早了。我们不排除那些探索性的用户可能会被 benefits 洗脑，但对于那些很清楚自己想要什么的开发者（他们是更加容易获客的群体，且更符合 target user 的特征），他们已经会有一系列的 feature list，在发掘你的产品之前，大概率已经评估了一些由自己业务衍生的技术需求。此时你的产品如果追求讲 benefits，可能会适得其反。

WorkOS 在 SaaStr 分享了一个企业对于技术工具的选用的场景，一个公司内不同决策人关心的内容：

Developers 开发者

Most developers will sign up for WorkOS and plug it in. They don’t want to learn what any of it means. If you want payments, sign up for Stripe. If you want to send an SMS, use Twilio.

大多数开发人员会注册 WorkOS 并直接使用它，他们并不想花时间去学习它的内部运作原理。如果你需要支付功能，那就注册 Stripe。想要发送短信，那就用 Twilio 吧。

VP of Product 产品 VP

The Head of Product has an Enterprise roadmap around the real functionality they want in the app. They don’t want to derail their roadmap because of user provisioning stuff.

产品负责人围绕应用程序中所需的实际功能制定了一份 Roadmap。他们不想因为用户身份配置之类的事情而打乱他们的计划。

Head of Sales 销售老板

They don’t understand what SAML means and don’t plan to learn it. They become stakeholders because they’ve heard the objections from customers, know that they need these features and that WorkOS can unlock their next stage of growth.

对他们来说，SAML 是个陌生的概念，也没有学习它的计划。促使他们成为利益相关者的原因是听到了来自客户的反对意见，他们意识到需要这些功能，并且 WorkOS 能够帮助他们解锁下一个增长阶段。

真的是非常现实的一个场景，一个协作低代码工具最近谈了一个大客户，客户说有自己的 IdP 可能需要 SAML 支持，销售团队一脸懵逼，SAML 是什么，他们也不想了解这个技术名词，只想快速签单。于是把这个需求递给产品，产品一想，这个能力不在我的 scope 范围内，属于技术基建，和我的领域毫不相干，优先级不高，赶紧丢给技术负责人，把这个身份相关的东西搞定吧，有影响用户体验和增长的我再参与。

为什么会出现 features over benefits 这个领域的特殊性呢，

1. 即使 buyer is not user，开发者在企业内对于自己工具选择的话语权是很高的：技术门槛高，其他职能的人只能对用户需求，产品流程，合规和安全性上加以干涉，纯粹技术上的 feature 拆解和测试依然依靠开发者自身。开发者需要第一时间需要知道你的产品有没有他需要的能力。

2. 一些基础的技术能力是行业共识，大家拥抱 open standard 和各式各样的广泛协议，求新求异的空间有限。技术产品提供 feature 的稳定性，拓展性，兼容性（Interoperability）反而是更重要的。不像 C 端和更面向用户的 SaaS 产品，尤其项目管理工具，不同产品可以有自己的态度，卖自己的 best practice 和方法论。

举个例子，很多人问我，你们做一个多因素验证的 infra 功能的价值主张和独特性体现在哪里呢？其实没有什么可以上升或者画饼的点，其实很直接：在 offering 上要通用，在 configuration 和集成体验上要好用。

Feature availability 

功能克制的界限一个完整的 workflow 能不能被解决，是否可用

去年我写过一篇文章，理论了很多一个产品功能做还是不做的问题（如何确定是否有必要开发新功能）。我现在依然秉承着类似的观点，但是补充一些我的逻辑漏洞。

假设用户需要两个 feature，我可以只做 feature A，而不做 feature B，如果你的 feature A 做得非常优秀，且提供了我自己去做 feature B 或者购买其他产品来 cover B 的可能性，也是 OK 的，海外产品大多这个思路，一是整个生态比较开放，二是小而美的垂直产品非常多，整体可用性非常高。最不可接受的是，开发者需要 A+B，我们只做了 feature A，但是用户又无法自己做 feature B，或者无法集成其他产品的 feature B，那么这个产品就是不可用的，变成了一个必须用这个产品，并且需要等着做完 feature B 才能解决所有问题的封闭系统。

你有没有发现，所有封闭的产品最后都会主打 all-in-one 以及逃不过越做越复杂的命运。

所以我想强调的是，每一个单点功能，不仅仅是满足这个模块最表面的能力，应该能提供

• 从“控制”的角度 multi-interface 的支持

• 站在开发者一侧做的产品的角度，从时间维度，产品阶段，生命周期，考虑对他们各个深度的支持

这是真正的克制的产品，即使单点功能不多，但是把单点功能做到 100% 甚至 200%。（画外音：好难是不是，想到这个理想化的目标觉得自己道阻且长的。）

对于一个开发者产品，功能不强大、需求无法满足是原罪。所以，克制的界限一个完整的 work flow 能不能被解决，是否可用。

All-in-one vs small-and-sharp

近些年，SaaS 创业者们终于渐渐意识到 all-in-one mindset 的产品形态在海外屡屡受挫的感受。中国企业服务市场的封闭性，和各个产品之间的很难打通，不得不迫使一个产品早期就把这个领域内所有产品功能补齐。

首先 All-in-one 这个理念并不是错误的， all-in-one 会 push 我们 discover the whole market early（提前布局哈哈），是件好事。但是他的问题在于从创业角度，它是地狱难度，all-in-one 最难的在于如何落地到产品形态上，以及这个 all-in-one 的 ah-ha moment 在什么时候可以被呈现。

客户有需求，你得做，但做完了产品就恶心复杂层层套娃，然后你做了还不知道收益如何。后续产品工作甚至会出现一半的时间解决自己制造的问题。所以为什么有很多产品一开始就选择了 multi-product strategy 但避免做平台型产品。

All-in-one 还是 small and sharp 都是自己的风格， PlanetScale 的 CEO 写了一些对于开发者体验的小文章我觉得还挺有意思的，贴过来分享。

Small, sharp tools

Give me the means to build. Let me pipe one thing to another. Make the next step I have to take either delightful or reasonable. Know my pain.
https://samlambert.com/dx

Developer experience and multi-surface interaction 

终于到了我最想聊的一部分，先来一段有天我和朋友的聊天内容：

做开发者产品，我感受最深刻的一点就是“层”的问题。首先，通用的用户体验原则依然有效，但在开发者产品领域，衍生出了一些更具体、更特殊的思路，并体现在市面上的各种产品之中。

1. Multi-surface interaction

   这一点是说工具如何跨越多个接触点来呈现自身的价值。如前文所说，开发者不会仅仅使用单个图形用户界面 (GUI)，还可能会与 SDK、API、CLI 不同的 interface 进行交互。一个 feature 的能力如何下放到不同的 interface 非常值得思考。

2. API-first design

   API- first design 的哲学是，优先构建强大的 API 作为基础。然后在 API 层之上构建其他界面（仪表板、UI 组件），方便后续的灵活性和可复用性。API-first design 的哲学不一定适用于所有，但是这个思路是合理的。从最深的地方不断封装解决方案给到开发者，长期下来 ROI 是很高的。API First 设计是一种解题思路，但不意味着我们推崇所有用户只能通过 API 的灵活才能实现业务需求。

3. 文档和社区

   文档和社区对于开发者体验的重要性就不赘述了。文档是开发者体验的基石，有活力的社区为用户提供了支持、共享和反馈的渠道。

抛开开发者产品不提，很多 SaaS 工具都会有一个后台产品。后台产品的设计逻辑往往很简单，就是需求 + 配置的逻辑。传统产品经理的工作流程如下：

• 了解用户

• 把用户需求抽象并且 GUI 化

• 用户要什么，就 cherry pick 地补一些 API 提供底层服务

这样最后做出的产品往往会出现以下问题：

• 控制台非常复杂

• API 颗粒度和结构很迷，难以使用

• 中间层的需求无法满足（后台 UI 无法满足，但又不想直接使用 API）

做开发者产品，让我对“层”这件事有了更深的体会。这段时间一直在思考，一个功能到底应该放在哪个界面上才合适，这里分享一些我的想法。

API

API 是 infra 产品中最能体现开发者产品能力范围的要素。原因很简单，其他所有功能都是基于 API 之上构建的。如果需要程序化的交互和最深度的控制，那么 API 的设计和结构至关重要。

CLI

CLI 适合快速操作与自动化。很多任务都能使用 CLI 更快地完成，尤其是执行重复性和规模化的任务，CLI 可以给到开发者 direct control 和更多的灵活度。

Logto 的开源版本给到了很多 CLI 帮助开发者安装、维护和更新 Logto 实例，让资源管理和配置更高效。一个 database alteration 的 CLI 例子。

Configuration files

配置文件包含了控制台中的代码编辑器、SDK 中的配置文件等等。直接编辑配置文件中的设置是一种常见的交互方式，因为它灵活且控制力强。

1. 不受平台限制，有更多定制化机会。例如 SDK 中的配置，用户可能有不同的语言框架，这些配置无法统一放在后台 UI 上管理。

2. 适合高级或隐藏选项，用来存放一些不适合用户日常使用的功能，或是 GUI 界面难以展现的功能。所有 GUI 本质上都是一个大表格，都是一个数据文件。有些图形界面过于复杂难以呈现的，可以考虑以 JSON 或 XML 等开发者习惯的代码形式呈现。

Graphica l user interface

最后谈到用户界面。将 “interface” 翻译成 “界面” 在中文语境下确实太不准确了。大家普遍谈及界面，还是会想当然地理解为视觉的用户界面；谈及开发者产品设计，刻板印象就是一些后台产品的“界面设计”。

Designing software applications and mobile apps pretty much means designing graphical user interfaces (GUIs), right?

Well, when it comes to working on a developer product, not necessarily. Or, at least, not solely. Non-graphical user interfaces are often a crucial part of a developer’s toolkit.

Reference: https://uxdesign.cc/designing-for-developers-e44280438e27 这篇 IBM 的 UX 在对于开发者产品设计的探讨上还蛮好的。值得一读。

那么，用户界面适用于开发者产品的哪些场景呢？

• 初次探索与学习：GUI 可以帮助开发者快速了解功能并快速上手，提升产品功能的可发现性。

• 常见 (Common)，但不频繁的任务： 对于开发人员不常执行的任务，一个有着清晰菜单和选项的 GUI 可以有效提升他们的效率。

• 概览类型（High-level overview)：GUI 最擅长的是信息的可视化，可视化图表和仪表盘有助于直观地向开发者展示其资源和实体的状态与表现。

我一直跟周围的同事们不厌其烦地胡乱念叨，我们的管理后台应该像‘四两拨千斤’一样， 要谨慎放置功能。对于复杂、精细、高频重复的管理任务， 我们要慎重考虑是否要放到我们的管理后台，navigate through UI 的交互是否高效 。如果必须要放，也要考虑是否一定要用传统的表单。

什么时候考虑 GUI 之外的替代方案呢？

• 细颗粒度和高控制力：需要细粒度控制参数或配置的任务，text-based interface 基于文本的界面通常效率更高。

• 自动化：对于需要重复执行或整合到更大自动化工作流中的任务，开发人员通常偏好 CLI 或 API。

Prompt-based interface

这里简单提一下 prompt based interface 吧。AI 产品最近已经卷疯了，但是在开发者产品领域，除了看到它做一些 copliot 的工作，似乎还没有带来巨大的变革。感觉整体原因是两个：

1. 开发者的工作流非常 well-established，变革的门槛较高

2. 开发者的工作内容对精细化和控制度要求很高，Generative AI 还无法做到这个程度

❓ 是不是 AI 产品的 prompt 都可以理解为是一个抽象和 high-level 的 CLI 呢？

❓ 按照上文的分析，GUI 是容易被取代的一环么？

Avoid vendor lock-in 

在开发者产品领域，“避免供应商锁定” 又是我学到的新名词。它是指开发人员或组织对单一供应商的产品、服务、技术或平台产生严重依赖的情况。这种依赖关系会让以后切换到其他供应商变得极其困难、代价高昂，甚至不可能。

这种行业共识简直是对封闭式系统的绝对狙击，为什么其他 SaaS 领域没有形成这样的共识 lol.‍

避免 vendor lock-in 是站在买方视角的，在卖方视角，在产品开发和设计中潜在要求我们具备几个原则：

• Be open-standard: 采用开源工具、技术和行业标准协议，不要瞎搞。

• 模块化设计: 产品中构建容易更换的组件，提高灵活性。减少客户因担心过度依赖系统任何部分而拒绝采用情况的发生。

• 抽象层：区分产品的核心技术层和客户的业务层，避免过度耦合。

• 注意数据格式的管理: 并制定清晰的迁移和导出策略。

渐进增强和优雅降级

Progressive enhancement and graceful degradation。这个是从 CEO 同学那里学到的。渐进增强和优雅降级是前端开发的两种重要理念。它们也可以应用于产品架构设计和产品设计。渐进增强指的是从一个对所有人来说都可用的基础核心体验开始，然后随着浏览器/设备功能的增强逐步添加高级功能。优雅降级指的是在无法提供完整功能的情况下，仍然提供一种可用的体验。

找到竞品分析新的打开方式

熟悉的读者都知道，挂面是一个非常痛恨竞品分析的人，因为研究竞品的解决方案并偷师阻碍了创新，忽视了对用户需求的本质理解。但是近一年，我找到了竞品分析的新的打开方式

理解市场

通过观察竞争对手近期上线或下线的功能，我们可以大致判断出市场需求的变化以及新一代产品的理念和趋势。这些观感，不需要直接反馈到我们的产品 roadmap 上，而是促使我们反思 GTM 的 gap 在哪里：

1. 我们的产品有没有错过本应该我们拿下的那些客户

2. 我们产品思路是不是符合市场需求

3. 如果符合，能否根据市场需求，进一步形成自己的 value proposition

拆解技术功能

技术产品的竞品分析就不要去看后台 UI 和看官网了，去看 doc ! doc ! doc ！重要的事情说三遍（当然如果产品的文档很垃圾那就别看了哈哈哈）。后台 UI 只是 UI，官网偏向价值传递，但是只有文档记录了这个产品所有的核心能力，从功能到 SDK 还有 API，甚至还能覆盖到一些 content marketing 的策略，doc 是最全面理解一个产品能力范围的途径。

正如前文所说，技术产品能力不足是原罪，解题思路千差万别毋需纠结，但是要对他解决的 use case 有所分析，帮助捕捉自己产品遗漏的场景和用户。

太久没更新，一下子飙了8000多字，还没有写到 GTM 的探索部分，我们下期再见吧。最后说一些很个人的鸡汤话题。

我们是一个没有所谓专门的“产品经理”的团队，但在日常工作中除了 workload 会大一些之外，在产品经理的能力覆盖上并没有什么 gap。

定义用户场景，需求，制定 roadmap，沟通，了解用户，这些其实是一些通用的思考和策略能力，与之相反的是工程，算法，设计，数据分析，这些需要很强的执行和落地能力。

思考和执行，两面是可以相互叠加的，也可以同时出现在一个人身上，并且可以互相帮助两个维度的成长。如何平衡思考洞察和执行，也是我在创业过程中，自我成长中一直想要寻求 balance 的点。

在快速迭代的环境中，其实就是两件事：做什么和怎么做，所以，在这个前提下，所谓的产品设计流程里，交互和 UI 就只会成为表达的工具和武器。最后，由整个团队去协力调整我们所有产品整个 package 的呈现。

但是问题的关键是，开发者产品，to developer 是一个极为特殊的领域。需求我定义，产品我来设计，我还不是开发者，这能行吗？

没有什么秘诀，我只能说一些鸡汤，没有捷径，但是可行：硬着头皮去做。

1. 所有深入的研究都是有回报的。我记得我有太多次研究技术需求把自己绕晕了的场景，回顾之后，其实可能是 1/10 的理解上的 gap 再乘以 1/10 的沟通的 gap，就会造成看似 100 倍的复杂度。要充分相信自己，即使自己不是开发者，只要有基本的理工科素养，肯定也可以理解到至少 80% 左右。我为什么可以如此自信：我不是一个脑子转的很快的人，尤其是一些小的逻辑，需要时间和理解消化，临场反应遇到压力非常容易懵。但是后续给到时间捋一遍，发现很多事不如想象的那么难，并且会变得更加深刻，当再次讨论的时候，这些理解会变成条件反射一样给到你准确的直觉上的判断。有些不合常理的复杂，肯定是中间过程环节出了问题，需要再次研究一下。

2. 相信自己的开发者同伴，理解他们看待问题的思维方式。我从来没有和这么多开发者同事合作做一款产品，整体体验下来，他们可真是直线条啊，每一个细小的逻辑链接紧密得密不透风，全是细节，如果沟通中出现一两个模糊或者没有通顺的点，很容易出现沟通问题。为了提高效率，我在表达中也渐渐 push自己学会倾听，然后在沟通中可能会出现误解的点加以注释避免跑偏。（其实对我来说是件难事，我一直是一个比较强势，喜欢输出，并且让别人配合我的工作风格的人）

3. 自己 handle 不了的，自己可以成为那个帮助 drive conclusion 的那个人，而非执着于自己是不是 decision maker 或者纠结于一两个决策是我做的还是别人做的。我们为落地和结果负责，落实到决策上是你的想法，还是我的想法，这些都不重要。

我们团队的小伙计大部分都是开发者，在与他们合作的过程中，我也学到了很多：

1. 自己的动手能力变强了，之前的思维惯式是用说服的方式合作，现在学会了探索优先用工具解决问题。

2. 合作方式更多样化。我是一个思维上喜欢不断抽象并且比较 top down 的人，之前的模式是希望通过表达和说服的方式，把所有人拉齐，形成一个高度对齐的目标并且达成绝对的一致再集体执行。但是现在学会了通过 <想法-实践-小成果> 的方式去推进事情。它没有改变我思维模式，但在执行和推进事情上增加了具体的 action item 和可执行度，这种改变我也很开心。

太长了太长了，整一个 next chapter 吧！

欢迎开发者产品工作者，程序员朋友们与我交流，我说得不对的，班门弄斧的，欢迎留言呦。

相关历史文章

如何确定是否有必要开发新功能

我的“半创业者”生活

做工具设计的一些观点