shidenggui (shidenggui)

[上海] 0522 线下聚会

shidenggui — Sun, 23 May 2021 13:24:03 +0800

昨天社区线下聚会，有幸借 @Ovilia 的光，和 Github 中国区独一枚超大 Star 合了影

@Ovilia 分享了刚上架的读书笔记 App 众山小 https://omynote.com

@_hisriver 分享了他为开发者打造的效率工具集 https://huhu.io

@aloveric 则是他萌萌的像素天气

@shidenggui 则是他基于卢曼卡片盒新打造的笔记 App 元思笔记

在上海感兴趣的小伙伴欢迎来参加👏

新品发布：元思笔记 - 打造自生长的知识网络

shidenggui — Mon, 10 May 2021 21:47:19 +0800

「元思笔记」缘起

陆陆续续接触过很多笔记软件，包括 Evernote、Marginote等，但一直没养成记笔记的习惯。

年前接触到了大火的 Roam Research，其支持的块引用，双向链接等功能用来管理一些信息蛮方便的。就对启发了作者的卢曼卡片盒笔记方法产生了好奇，进而追溯到了介绍该方法的书籍《How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking》。正值过年在家，果断开始读起。

在阅读中发现 Roam Research 其实并不是纯粹的卢曼卡片盒笔记软件，只是吸取了其一部分理念。而原版的卢曼卡片盒笔记方法更对我的胃口，经过一番查找，发现手机端并没有比较好的对应软件，就想着能不能自己开发一款。这便是「元思笔记」的起源。

卢曼卡片盒

该笔记方法致力于构建自生长的知识网络，来辅助思考和输出。由此总结的几条原则

Garbage in，garbage out

慎重对待你将要记录的信息，评估是否将其纳入你永久的知识网络之中。

重述而不是记录

所有的笔记都应该经过自己的重述，而不是单纯的记录。

原子化

以卡片为单位记录笔记，每张卡片应当包括足够的信息以使其可以被单独理解。

创造关联

尽可能的创造不同卡片之间的关联，并补充对应的上下文。

"汲取日常中的奥秘，吐露冰雪般的凝思"

综上原则，元思选择了特罗斯特朗姆诗集《沉石与火舌》译者对其诗句的评价：“汲取日常中的奥秘，吐露冰雪般的凝思” 作为 slogan。正贴合元思构建卡片的理念。

下面是正式介绍：

元思笔记 - 打造自生长的知识网络

元思笔记是基于卢曼卡片盒而开发的极简笔记软件。

通过创建知识卡片以及维护它们之间的关系来构建自生长的知识网络。

本地保存内容，保证隐私安全
支持随时导出导入备份
支持双向链接以及父子关系关联
支持简略 Markdown 格式

尾声

过年期间元思基本功能就已经开发的差不多了，到五一抽空整理上架，中间自己试用了两个多月的时间。总共积累了 574 张卡片，上千条卡片之间的关联关系，约五万字的纯手打笔记。相比之前自己的笔记方法可以说是一个飞跃。

目前安卓版本已经上架了，iOS 正在审核中。后续准备开发基于 webdav 的云备份和桌面端。感兴趣的朋友欢迎下载体验，也欢迎对笔记方法感兴趣的入群交流。

元思笔记官网: https://shidenggui.com/metaslip

2021-05-13

iOS 版本上架了，欢迎体验👏 https://apps.apple.com/cn/app/id1565362148

附录

详细介绍卢曼笔记盒的一篇非常不错的译文：卡片盒笔记法详细介绍
之前参加神兽之间书店《沉石与火舌》读书会的会后分享: 阅读之初是被诗人凝练意象所构建的画面吸引。在凝视的过程中，这画面竟借着时空的涌动而缓缓展开，在静与动的转换中一个意象钩沉着一个意象，直到将整个人都拉入诗中，陷入深深的共鸣。

首发于个人博客 shidenggui.com 与 w2solo 社群。

[上海] 独立开发者线下聚会 Indiehackers Friday (2020-10-24)

shidenggui — Sun, 18 Oct 2020 23:08:37 +0800

2020-10-24 周六聚会

@metrue 不加班的程序员，工作到半夜的奶爸. 最近在打造一款全宇宙最简单的写博客的应用: https://giki.app
@aloveric ：全栈，拥有 20 几款苹果生态应用的开发者，包括萌萌哒的像素系列和二次元 Avater，及本社区 iOS 端 IndieHackers 等，B 站 UP 主
@istarwyh 有建筑/环境专业背景,略懂金融,马上毕业做码农.在做 Java 成长为架构师的路上越走越宽 (pian),主要产品是和同学合作的华为云 DevUI 组件库的配套插件DevUIHelper，可省去反复查看文档写页面的麻烦.目前想做一个英语地道写作神器 writingHelper,希望能帮助向我一样从小写英文作文就抓耳挠腮的人.
@shidenggui 全栈，小说推荐应用 - 推书君 App 、独立博客导航站 bloghub.fun、开源库 easytrader 作者。个人博客: shidenggui.com
@guyskk Python Web 开发者，全栈，想做很多好用的产品，向往自由的生活方式，正在走向独立开发的道路。目前的作品是: 蚁阅 - 让 RSS 更好用。个人博客: https://blog.guyskk.com 。

[上海] 独立开发者线下聚会 Indiehackers Friday (2020-10-08)

shidenggui — Sun, 18 Oct 2020 23:02:40 +0800

##2020-10-08 国庆聚会

参加者 (从左到右)：

@ 羡辙 iOS 开发者，2019 字体日历作者，博客
@PersiLiao 自由职业，正在探索独立开发者。
@shidenggui 全栈，推书君 App 作者
@ 赵劲松少见的涉及硬件的程序开发者

[上海] 独立开发者线下聚会 Indiehackers Friday (2020-10-02)

shidenggui — Sat, 03 Oct 2020 16:09:54 +0800

2020-10-02 国庆聚会

参加者 (从左到右)：

@ 赵劲松少见的涉及硬件的程序开发者
@guyskk 蚁阅的作者。
@shidenggui 全栈，推书君 App 作者

过程：

本来是五个人参加，但是有两人因事缺席，@ 赵劲松就邀请我跟 @guyskk 去他公司坐坐，顺便一起吃个饭。

