🔧 阿川の電商水電行
我已經推出過幾款產品，也犯過不少錯誤，所以我很清楚哪些事情真正重要，哪些只是偽裝成準備工作的拖延症。以下是我每次產品發布前都會檢查的清單。
-
在擁有使用者之前設定分析功能
我知道在使用者數量為零的時候，設定分析資料似乎毫無意義，但幾個月後，你會後悔當初沒有從一開始就收集資料。設定分析功能大概只需要30分鐘，但它能讓你真正了解使用者在你的應用程式裡做了什麼，而不是你臆想的。
我用的是 PostHog。它對大多數早期產品都是免費的，你可以用它來追蹤事件、查看會話錄像，以及執行基本的銷售漏斗。 Mixpanel 和 Amplitude 也都可以。至少你需要追蹤註冊用戶、關鍵啟動事件以及付費方案的升級情況。以後可以加入更多功能，但發布前一定要把這些基本功能都搞定。
-
設立回饋板
我之前的專案中都忽略了這一點，每次都後悔不已。回饋板可以讓使用者提交功能請求、報告錯誤，並互相點讚彼此的想法，這樣你就能了解他們真正重視的是什麼。
如果沒有回饋看板，你會收到大量分散在電子郵件、Twitter 私訊、客服聊天和 Slack 訊息中的功能請求。你會迷失方向，最終開發出你記得的功能，而不是真正重要的功能。有了回饋看板，最熱門的需求就會置頂，你可以清楚地看到有多少人想要某個功能。發布功能時，你可以通知所有提出過請求的用戶，這對於提高用戶留存率至關重要。
我認為這一步至關重要，所以我專門為此開發了一個名為UserJot 的工具。如果你想自行託管，也可以選擇像 Fider 這樣的開源方案。無論你選擇哪種方案，都要確保它能從你的應用程式內部存取。提交回饋越便捷，你收到的回饋就越多；而早期獲得更多回饋意味著後期可以減少錯誤決策。
-
設定錯誤監控
你的應用程式可能會出現故障，你想在用戶告訴你之前，或者更糟的是，在他們直接離開並且永遠不會回來之前，就了解錯誤情況。
Sentry 和 Axiom 都是不錯的選擇。它們可以捕獲異常，顯示堆疊跟踪，並告知受影響的用戶數量。目前，免費套餐足以滿足大多數產品的需求。建議同時為前端和後端配置，這樣當出現問題時，您就能了解使用者當時正在存取哪個頁面、嘗試執行什麼操作以及使用的瀏覽器等資訊。配置過程可能只需 20 分鐘，卻能為您節省後續數小時的除錯時間。
-
設定交易電子郵件
你需要發送歡迎郵件、密碼重設郵件、收據郵件和通知郵件。不要嘗試從你自己的伺服器發送，否則郵件會被誤判為垃圾郵件，而且你會浪費數天時間來排查送達率問題。
我使用 SES 是因為它的 API 簡潔且功能強大。 Postmark 也是不錯的選擇。至少你需要一封歡迎郵件來註冊、密碼重置，以及如果你提供收費服務，你還需要發送購買收據。之後你可以加入更複雜的郵件序列，但對於產品上線來說，先把基本功能搞定就行了。
-
確保你的登陸頁面設計正確
我不是說要花三個星期，但肯定不只花一個下午的時間。你的著陸頁只有一個目的，那就是說服別人嘗試你的產品，頁面上的所有內容都應該圍繞著這個目的。
你需要一個簡潔明了的標題，用一句話概括產品功能；一張展示產品實際效果的截圖或演示；一些用戶評價，哪怕只是一個測試用戶的證言；以及一個清晰的行動號召按鈕。至於花俏的動畫、精美的插圖和十個不同的價格檔位，都可以先放一放。
我使用 Astro 來建立靜態落地頁。它非常簡單易用，功能強大，而且可以輕鬆部署到任何地方。一個簡單的測試方法是，把你的落地頁展示給一個完全不了解你正在開發的產品的人，看看他們能否在 10 秒內解釋清楚它的功能。如果他們不能，那就需要簡化頁面內容。
-
測試關鍵路徑
在正式發布之前，請務必像真實用戶一樣使用你的產品。用新郵箱而不是測試帳號完成註冊流程，測試產品的主要功能，如果有付款功能，也測試一下支付流程，測試密碼重設功能，然後退出登入再重新登入。
我數不清有多少次發布產品後，註冊流程在某些特殊情況下出現問題。如果可以的話，最好找兩三個人一起測試，因為新鮮的視角能發現你忽略的問題。
-
準備好你的發布管道
在產品發布前就確定好發布管道，而不是在發布當天。對於大多數開發者工具和產品來說，常見的發布管道包括 Twitter、Hacker News（如果產品足夠技術性的話）、Product Hunt、相關的 Reddit 子版塊、Indie Hackers，以及你的郵件列表（如果你有的話）。
你不需要面面俱到。選擇兩到三條適合你受眾的內容，事先寫好發文。你肯定不想在發布當天一邊修復漏洞一邊寫推文吧。
-
具備與使用者溝通的管道
上線當天，用戶會提出問題、發現漏洞並提供回饋。你需要一種快速回應的方式。電子郵件、Intercom 或 Crisp 等聊天工具都可行，如果你想建立社區，Discord 伺服器也是一個不錯的選擇。
我通常會先透過郵件和回饋看板進行溝通。關鍵是要快速回复，尤其是在初期階段。如果創辦人能在5分鐘內回复，人們會記住，這有助於建立很難用其他方式獲得的忠誠度。
-
未臻完美就出貨
你的應用程式還沒準備好，也永遠不會準備好。總是會有更多功能需要加入，更多漏洞需要修復，更多設計上的調整可以讓它更好。但無論如何，先發佈吧。
第一周從真實用戶那裡獲得的回饋，比你在第三個月開發的功能更有價值。如果你的核心功能運作良好，使用者能夠註冊，那麼你就已經做好了充分的準備。
清單
[ ] 分析追蹤關鍵事件
[ ] 可透過應用程式存取的回饋板
[ ] 前端與後端錯誤監控
[ ] 事務性電子郵件正常運作
[ ] 著陸頁清楚地解釋了你的業務內容。
[ ] 使用新帳戶測試關鍵路徑
[ ] 為 2-3 個頻道撰寫的發布文章
[ ] 回應使用者準備就緒的方式
就是這樣。產品發布本身遠不如你想像的那麼重要。真正重要的是發布後的幾週內你所做的工作，例如與用戶溝通、修復問題、打造他們真正需要的功能。這份清單只是為了確保在收到回饋時，你不會從零開始。
原文出處：https://dev.to/shayy/my-checklist-before-launching-any-app-2a8h
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
