Heptabase from 0 to 1

By Hohshen

概念

一個相同的知識,會在很多主題中被重複使用
想做的就是一個系統, 將每個主題與知識點關聯
這個系統由卡片(知識點)與白板(主題)構成
把很多卡片放到白板上,make sense的去連線,
整理成一個好理解的主題
並且重複利用許多知識點

強調「學習如何思考」大過「學習知識」人類的知識工作有固定的生命週期：
探索 → 收集 → 思考 → 創作 → 分享。

模擬人類大腦在思考和學習的方式

Minerva 的教育

Google 「探索」

「收集」到Roam Research

Miro 來建立「思考」

Notion 來「創作」

「分享」到 Medium 讓其他人「探索」

Google 「探索」

「收集」到Roam Research

Miro 來建立「思考」

Notion 來「創作」

「分享」到 Medium 讓其他人「探索」

軟體結合

Google 「探索」

Heptabase

「分享」到 Medium 讓其他人「探索」

軟體結合

第一週: 打造 MVP

三個功能：建立白板、建立文字卡片、把文字卡片

一個禮拜的純前端

What is “Minimal”?

no account

no backend server & database

no billing system

no multi-media support
pure f2e

初期的 web Large JSON file 存在 IndexedDB
前端 APP host 在 Netlify 上
markdown 可在白板間被重用

optimize for feedback

建立可運作的雛形快速得到回饋

Proof of Concept:

optimize for feedback

六個月裡頭
發佈了兩百多次更新（平均每天至少更新一次）、
兩千多個 git commit，

每次發佈時我們心中都有希望能測試的假設。

Code 一開始寫得醜沒關係，未來再重構就好了。
用戶會不會用，比 code 乾不乾淨重要一百倍，
如果一個功能用戶就是不會用，code 寫得再好也是浪費時間。

Day 1 留存率也從 20% 一路成長到 60%。

1. 省去大量的溝通成本，在最短的時間內把自己想象中的東西做出來，等到開始覺得有些力不從心後，再逐漸將責任交接給更厲害的設計師和工程師夥伴。
2. 可以確保自己暸解第一線的細節，這對提高決策的品質有很大的幫助。
3. 可以在團隊中樹立典範，CEO 的做事方式對團隊的做事文化有非常大的影響。

CEO 先執行第一步的好處

Staging 2: Rapid Iteration

optimize for shipping speed

快速迭代讓使用者越快使用到產品

Principles

1. No data loss for our users.
2. Ship usable feature as fast as possible to the user.

- 把大功能切成小功能解決使用者最重的痛點

- 開發feature步驟分為：Goal、Release、Checkpoint

3. Always put the customers first.

- 討論上如果有分歧的時候，先討論使用者需要的是什麼

- 不知道使用者在想甚麼就辦投票(discord投票)

每次更新後都會討論下一版要怎麼更新才會有最大的 Impact，
討論完後就直接上工，沒有廢話。（且戰且走）

Optimize for Speed

1. Not always using best practices

- Duplicated code for flexibility 不要過度抽象化，保持開發彈性- - Ship first, refactor later 先有功能，refactor 之後再處理

因為產品算是疊的還蠻快的,所以很多時候上禮拜這份Code不一樣,下禮拜就拿不一樣,
今天把它寫得很漂亮,下禮拜改到什麼程度

Optimize for Speed

stack pr : Superlog
- stack pr，一個大功能分成多個模組。A 先上 PR，B 在 A 基礎上繼續開發
- 減少 reviewer 一次要看很多行 code，也不會阻擋開發者的開發進程
- 很考驗開發者對 feature 的理解跟規劃
code review: Graphite - How the fastest developers ship code

Staging 3: Production

optimize for users love

把比較粗糙的作法優化

1. Better retention

2. Clearer technical solution

3. Faster iteration speed

When to improve

從開發者角度做取捨來保證開發進度

- Engineers do customer support.
工程師可以快速接收到使用者回報的問題，
進而討論是否需要花時間解決

- User complaint
Cost of problem solving + technical implication.

User complaint:
Cost of problem solving + technical implication.

e.g. Storage 一開始是用 indexdb

可能會被瀏覽器自動清掉,還有考慮到後面要做成 mobile app，
後來 migrate 到 SQLite

e.g. Search 一開始是把 data 丟到記憶體 search，

想分詞、highlight，但都要等比較久，
後面用sqlite fulltext module

e.g. Mobile App

一開始問使用者最想要什麼功能，
收到回饋是想要有一個 mobile app 可以看到卡片

Heptabase 1.0

1. capacitor後來轉換到react navite 十天生出第一版
2. 前後端都選用 javascript進行開發減少溝通gap

data-driven

用 Amplitude 或 Mixpanel 等工具去追蹤重要的數據，盡可能地 data-driven。

Day 1 留存率還沒拉起來時，先別管 Day 7 留存率。同樣地，Day 7 留存率還沒拉起來時，先別管 Day 30 的留存率。不同階段的留存率提升的方式也不同。

Angel investor

1. Problem & Product:
我們的產品在解決什麼問題、
什麼樣的人需要我們的產品。

2. Users & Traction:
目前的數據（留存率、用戶數）以及成長策略、
如何 Onboard 用戶、關鍵的 Insight 是什麼。

3. Team:
團隊怎麼認識的、誰負責做什麼事情。

4. Vision & Market:
公司的長期願景、如何成為 Billion-dollar company。

YC 的標語是「打造人們需要的產品」
（make something people want）

收費

你應該在 Day 1 就開始思考收費。
因為唯有收費了，你才能真正搞清楚
誰願意付費、誰不願意付費，
區分出你的核心用戶

Eat your dog food

Title Text

Subtitle

我們每天都泡在 Discord 社群裡和用戶對話，努力迭代產品、盡快地上線下一版。
錄取 YC 這些原本感覺相當困難的事情，也變成了一個相對自然的結果。

你應該明天就發布產品

~~「MVP 要有哪些功能才能 launch，做出這些功能要花多少時間？」~~

「我們明天要 launch，今天最多可以做到什麼程度的 MVP？」

MVP 推出去功能太少、太爛、沒有人用，這些一點都不是問題。
MVP 從來都不該一次到位，
而是要能高速迭代、變得愈來愈好。
每一次更新 MVP 都是一次學習、一次揮棒。

Heptabase from 0 to 1

目錄

Introduction Heptabase

Staging 1: proof of concept

optimize for feedback

概念

第一週: 打造 MVP