很巧的是我跟 @guyskk 都在世纪公园旁边，所以早上先去了 @guyskk 附近的地铁站汇合。

之后成功到达 @ 赵劲松的公司，大家分别介绍了下自己的产品，@ 赵劲松经历丰富，90 年代就开始鼓捣程序了。

晚餐去了附近的一家 90 后创业的网红面馆，确实有点震惊，不愧是网红。

最后兴尽而散。

想参加的小伙伴点击这里

独立开发者社区线上聚会 (2020-09-26)

shidenggui — Tue, 29 Sep 2020 11:38:40 +0800

2020-09-26 周六线上聚会

@aloveric ：全栈，拥有 10 几款苹果生态应用的开发者，包括萌萌哒的像素系列和二次元 Avater，及本社区 iOS 端 IndieHackers 等，B 站 UP 主
李 BoBo ： X++创始人，B 站 UP 主
@kiddyu ：新趣集开发者
@shidenggui ：全栈，推书君 App 开发者
@litang0908 ：钱迹 App 开发者

过程：

七点开始，李 BoBo 作为主持人准时开始。@litang0908 因为要去机场接个人，先旁听。

接下来大家依次介绍了下自己的产品和基本经历，然后九点的时候@litang0908 顺利归来，接棒。

中间的提问环节，参与者爆了很多干货，包括如何推广、收入情况、想法来源等等。

@aloveric 的像素系列在 App Store 的浏览量有十几亿，吓人一跳。让我们一窥苹果推荐带来的流量之大。

@litang0908 曝光了下后台数据，收入喜人，提振了小伙伴对独立开发的信心。

李 BoBo 主要是关注文旅产品，目前在日本乡村旅居了大半年，过着悠闲的田园生活。

@shidenggui 吐槽了下个人做重运营类产品的深坑，后面一定要吸取教训。

@kiddyu 探讨了自己最近几个 App 被拒的经历，引发了大家的共鸣。

最后进入闲聊侃大山阶段，聊到了十一点多后，兴尽而散。

想参加的小伙伴点击这里

[上海] 独立开发者线下聚会 Indiehackers Friday (2020-09-25)

shidenggui — Sat, 26 Sep 2020 14:01:50 +0800

2020-09-25 周五聚会

@istarwyh devuihelper插件作者之一
@Maskmale 专注维吾尔语言的 iOS 开发者，维吾尔系列应用
@shidenggui 全栈，推书君 App 作者
@aloveric 全栈，拥有 10 几款苹果生态应用的开发者，包括萌萌哒的像素系列和二次元 Avater，及本社区 iOS 端 IndieHackers 等，B 站 UP 主

过程：

一点多小伙伴陆续到齐，发现 @aloveric 选的星巴克在内衣商店的包围中 🤣，不过据他说也是听朋友推荐的.

@aloveric 开了 B 站直播，大家简单介绍了下自己的产品，没想到高峰有 160 多人观看，果然摸鱼无处不在😏。

为了避免晚高峰四点多前往耶里夏丽餐厅聚餐，路上顺便考察了下有没有更好的聚会地点。晚餐是很有特色的新疆美食，大家聊到 8 点多，兴尽而归。

想参加的小伙伴点击这里

[上海] 独立开发者线下聚会召集 Indiehackers Friday

shidenggui — Thu, 24 Sep 2020 13:27:54 +0800

认识了不少独立开发者，都是默默一人码代码。突然想到如果能每周抽一天，大家在一起写写代码，聊聊天，岂不惬意。

目前暂定地点为人民广场附近星巴克。

时间为周五下午一点到四点，避开早晚高峰。如果人多可以酌情约午餐。

规则随意，可参考默默会

报名方式：

扫码进群

或加以下管理员微信，备注上海聚会

@shidenggui : lsdg1993

@aloveric : aloveric

2020-09-25 周五聚会

@istarwyh devuihelper插件作者之一，
@Maskmale 专注维吾尔语言的 iOS 开发者，维吾尔系列应用
@shidenggui 全栈，推书君 App 作者
@aloveric 全栈，拥有 10 几款苹果生态应用的开发者，包括萌萌哒的像素系列和二次元 Avater，及本社区 iOS 端 IndieHackers 等，B 站 UP 主

过程：

一点多小伙伴陆续到齐，发现 @aloveric 选的星巴克在内衣商店的包围中 🤣，不过据他说也是听朋友推荐的.

@aloveric 开了 B 站直播，大家简单介绍了下自己的产品，没想到高峰有 160 多人观看，果然摸鱼无处不在😏。

为了避免晚高峰四点多前往耶里夏丽餐厅聚餐，路上顺便考察了下有没有更好的聚会地点。晚餐是很有特色的新疆美食，大家聊到 8 点多，兴尽而归。

2020-10-02 国庆聚会

参加者 (从左到右)：

@ 赵劲松少见的涉及硬件的程序开发者
@guyskk 蚁阅的作者。
@shidenggui 全栈，推书君 App 作者

过程：

本来是五个人参加，但是有两人因事缺席，@ 赵劲松就邀请我跟 @guyskk 去他公司坐坐，顺便一起吃个饭。

很巧的是我跟 @guyskk 都在世纪公园旁边，所以早上先去了 @guyskk 附近的地铁站汇合。

之后成功到达 @ 赵劲松的公司，大家分别介绍了下自己的产品，@ 赵劲松经历丰富，90 年代就开始鼓捣程序了。

晚餐去了附近的一家 90 后创业的网红面馆，确实有点震惊，不愧是网红。

最后兴尽而散。

2020-10-08 国庆聚会

https://indiehackers.net/topics/635

2020-10-17 周五聚会

https://indiehackers.net/topics/636

BlogHub 上线了，开源独立博客聚合站，一起来发现更多有趣的灵魂

shidenggui — Tue, 03 Mar 2020 12:48:20 +0800

缘起

离我在 2013 年第一次搭建博客已经过了好多年了，但惭愧的是这两年才开始认真写博客，不久前我终于开发了自己的独立博客 Shidenggui's Blog。

在维护博客的过程中，我认识了很多朋友，每次偶遇他人的博文，有时觉得原来世界上竟有人可以这样生活、原来有人跟我的想法那么接近。

我常常想，那么多有趣、好玩的独立博客，该如何被我们发现呢？这就是 BlogHub 的起源。

诞生

灵感的火花

最近一段时间，独立开发者社区的小伙伴群里都在讨论独立博客的种种痛点，包括图床、评论、访问速度、流量等问题。而此时我正好开发完自己的博客，苦恼于搜索引擎的收录和宣传，也在和认识的小伙伴们交换友链。在这个过程中，我认识了很多新朋友，也发现原来还有那么多有意思的独立博客，以前的我竟一无所知。

付诸行动

在中文互联网质量不断下滑、越加封闭的现在，仅存的独立博主们依旧保持着互联网最开始的开放、自由的精神，默默产出高质量的思考，有没有可能做一个中文独立博客聚合站，聚合大家的文章，让大家有机会发现更多有趣的博主，认识更多的朋友呢？

在一开始我非常幸运的发现了 timqian 维护的 chinese-independent-blogs 项目，这样初期数据源问题就解决了。

而去过我博客的朋友会发现，BlogHub 的样式跟我的博客网站很像。这不是偶然，一开始为了开发速度，复用了我的博客 90% 的代码。整体基于 Javascript，采用了 Nextjs 和 Nestjs 以及 GraphQL。

最后就是起名了，不久前知道了 DIYgod 的 RSSHub，非常喜欢 Hub 这个单词所代表的的互联互通之意，BlogHub 因此诞生了

在购买域名的过程中，幸运的发现了 .fun 后缀。选择开源，选择聚合独立博客，不就是为了认识更多朋友、有更多的小伙伴一起来玩，在这个过程中享受乐趣吗？

因为上面几点的帮助，所以仅仅开发了不到一周，bloghub.fun 就上线了。

希望

「子曰：有朋自远方来，不亦说乎」

希望 BlogHub 也能让大家发现更多有趣的灵魂，结交更多的朋友。

尾声

bloghub 项目初级雏形，后面还有很多需要改善的地方，代码开源在github.com/shidenggui/bloghub

对此有兴趣的朋友可以加入Telegram 群组 · 微信群组，如果扫码满了可以加我好友拉你进群，一起来交流。

首发于 shidenggui.com

现在还有必要拥有独立博客吗？谈谈我的独立博客史

shidenggui — Sun, 23 Feb 2020 08:15:24 +0800

缘起

一直想拥有一个属于自己的独立博客，这或许算是我作为程序员的执念之一吧。

为什么

因为我从别人的博客中收益良多。像学习 Vim 的时候拜读过酷壳的简明 Vim 练级攻略，还包括谷歌搜索时经常接触的其他优秀文章，期待有一天我也可以通过文章来帮助别人。

希望认识更多志同道合的朋友，人生太短，世界太大，如果有一天因为博客而结缘，进而成为朋友，不是很美妙的事情吗。这几年我通过博客认识了好几位朋友，虽然不多，但是都保持着不错的关系，我也期待着别人通过我的博客认识我的那一天。

希望能有一个自留地，有些话想说，有些事想做，有些回忆想留下。而假手他人，总不如自己可靠。

为什么一定要独立博客？

不可以依赖公众号、CSDN 等博客系统吗？曾经的我也是这样想的，为什么一定要这么麻烦，重要的不是写文章这件事吗？是的，最重要的是开始写。我也曾经使用静态博客、Github Isuues，以及公众号的方式来托管文章，但是随着长期使用它们总有不尽如人意的地方，后面会在我的独立博客史中谈到。核心的问题在于：我们并不能真正享有我们文章的所有权。

我的独立博客史

第一个博客，大学时代的初次尝试：WordPress

我在学生时代早期一直有记日记的习惯，然而到了高中后期因为学业的原因放弃了，除了不久前又尝试记录过一段时间，从此再也没有捡起来过。

到了七八年前的大学时代，希望能有一个地方记录我生活的念头再次燃起，这时候瞄准了功能强大的 WordPress，使用了当时新潮的 .me 域名，尤记得我的服务器是申请了 Github 的教育优惠，用领的 100 美金代金卷购买的 DigitalOcean 最便宜的 5 美刀一月主机，好不容易搭建上线之后发现因为外网的缘故，国内访问非常卡，而且 WordPress 本身非常臃肿，体验并不好，在断断续续写了几篇文章后就废弃了。

第二个博客，毕业后再起航：Jeklly 静态博客

时间荏苒，大学很快结束了，我于 2015 年 6 月底毕业，工作之后接触的多了，再次希望能有一个地方呼吸除了工作之外的清新空气。

第二个博客吸取了教训，为了专注写文章这件事情，选择了 Jeklly 这种静态博客，托管于 Github，于2015年8月17日上线。在这里第一次认识到 Markdown 文件格式，后面一直基于此编写文章。博客上线初期写了几篇文章，后面因为系统故障，本地原始文件丢失，然后才发现 Jeklly 竟然只保存了渲染后的静态 html。

原始文件的丢失加换工作的缘故，进入了 9106 的高强度模式，情绪低落就没有继续写了。而博客也随着 .me 域名的到期而关闭，只留下 Github 的仓库遗迹。

第三个博客，不死心之再出击： Github Issues

正所谓念念不忘，必有回响。在第二个博客关闭的两年半后，2018年3月5日，我选择了 Github 的 Issues 继续我的博客之旅。

经过两次失败的沉痛反思和近五年的时光，我认识到不管使用如何花哨的技术，如果我不能保证持续的产出文章的话，我的独立博客之旅就要在此终结。我不甘心啊！

我告诉自己，这次我一定可以成功，因为我的独立博客之魂还在燃烧。而最重要的就是专注写文章，专注写文章，专注写文章。

这也是我选择 Github Issues 的方式，简洁、无广告，同时把 Blog 仓库置顶到首页，作为一个每天都上 Github 的来说，也是对自己的一个提醒和激励。

这次我成功了，在花了一年多写了十来篇博客后，虽然产量不高，但是我发现坚持写文章对我来说已经不是问题了（如何坚持有机会额外分享）。而这时 Github Issues 的缺点也渐渐暴露了出来。

贴图困难。我之前都是手动截图，传到 Github 仓库，然后链接原始文件地址，非常繁琐。后面贴图的问题通过 upic 这个小工具有所缓解
分享困难。我有些读书笔记想和我的朋友们分享，但不是所有人都是程序员，访问 Github 对某些人来说太不方便了。
交流困难。因为分享困难，导致我的文章基本没有互动，除了第一篇文章有 10 来条捧场评论，后面在两年间通常只有一到两条评论。
没有统计。对于文章的相关数据基本一无所知，再加上评论的稀少，给自己一种玩单机游戏的感觉。
没有订阅。虽然有 Watch，但是功能还是太弱了，基本上可以说是可有可无。

第四个博客，有苦有乐：公众号

这时候我了解到了公众号这个平台，觉得对以上几个问题是比较好的解决方式。一开始是在 Github 发布文章之后再手动同步到公众号，但是很快我就喜欢上了公众号的体验。

文章在公众号的阅读量和活跃度比在 Github Issues 高的多，而且跟朋友的交流也很方便，附带的数据统计也够用。这时因为贴图过于繁琐的问题，我渐渐不再同步内容到 Github Issues 上了。

在公众号写作了快一年后，公众号的缺陷也慢慢暴露出来了。

更新文章受限。文章发出后，只能有一次机会修改二十五个字。有时候只能通过留言来纠正，体验并不好。
广告嫌疑太浓。公众号目前的营销和商业氛围太浓。有时候跟朋友或者在群里聊天，都不敢发自己的公众号文章链接，总感觉自己是在打广告，特别羞耻。
无法被搜索引擎收录。文章的阅读数集中在发表后的一两天内，之后基本不再增加，除了特意翻看历史文章的人，基本不再有机会被曝光。
无法外链。之前我经常外链 Wiki、Github 等丰富文章内容，而公众号只提供一个阅读原文，有时候真的让人感觉非常不便。
自定义功能太弱。比如我想跟朋友交换友链、加上作品列表、支持 RSS 订阅、放上 Github 链接、这在公众号的系统中是无法满足的。

第五个博客，浴火重生：自己开发 shidenggui.com

其实很早前就动过开发博客系统的念头，本身作为一个后端工程师，博客系统可说是非常简单的应用。但是真正的问题在于前端，之前也曾自学过 CSS 和 Javascript，但 CSS 给我留下了难以掌握的心理阴影，尤其是其中的 Float 布局。

不过最近一年事情出现了转机，我花了不少时间打磨我的小说推荐网站推书君 (www.tuishujun.com) 以及对应的小程序版本，在这个过程中我渐渐熟悉了前端，虽然还称不上专业，但是我想开发一个简单的博客应该是够了。

时机成熟了，我告诉自己，而且正逢春节在家隔离，时间充裕。说动就动，在吸取了前几个博客的教训之后，做了以下几点考虑：

文章依旧使用 Markdown 编写，显示的时候渲染为 HTML。现在有很多优秀的 Markdown 编辑器，比如 typora 等，没有必要再实现一套复杂的编辑系统。而文章的元信息比如创建时间等参考了 hexo ，使用 YAML 附加于文章头部。
支持搜索引擎收录。使用支持服务端渲染的 SSR 框架 Nextjs。
保证加载速度。CSS 使用 Tailwincss，基本没有单独写过样式类，CSS 大小控制在 5K 以下。尽量减少 Javascript 类库的引入。使用 CDN 进行加速。
提供 RSS 和公众号两种订阅方式。
尽量小的内存占用，降低后续维护成本。使用 Docker 打包，整个博客包括使用 Nestjs 的后端，内存占用 170 MB。

总体开发花了三天时间，其中一天用于将公众号和 Github 的文章改为当前的 Markdown 格式，于2020年2月14日正式上线。

独立博客上线一周了，带来了什么变化？

说实话，效果有点超出我的预料，容我细细道来。

友链

博客上线之后，第一步自然就是跟朋友交换友链了，终于给朋友们的博客地址找了一个好家。

更好的文章分享支持

在发推或者 tg 群里面聊天的时候，常常会看到别人贴的链接有特效，而自己贴的文章却不行，研究后发现是需要在网页中添加关于社会化分享的配置，这次也给自己的博客加上了。

更好的传播

程序员的交流还有很多一部分不处于微信生态圈，而大家也大多不愿意分享微信文章链接。

博客上线一周之后，我遇到了一个针对开源开发者的福利活动，整体流程比较复杂，有不少朋友遇到问题，我就写了一篇自己的操作流程分享到博客上，看能不能对大家提供帮助。没想到大家非常热情，也有不少朋友写文章的时候顺带提了一句，结果这篇文章在三天不到的时间收获了两万多的阅读。

虽然是暂时的，不过还是很高兴能给那么多人带来帮助，也算是给自己的博客开了一个好头。

一些小问题

图床：图片的存储一直是独立博客比较烦恼的问题，我这次使用的是 gitee 的图床，当后来发现图片无法在微信浏览器中正常加载，比较恼人，后续准备换用自己的存储系统，具体还在调研中。
原创保护：之前我在公众号翻译过一篇谈产品的文章，反响比较热烈，好几个人找我开转载白名单。而这次发布的教程文章同样受到好评，但是我在一天后发现 segmentfault 和知乎已经有了我的盗文，而我却没什么太好的办法。

尾声

博客刚刚上线一周，有很多小细节还在优化中，有些功能尚待开发，不过也收获了很多惊喜，后面我也会持续努力。

如果大家对独立博客有兴趣的话，欢迎加我好友 (博客右上角订阅/公众号菜单)，一起交流。

以一段话纪念我这曲折的独立博客史：

天方国古有神鸟，名「菲尼克斯」(Phoenix)，满五百岁后，集香木自焚，复从死灰中更生，鲜美异常，不再死。 ————《凤凰涅槃》

首发于个人公众号「食灯鬼」以及个人博客 https://shidenggui.com/articles/why-blog

独立开发者线下十二人聚会邀请 [上海站]

shidenggui — Tue, 24 Dec 2019 21:03:48 +0800

独立开发者线下十二人聚会邀请

996 高压下的程序员，还有一个很酷的选择。成为独立开发者，重新定义自己的生活，工作和价值。

真的很酷，我希望认识更多同样酷的人。

聚会的目的是希望可以让独立开发者们有一次相互交流的机会，已经有稳定运营的产品的开发者们，可以相互交流产品的经验，还在孵化中的开发者可以让自己少走一些弯路。有想法还没有踏出第一步的开发者，可以迈出第一步。

四到六人演讲，其余可进行闪电演讲。四人演讲需提前排练准备。

演讲进行一次线上练习，一次现场练习。

活动运营过程中，了解每一个活动参与者。包括背景，年龄，是否工作，行业，职业，产品或想法。

从这些信息中选拔出负荷条件的十二人。

以上文案感谢 @cj 的撰写，邀请链接：点此

我是如何一步步打造爆款产品，以及对应方法论 | 翻译

shidenggui — Sun, 15 Dec 2019 14:59:15 +0800

缘起

之前在独立开发者社区的群里，有个小伙伴转发了一篇关于产品的文章，是关于一个两度创业成功的人，如何通过他的思考，总结出打造爆款产品的方法论以及实践过程，内容非常详细，可以说是手把手指导也不为过。

我读过之后大呼过瘾。当时小伙伴说他之前想翻译，但苦于没有时间，我就自告奋勇接下了这个任务。这里表示感谢群友嘉文的帮助和校对，使得翻译顺利完成。接下来就不多说了，请欣赏正文。

本文首发于个人公众号「食灯鬼」和「独立开发者」社区，若无授权，请勿转载。

公众号文章传送门

正文

Superhuman 如何构建驱动引擎以达到产品市场契合

以下文章来自 Rahul Vohra，Superhuman 的创始人和 CEO，一家致力于最快邮件使用体验的初创公司。

所有人都听过产品市场契合（Product / Market fit，以下简称 pmf）驱动初创公司走向成功，而每一家失败的公司背后基本都潜伏着未达到 pmf 的问题。

对于创始人来说，从第一天起就有着尽快达到 pmf 的执念。它既是我们急于清除的巨大障碍，也是让我们夜不能寐、担忧永远无法达成的恐惧。但当我们想要弄明白到底什么是 pmf ，以及如何做到的时候，大部分人很快就认识到并没有一种经过实战检验的方式。

在 2017 年夏天，我正在极力为我的初创公司 Superhuman 找到一条达到 pmf 的道路。通过阅读一些经典的博客和影响深远的文章，我有了一些印象深刻的观察结果。YC 创始人 Paul Graham 认为 pmf 是你做了一些人们需要的东西，而 Sam Altman 认为 pmf 是用户开始自发的宣传你的产品。当然，最常见的定义来自于 Marc Andressed 2007 的 blog:

” 判断 pmf 没有达到是很简单的。用户没有从你这里得到太多的价值，他们没有自发的宣传你的产品，使用量没有快速增长，新闻评论不温不火，销售周期过长，以及很多未完成的交易。

而判断 pmf 达到同样也很简单。用户以你所能生产的最大速度购买你的产品，使用量增长的跟你购买服务器一样快。用户把钱堆到你的公司账户。你尽你所能的招聘销售和客户支持人员。媒体人员不断的在打电话给你，因为他们知道你做了一些热门的好东西，想要采访你。你拿到了哈佛商业评论的年度企业家。投资者们蹲守在你的房前”

这是我对 pmf 的最生动的想象，这番画面让我泪流满面。

我们在 2015 成立工厂开始编写 Superhuman 的代码。一年后我们有了 7 个人，我们仍然还在狂热的编码中。到了 2017 年夏天，人数到达了 14 人，依旧是继续编码。这时，我感到了来自团队我和自己的，与日俱增的上线压力。我之前的公司 Rapportive 在更短的时间内启动、扩张并被领英 (LinkedIn) 收购了。然而此时，我们已经花了两年时间，却什么还没有。

但是不管压力多么巨大，我还是没准备好上线。通常大家都说 “不管怎么先上线，看看反响再说”，这对那些只投入了几个月时间，沉没成本还不高的公司可能适用。但是” 先上线看看反响 “对我来说，太不负责任和鲁莽了，特别是想到我们投入的这几年时间。

而我身为创始人不能把我的感受直接告诉我的团队，这也加剧了我的压力。这些雄心勃勃的工程师为这个产品倾注了全部心血。我没办法跟他们说这个产品还没准备好，更糟糕的是，也没想到任何办法摆脱这种情况。我一直在努力，想要找到正确的语言或者框架来搞清我们当前所处的位置，并规划好之后到达 pmf 的步骤。

因为我找到的关于 pmf 的描述对上线后的公司非常有帮助。如果上线后，收入没有增长，融资困难，媒体毫无兴趣，用户增长非常贫乏，你可以说你没有达到 pmf。但实践中，因为我之前创业成功，在融资上并没有遇到问题。我们有意拒绝了媒体采访邀约。当前我们选择只服务一小部分内测用户，所以也谈不上快速增长。对于处在内测阶段的我们来说，此时没有任何指标可以明确是否达到了 pmf。

这些关于 pmf 的描述都太事后诸葛亮了，太过不切实际。我清楚的知道公司的情况，却没办法把这一点传达给其他人，也不知道公司下一步的计划。

所以我绞尽脑汁想要搞清楚如何让 Superhuman 从当前的位置更进一步，达到 pmf。最后我开始思考：如果我们能衡量 pmf 呢？因为如果你能衡量 pmf，或许你就可以改善它。甚至你可以系统的提高 pmf 直到达到你的预期。

围绕这一目标重新定位，我开始反推达到 pmf 的过程。下面是我的发现，特别是如何清晰的定义 pmf 指标并构建 Superhuman 驱动引擎达到 pmf 的四个步骤。

围绕一个指标：达到 pmf 的领先指标。

在我理解 pmf 的过程中，我读了所有我能读到的书，并与每一位我能找到的专家交流。当我遇到肖恩·埃利斯 (Sean Ellis) 时，一切都改变了。他在 Dropbox、LogMeln 和 Eventbrite 创立之初负责早期增长，后来又创造了 “增长黑客”(growth hacker) 一词。

我找到的 pmf 定义非常形象和具有说服力，但它们是滞后指标——当投资人蹲守在你的房子外时，你已经达到了 pmf。相反，埃利斯找到了一个先行指标：只需要问问用户，如果你无法使用我们的产品，你会感到多么失望？然后记录回答 “非常失望” 的人的比例。

埃利斯通过调查将近 100 个初创公司，发现了魔法数 40%。通常少于 40% 的用户回答 “非常失望” 的公司都努力寻求增长，而那些具有强大吸引力的公司几乎总是超过这个门槛。

问问你的用户，如果他们不再使用你的的产品的话，他们有什么感觉。那些回答 “非常失望” 的人是解锁 pmf 的钥匙。

Hiten Shah 做了一个有用的尝试，他在 2015 的开放研究项目中，发了埃利斯的问题给 731 个 Slack 的用户，51% 的用户回答如果没有 Slack 的话，他们会非常失望。由此可见 Slack 在 50 万付费用户时已经达到了 pmf。如今，考虑到 Slack 传奇般的成功故事，这点显而易见。不过由此可以看出达到 40% 这个指标有多么艰难。

在这种方法的启发下，我们开始测量 Superhuman 的反响怎么样。根据埃利斯的建议，我们以最近两周使用过产品核心功能至少两次的用户为准。(当时我们应该有 100 到 200 个可调查用户，但是规模更小、更早期的初创公司也不要羞于使用这个方法 —— 大概 40 个左右的回复就可以给出大概正确的方向，远比大部分人想的少)

然后我们开始通过邮件给这些用户发送调查问卷询问以下问题：

1. 如果你不再能使用我们的产品，你的感觉如何？

A. 非常失望
B. 有点失望
C. 不失望

2. 你认为我们的产品对哪些人最有用？

3. 你觉得我们产品最有用的地方是哪里？

4. 怎样才能让我们的产品变得对你来说更有用？

通过收集的反馈，我们开始分析第一个问题：

只有 22% 的人投票给 “非常失望” 这个答案，这清楚的表明 Superhuman 没有达到 pmf。虽然这个结果令人沮丧，但我却充满了斗志。我现在有了一个工具可以向团队解释当前的处境，更令人兴奋的是，我们据此有了一个可以提高 pmf 的计划。

从基准到驱动引擎：优化 pmf 的四个步骤

下定决心后，我把所有精力都聚焦在如何提高我们的 pmf 。我们需要形成一个达成 pmf 的框架，而用户对每个调查问题的反馈都是该框架的关键素材。

以下是我们 pmf 引擎的四个组件：

1) 细分以找到你的支持者，进而刻画出高期望客户。

通过你的早期宣传，你可能会吸引到各种各样的用户，特别是如果你开了产品发布会同时产品是免费的。

但其中的许多用户可能不是你的目标用户，他们并不真正需要你的产品，你的产品也并不适合他们。你并不想这些人成为你的用户。

作为早期团队，你可以先入为主的将目标市场限制在你认为的细分用户上，但这并不能教给你任何新东西。相反，如果你使用回答 “非常失望” 的用户作为一个透镜去缩小市场，数据本身就能说明问题，甚至你可能找到新的非常契合你的产品的市场。

对我来说，细分的目的是为了找到产品能拥有更好的 pmf 的领域，这些领域我可能忽略了，或者没有考虑到。

一开始，我们将用户按照第一个问题分组（如果你不再能使用我们的产品，你的感觉如何？）

我们给每个填写问卷的用户分配了一个角色。

接下来，我们研究「非常失望」组的用户（占比最大的 22% 支持者），并利用这些特征来细分市场。在这个简化的例子中，你可以看到我们主要关注创始人、经理、高管和业务发展人员——暂时忽略了所有其他角色。

通过这种更加细分的视角来观察我们的数据，数字变了。通过聚焦「非常失望」组的用户，我们的 pmf 上升了 10 % 之多。虽然离渴求的 40% 还有一点距离，但是我们用最小的努力拉近了距离。

为了更加深入的探索，我想更好的了解真正热爱我们产品的用户。我希望尽可能生动的描绘他们的用户画像，以便激励我的团队给他们更好的服务。

我利用 Julie Supan 的高期望客户框架来做到这点。Supan 指出，高期望客户（HXC）并不是一个具有多重角色的用户，而是在你目标群体中最有洞察力的用户。最重要的是，他们能从你的产品中获得最多好处，并帮你传播口碑。例如， Airbnb 的高期望客户并不只是想要访问新地方，同时也希望拥有归属感。对 Dropbox 而言，他们的高期望客户希望保持井然有序，简化生活并保证他们的工作成果不受损害。

带着这种想法，我试图找出 Superhuman 的高期望客户。我们基于「非常失望」组的用户分析他们对第二个问题的反馈：你认为我们的产品对哪些人最有用？

这是一个非常有力的问题，因为快乐的用户通常都会描绘他们自己，而不是其他人，使用那些对他们最关键的词语。你会了解你的产品对哪些人有用，以及那些会与他们产生共鸣的语言（也为你的市场营销提供了非常有价值的核心视野）。

基于用户的语言和 Supan 的建议，一个栩栩如生的 Superhuman 高期望客户的用户画像出现在我们眼前：

“妮可是一个努力工作的专业人士，她与许多人打交道。举例来说，她可能是 CEO、创始人、经理或者业务发展人员。妮可长时间工作，往往周末也不休息。她认为自己非常忙，希望能有更多时间。虽然妮可自认很有效率，但她意识到自己还可以做的更好，偶尔会花时间想办法提高自己。她大部分的时间都花在她的收件箱，每天大概阅读 100-200 封邮件以及发送 15-40 封邮件（忙的时候一天可能发送多达 80 封）。 ”

“妮可认为及时响应是她工作的一部分，她也自豪自己能做到这一点。她知道反应迟钝会阻碍她的团队，损害她的声誉或错过机会。她的目标是清空收件箱，但一周往往只能做到两三次。偶尔——大概一年一次——她会删除某个时间点之前处理不过来的邮件。她通常具有成长型思维，对新产品和新技术保持热情，但是在邮件处理这块，她可能还是旧的思维方式。每当使用新的邮件客户端时，她都会怀疑这是否能提高她的效率。”

基于高期望客户，我们整个公司可以比其他任何人都更聚焦于这个细分市场。有些人会争论说这个方法太局限了，创业早期不应该把目光弄的如此狭窄。

” 很多人认为将产品局限于一个小的细分市场，会很容易到达天花板——但我不这么认为。”

Paul Graham 解释了为什么：

"当开始创业时，一定有某些用户需要他们的产品——这不是指那些未来可能用到这些产品的人，而是那些现在就迫切需要的人。通常情况下，初期用户群很小。因为如果存在大量用户迫切需要的东西，而且可以通过一个创业公司来满足的话，通常这样的产品已经存在了。这意味着你只能两者选一：要么给大部分人提供有点想要的东西，要么给小部分人提供非常想要的东西。选择后者，不是所有这样的创意都是好的创业点子，但几乎所有好的创业点子都是这类的。"

在另一篇文章中，他对这个观点进行了更加深入的探讨：

“在理论上，这种类型的创业会给初创公司带来麻烦。它们可能会达到一个局部最优值。但实际上，这种情况从未发生。创意的极大值很少是孤立的，大部分很棒的想法都挨着更好的想法。“

从本质上讲，最好做给少部分用户提供「非常想要」的产品，而不是给大量用户提供「有点想要」的产品。在我看来，对一款为少量用户提供「非常想要」的功能的产品，精确定位细分市场很有帮助，可以减少很多不必要的工作。

2）通过分析用户反馈，将中立用户转化为狂热粉丝

然而，仅仅辨识出高期待客户是不够的。我们已经细化了目标用户，现在需要更加深入的挖掘他们的需求。因为我们目前的指标低于 40%，所以需要找出核心用户喜欢 Superhuman 的真正原因——以及如何将更多用户转化成核心用户。

为了深入了解我们将如何改进产品并扩大其吸引力，我发现将精力集中在以下关键问题上很有帮助：

为什么用户喜欢这个产品？

是什么阻碍了人们对产品的喜爱？

为了理解用户为什么喜欢 Superhuman，我们再一次将目光转向那些离开了我们产品会非常失望的人。这一次，我们关注他们对第三个问题的回答：你觉得我们产品最有用的地方是哪里？

下面是一些引人注目的答案：

“使用 Superhuman 可以更快地处理电子邮件。它一次只显示一封邮件，总体速度比 Gmail 快得多。我用一半的时间就能清空收件箱。”

“速度！这个应用程序速度快的惊人。搭配良好的用户体验和快捷键，我感觉自己像个真正的超人。”

“使用 Superhuman 比使用 Gmail 快得多，不是一点半点。而且它复用了 Gmail 的快捷方式，对用过 Gmail 的人来说上手毫不费力。”

“我可以更快地处理收到的邮件，对消息进行快速排序并简化我的工作流程。”

“速度。审美。我能通过键盘搞定所有事。”

“速度和出色的键盘快捷键。我几乎不需要触控板。”

通过把这些答案输入到词云，出现了一些共同的主题：热爱我们产品的用户最欣赏它的速度、专注以及键盘快捷键。

通过对产品吸引力的深入理解，我们把注意力转向了如何让更多的用户爱上 Superhuman。

我们接下来要做的可能有点反直觉：我们决定礼貌的忽略来自那些离开这个产品不会感到失望的用户的反馈。

这些用户不应该对你的产品战略有任何的影响。他们会提一些毫无意义的需求，提供病态的用户案例，同时可能非常活跃，再之后他们会毫不犹豫的抛弃产品，留下你一塌糊涂的产品规划。尽管这看起来令人惊讶或痛苦，但不要对他们的反馈作出行动——它将使你在追求 pmf 时误入歧途。

礼貌的无视那些离开你的产品不会感到失望的用户. 他们离爱上你的产品太远了，让他们改变基本上是不可能做到的。

这样就只剩下那些离开我们的产品会感到有点失望的用户了。在某一方面，“有点” 意味着机会。吸引的种子已经播下，也许通过一些调整，就可以让他们爱上你的产品。但另一方面，很可能无论你做什么，某些用户都不会爱上你的产品。

为了充分利用这些提供线索的用户，我们进行了进一步的细分。通过分析第三个问题，我们发现喜欢产品的用户认为最有用的地方是速度很快。我们利用这个特征进一步划分用户组。

我们将用户通过速度是否是他们的主要关注点划分为了两组，并通过他们的反馈采取行动：

对那些有点失望，但速度不是他们主要关注点的用户组：我们选择礼貌的无视他们，因为我们最主要的产品功能没有跟他们产生共鸣。就算我们开发了所有他们想要的一切，他们也不太可能爱上这个产品。

对那些有点失望，但速度是他们主要关注点的用户组：我们重点关注他们的反馈，因为他跟我们的主要功能产生了共鸣。某些功能——可能是一些小功能——就能让他们爱上我们。

聚焦在后一个用户组，我们开始更仔细的研究他们对第四个问题的回答：“怎样才能让我们的产品变得对你来说更有用？”

这是我们看到的：

通过一些分析，我们发现阻碍用户爱上产品的原因非常简单：缺少移动端应用。在 2015 年，我们采取了先从桌面端开始的策略。因为大部分邮件是从桌面端发送的，我们觉得在这里可以创造最大的价值。我们一直计划构建一个移动端应用，但是在我们创业早期——就像每个初创公司一样——我们的筹码只够下注一次。在 2017 年，移动端应用的紧迫性已经非常明显了，它成为了我们 pmf 的关键。

通过更深入的研究，我们发现了一些不太明显但是更有趣的需求：集成第三方、附件处理、日历、统一收件箱、更好的搜索、阅读回执以及其他一些长尾需求。例如，作为一个初创公司，我们内部并没有重度使用自研的日历，所以并没有像重视邮件一样重视日历。通过这次对用户反馈的深入挖掘，我们提高了日历在我们产品中的优先级。

对我们产品的主要优势和缺点有了清晰的认识后，接下来需要做的就是把这些认知应用到构建产品当中。通过满足那些中立用户的需求，尽量让他们转变为狂热用户。

3) 路线图应该致力于加倍关注用户喜爱的功能和解决妨碍用户爱上产品的问题

尽管我们理解用户为什么爱上我们以及是什么阻碍他们爱上我们，但一开始我们也很难清晰的认识到如何制定路线图以平衡这两点。

最终我认识到：如果你仅仅专注于增强用户喜欢的功能，你的 pmf 并不会提高。如果你仅仅专注于解决妨碍用户爱上你的问题，你的竞争对手很可能超过你。这个结论指导着我们的产品规划，帮助高效的制定了路线图。

为了让「非常失望」组的用户更喜欢我们，路线图的一半用于以下项目：

更快的速度：我们的产品已经很快了，但我们努力让它更快。例如，当前 UI 的响应时间在 100 ms 内，搜索速度比 Gmail 更快。但我们进一步将响应时间缩短到 50 ms 内，并即时呈现搜索结果。

更多的快捷键：用户喜欢通过快捷键搞定一切事情。因此我们把快捷键变得更健壮和全面。我们加了一些其他邮件客户端从没有过的快捷键，同时保证当用户输入超过电脑处理速度时，依旧能得到正确的处理结果。

更多自动化：用户真的非常在乎效率。但打字速度限制了效率的提高。因此我们开发了代码片段，允许用户自动输入短语、段落、甚至整个邮件。为了节省更多时间，我们进一步完善了代码片段，使其更加健壮，可以添加附件、自动添加抄送人，甚至可以和 CRM 与 ATS 集成。

更好的设计：在我们收集的反馈中，看到用户喜欢我们的设计以及一些小细节，因此我们投入了更多精力，做了很多细微的改动，以向用户表达我们对细节的关注。例如，输入 “-->" 将自动转成一个右箭头：→。

为了争取那些「喜欢我们产品的速度但是有点失望」的用户，我们的第二部分路线图主要关注如下：

开发移动版 App。

增加与现有产品的集成能力。

改进附件处理。

增加日历功能。

创建一个统一收件箱选项。

改进搜索。

增加已读回执功能。

为了给这些工作排序，我们进行了非常简单的成本收益分析：我们给每一个潜在的功能点打上低/中/高的成本标签，以及类似的低/中/高的收益标签。对于路线图中第二部分用于争取「有点失望」的用户的功能，收益很容易计算，只需要统计问卷中对该功能的改进建议数量。对于第一部分，让「非常失望」的用户更喜欢我们的产品，我们只能通过直觉判断收益水平。这是「产品本能」发挥作用的地方，而这种能力基于经验和与客户共情的能力（早期刻画高期待客户的用户画像，对训练产品本能非常有帮助）。

有了上述计划，我们就从「低成本、高收益」的功能点开始尽快发布改进。

为了增加你的 pmf 分数，花一半的时间继续投入用户已经喜欢的功能，另一半时间解决阻碍用户喜欢上你的产品的问题。

4) 重复上述过程，将 pmf 分数作为最重要的指标

我们持续对新用户进行调查问卷，以跟踪 pmf 分数是如何变化的（我们谨慎的确保不会对用户进行重复调查以避免不小心超过 40%）。

回答「非常失望」的用户百分比迅速成为我们最关心的数字。作为最明显的指标，我们分别以每周、每月、每季度的频率跟踪它。为了让这个过程简单点，我们开发了一些定制化工具持续对新用户进行问卷调查，并以不同的时间窗口聚合结果。我们也调整了产品团队的目标，以「非常失望」的用户百分比作为唯一的关键结果设置 OKR，以确保我们持续增加 pmf 分数。

重新调整了产品方向后很快有了成效。在 2017 年夏天刚开始的时候，我们的 pmf 分数为 22%。通过细分仅关注「非常失望」的用户组后，分数为 33%。通过三个季度的努力，分数几乎翻倍达到了 58%。

事情并没有到此结束，我们将一直保持对 pmf 分数的追踪。我认为对于初创公司来说关注该指标是非常有用的，因为随着用户增长，你将会遇到各种各样的用户。早期用户是非常宽容的，尽管产品有着这样那样的问题，他们依旧能享受它带来的好处。但随着你的用户增长，他们的要求会越来越高，渴求其他竞品已有的功能。此时，你的 pmf 分数可能会大大下降。

然而，这没什么好焦虑的，因为总有办法解决。如果你的产品有很强的网络效应（想想 Uber 或者 Airbnb），那么产品价值将随着用户增长同步增长。如果你是一个像 Superhuman 一样的 SaaS 公司，随着用户的增长，你只需要持续改进产品。为了做到这一点，我们每个季度都会用本文提出的这套方法重定我们的路线图，确保足够快的改进 pmf 分数。

即将迫降，小心冲击

随着这个过程的不断演进，我发现了如何定义 pmf 以及衡量它的办法。我们团队通过一个具体指标凝聚在一起，而不是一个令人绝望的抽象目标。通过调查用户，细分市场，了解用户喜欢什么和讨厌什么，然后制定路线图平衡这两点，我们找到了提升 pmf 的方法论。

很难高估 pmf 驱动引擎在我们公司的影响。我们在 Superhuman 所做的一切——从招聘销售、营销人员到融资——都变得轻而易举。团队扩张到了 22 人，NPS（净推荐值）也随着 pmf 不断增长。无论是调查问卷中，还是社交媒体上，用户对产品的喜爱明显提高了。当前的投资者开始问我能不能在下一轮融资前追加更多资金，而外部投资者不断问我他们是否能够投资。

再一次回顾从为 Superhuman 构建 pmf 引擎中所学到的东西，我得到了两个结论：

早期投资者应该建议初创团队在达到 pmf 之前避免推动增长。在这个行业中，我们都知道这最终会导致灾难，但过早增长的压力仍然很普遍。初创公司需要时间和空间来找到适合的方式并正确启动。

对于任何想要走出荒野，踏上追寻难以捉摸的 pmf 之路的创始人来说，我已经体验过这一切 —— 我希望你能在那些众所周知的创业车库中重组我的引擎，让它属于你。当你最终达到你所追求的 pmf 分数时，我建议你一脚踩下踏板，尽可能的高速增长。尽管这会令你感到不适，但你会获得你需要的证据证明你将成功。

后记

这是我第一次翻译英文文章，全文译好八千余字，花了不少心思，也算真切体会到了翻译之难，古人常说译文需信达雅，做到信已殊为不易。为了防止误译，经过几番校对才敢发布。但因为经验原因，肯定还有不足的地方，希望大家能指出，以便改进。

当时接下翻译，一方面是为了觉得这篇文章非常不错，希望更多人看到，另一方面也是觉得自己译过一遍，能加深对内容的理解，而不是草草读过。希望大家也能有所收获。

原文地址：https://firstround.com/review/how-superhuman-built-an-engine-to-find-product-market-fit/