【PM總動員】從零到一的產品開發思維：那些 Engaged.AI 做對與做錯的事情
【PM總動員】是產品三眼怪的每月定期客座單元，挖掘邀請海內外業界產品開發相關領域的大大們和大家分享！本月邀請到的是台灣新創 Engaged.AI 的產品經理 Steff 來跟大家分享從0到1的新產品開發第一手經驗，她如何在PM的角色與團隊共同經歷了新創產品開的不同階段，內含十分扎實的實務案例與思維！前言
在投身產品經理時，就職企業選擇上，有些人會選擇應徵大企業，也有人會優先考量加入新創團隊。根據 3PM Lab 在 2019 年底做的問卷調查顯示，在他們近 130 位的樣本數中有 28％ 的產品經理目前就職於新創團隊。
在加入新創團隊前，大多會從新創目前的商業模式、團隊規模、募資狀態、收益概況等量化數據評估，但是對於這些外部條件會如何影響該團隊產品經理的職能，相對上是很難用量化指標判斷的。
今天用我自己從零到一建立 Engaged.AI 的經驗讓大家分享，在不同產品生命週期，產品經理的職能會有什麼變化，還有我自己在不同階段的學習。希望可以讓想投入新創做產品經理的你可以建立比較明確的職能期待，也能用不同的角度判斷這間新創是否適合自己。
Engaged.AI 是什麼？
我所負責的產品 Engaged.AI 是一個 Instagram 數據分析工具，幫助行銷人員解讀數據，建立以數據佐證的決策，加速品牌在 Instagram 上達成目標。
我們在 2018 年年底發想出 Engaged.AI 最基本的產品構想，並在 2019 年 3 月的時候正式發佈產品。從產品發佈至今不到一年的時間，我們累積了超過一萬個使用者，服務著大家熟悉的品牌如 Lexus、La Mer、KKBOX 等等。
Ash Maurya 在他的著作 Running Lean 中提到，在新創公司中，產品的生命週期大致上分成三個階段：
- Problem/Solution Fit
- Product/Market Fit
- Scale
而 Engaged.AI 目前則是達到了 Product/Market Fit，並且在 Scale 的路上努力。接下來我會用這個結構與大家分享在這一年多的過程中，Engaged.AI 在不同的階段分別做對了什麼事情、做錯了哪些事，又是如何彌補錯誤的。
第一階段：Problem/Solution Fit
大家耳熟能詳的創業傳說通常開頭都是這樣：「我們發現了一個還沒有被解決的問題，於是我們決定為此建置一個產品。」
Engaged.AI 開始的故事與這個差不多，我們的確發現了一個還沒有被解決的問題，但我們並沒有立即決定要開發一個產品，而是花了很多時間找尋 Problem/Solution Fit。
產品目標
在 Problem/Solution Fit 階段，新創需要回答的關鍵問題是：
我是否有個「值得被解決」的問題（Do I have a problem worth solving?）
根據富比士報導，造成新創死亡最主要的原因是：沒有解決一個真正存在的問題（real-world problem）。因此，在投入開發資源前，通常會先判斷這個問題是否「值得被解決」。
如果一個問題「值得被解決」，那它會滿足以下三個條件：
- Desirable — 這是不是一個用戶想要的東西？
- Feasible — 它是否可以被解決？
- Viable — 用戶是否會為了你的解決方案付費？
那在這個階段，身為產品經理的我做了什麼？
產品經理職能
在這個階段，新創整體的團隊通常比較小，像是現在估值 $310 億美金，並且預計今年 IPO 的 Airbnb 在草創階段時也只有三個人。
在 Engaged.AI 還只有最初始的產品想法時，團隊內也只有一個全端工程師搭配一個可以做除了開發之外所有事情的人，也就是我。
在還沒跟開始做 Engaged.AI 之前，我們團隊主要的業務是做客製化Facebook Messenger Chatbot，像是安溥的小蛤蜊、GQ 的 Barsurfing 等等。我們在為顧客做客製化服務時，常常聽到大家跟我們說關於經營 Instagram 的種種困難。對於想要從客製化服務轉型到 SaaS 的我們來說，這是一個很好的機會。於是我們就投入了兩個人，去研究在 Instagram 場域中，我們的立足點存在於哪裡。
我在這時候的階段性目標就如同前面提到的：確定想要解決的問題值得被解決。也因此我的職能主要是：
- 用戶訪談 — 與潛在用戶進行訪談，去了解團隊想要解決的問題是否滿足以上提到的三個條件。
- 釐清商業模型 — 根據訪談用戶獲得的質化資料，設計解決方案，並規劃產品的商業模型
- 原型製作與假設驗證 —在完成解決方案的設計與商業模型的規劃後，會製作最低可行產品（Minimum Viable Product），並進行更深入的用戶研究與假設驗證。
在這個階段，我與團隊學到的事情是：
Learning #1: 用戶沒有責任對你說實話
用戶其實沒有責任對你句句屬實，挖掘問題背後的真相才是你的責任。
延續前面提到的，我們在做 Engaged.AI 產品初期研究時，花了很多時間訪談用戶，期待取得質化數據，協助團隊做後續的判斷與分析。在進行研究的時候，我其實因為訪談問題的錯誤，獲得很多無效的質化數據，也浪費了很多時間。
什麼是錯誤的訪談問題呢？
想像有個人拿著一個可以切換 50 種顏色的原子筆在你面前，用著充滿期待的表情問：「你覺得你需要這個新的產品嗎？」你其實很難跟他說：「我不太在乎我的筆是不是可以同時有 50 種顏色。」甚至有可能回答：「我覺得這個真的很棒！它解決了我好多的問題！」
這就是一種錯誤的問題形式。這個詢問的情境，以及詢問的方式很容易影響用戶提供的答案，也因為答案本身的偏誤，最後讓整個研究的結果無效。我自己在解決這個問題的時候，參考了 Rob Fitzpatrick 提出的 The Mom Test。他提出了幾個簡單的原則幫助你在不確定性很高的產品發展前期，設計出不容易被用戶誤導，並且可以獲得用戶真實回饋的訪綱。
以下從幾個我問過的爛問題，剖析爛問題有什麼樣的特徵，又該怎麼把爛問題變好。
問題一：「如果這個產品可以幫你把你的貼文數據自動統整成一份報表的話，你覺得怎麼樣？」
在做產品研究時，我們都會想要知道預想的解決方案對於用戶來說是否有幫助。但當我們在一個還沒有產品原型的狀態詢問用戶這個問題，也只是獲得用戶假設性的想法。而這些假設性的想法，對於決定是否該投入成本開發產品一點幫助都沒有。也因此，在設計訪談問題時，要盡量避免假設性的問題（hypothetical questions）。
那要怎麼把這個壞問題變好呢？我後來將問題直接改為詢問用戶目前的解決方案：「你們目前是怎麼把貼文數據統整成一份報表的？」當他們回答：「我們都是從 Instagram App 上手動把成效數據抄到 Excel 表單上。」我就有機會繼續詢問這個行為發生的頻率、發生的方式、發生時會遇到的問題等，協助我後續進行原型設計時，需要被優先考量的議題。這個時候，用戶也有機會跟我說：「其實我們不太需要做這件事情。」那我也能進而知道，我在想的用戶問題根本不值得被解決。
問題二：「你覺得你會為了這個功能支付多少錢？」
定價對於判斷問題的商業價值是重要的，但是當你用一個開放式問題詢問時，用戶也會給你一個模糊不清的開放答案。然後我們在事後統計定價時，也因為各個答案相差太大，沒有得到一個顯著的結果。
在探索與「數字」相關的洞見時，要避免用開放性的方式詢問，要盡量改用實驗，或者是詢問跟這個數字相關的錨點（anchor point）才有機會貼近真實的答案。
也因此，我們後來改為直接詢問用戶為目前解決方案支付的費用。例如，有個用戶說他們其實有免費使用一個產品幫助他們解決部分的數據分析問題。這時候，除了得到一個可以後續研究的競品之外，我還有機會知道為什麼對於用戶來說，目前這個問題沒有考慮付費。如果用戶目前沒有為解決方案付費，也可以改詢問在時間上的既有成本，作為另一個可參考的數據。
Engaged.AI 在產品正式發布之前，也透過「用途理論」與「Price Sensitivity Meter」兩者的結合，再進行一次 Pricing 的研究，最後得到了我們現在的產品定價。問題三：「你大概多久會做一次社群成效報告？」
這是一個看似還不錯，但是很容易得到錯誤資訊的問題。使用頻率是一個我們常常拿來判斷商業價值的方式之一，但當我們用這個詢問的方式問用戶時，用戶為了要在陌生人面前看起來好看，會吹牛實際發生的頻率。就像是有個不太熟的人問你：「你一週運動多少次？」儘管你已經一個月沒去健身房，你為了要在對方面前展現一個好的形象，可能會回答：「大概 2–3 次吧。」
我後來都改用：「可以跟我分享上一次做社群成效報告的體驗嗎？」這樣的方式去做問題的 follow up。在這個情況下，你將有一個明確的事件發生的時間，去做更準確的使用頻率判斷，例如：「我上一次做社群報告是上上禮拜一。」同時，你也有機會更進一步了解，在需求發生的過程中，有什麼細節是未來在做原型設計時要注意的。
Learning #2: Business Model Should Be A Living Document
產品的商業模型規劃並不會有完成的一天，因為它會隨著市場變動、用戶變化、產品演進或企業目標的改變，而有所調整。
Engaged.AI 在這個階段使用了 Lean Canvas 幫助我們規劃商業模型。透過 Lean Canvas，我們完整地規劃了產品最一開始的商業模型，也根據這個 Canvas 做了後續的商業決策。
當我們利用 Lean Canvas 完成決策後，就把它放在旁邊，再也沒有拿出來過。但在事過境遷，我才發現 Lean Canvas 應該是一個產品經理需要定期更新、維護、重新檢視的文件。
以 Engaged.AI 的 Revenue Model 為例，從產品正式發佈到現在，我們總共經歷了至少四次的 Revenue Model 變動。每一次 Revenue Model 的變更其實都是根據市場變動、用戶變化、產品演進或企業目標改變，而做的調整。
Engaged.AI 在一開始是使用 Freemium Model 的。我們希望可以透過免費的產品方案作為我們的用戶獲取策略（User Acquisition Strategy），也就是在產品有免費方案時，用戶因為沒有成本，比較願意嘗試使用產品。但當我們正式將產品發布出去時，在不同面向都看到了一些徵兆：
- 點擊付費功能的人很多，但到了頁面之後卻沒有再做下一步的轉換
- 很多人問我們是不是可以 Demo 產品，並且 Demo 之後，大都會直接購買產品
- 訪談轉換時間（從在產品上建立帳號到進行購買所花費的時間）很長的用戶發現，他們大多是行銷團隊的執行者，且花費很多時間在說服主管這個工具可以協助團隊執行更好的行銷策略
- 研究轉換時間很短的用戶後發現，他們大多是行銷團隊的主管，可以立即了解產品對於團隊的價值，也有實行購買的決策權
這些讓我們決定變更 Revenue Model 的徵兆其實都是 Lean Canvas 上的一部分。譬如說第三點與第四點其實就是在 Customer Segments 內應該要考慮企業內不同權力層級的用戶（主管或執行者）。
同時，當我們調整 Revenue Model 時，也會影響到在 Lean Canvas 上的其他項目，造成相對應的變更。就像是 Engaged.AI 現行的 Revenue Model 是一個 Hybrid 的方式，同時執行了 Freemium 與 Free Trial，那這個 Revenue Model 的變化也會影響到在 Cost Structure 中的 Customer Acquisition Cost，像是考慮中間業務結單花費的人力成本，或者是將 Free Trial 的成本考慮進去。
作為一個產品經理，熟悉產品本身的商業模型，以及了解在產品上的每個變更會如何影響到商業模型是必要的。對於不太熟悉要怎麼做產品或市場商業分析的產品經理，Lean Canvas 也是一個建立分析框架並培養分析習慣的開始。我自己就會至少每一個月都在 Calendar 上 Block 一個時間出來更新 Engaged.AI Lean Canvas，幫助我了解我還需要做哪些面向的商業研究。
想要多瞭解在 SaaS 中，Freemium 和 Free Trial 有什麼差別，又該如何根據產品與市場本身的特性判斷要選擇哪種 Revenue Model，可以參考這篇：Free trial or freemium? Decide your go-to-market strategy first.Learning #3: 不要害怕投入開發成本，但要極大化 ROI
在開發新產品的過程中，很難拿捏「我是不是還要繼續做研究？」還是「我目前得到的洞見是不是足以投入開發成本？」
Engaged.AI 在產品初期時，其實只訪問了大概十位左右的潛在用戶，便投入成本進行 MVP 的開發。聽起來好像很冒險，但其實是在考量了以下兩個要素之後做的決定：
- 對於需求是否「值得被解決」已經相對清楚，但我們不確定預想的解決方案是否可以解決問題
- 在沒有有形的解決方案時，用戶只能提供給我們假設性的答案，而這並不是我們想要的
只要確定你投入的開發成本，可以為你帶來目前無法得到的學習與洞見，就是一個強而有力的 Signal。
我們在正式產品發布前總共做了兩次 MVP 的測試：
- 與 15 位潛在用戶（10 位舊的+5 位新的）討論第一個版本的 MVP
- 在社群行銷工作者聚集的 Facebook Group — 社群丼內進行Product Soft Launch，邀請了一百位左右的用戶為我們測試 MVP
這兩次 MVP 測試的方式稍有不同。我們在第一階段比較小規模的測試是密切與用戶進行 MVP 的討論，並且實地觀察他們使用的情形。在這個階段，我們主要修正的項目也是調整產品的設計方式。
在第二個階段，測試用戶的規模比較龐大，我們的測試方式就是透過 LogRocket 這個服務，一方面幫我們做產品 QA，另一方面為我們進行易用性的測試。同時我們也用了問卷進行了需要一定規模才能進行的用戶研究，如先前提到的 Pricing 研究。
這樣冒險的舉動，其實也為我們帶來一個意想不到的收穫 — 第一批產品用戶的積累。對於一個新的產品來說，找到第一批用戶往往是最困難的事情，但因為 Engaged.AI 有這兩次的 MVP 測試，我們在正式推出產品的第一週就有超過 300 位使用者。
第二階段：Product/Market Fit
產品目標
當新創已經確定問題「值得被解決」，並且完成最低可行產品（Minimum Viable Product）時，下一個階段就是為產品發布做準備，確保產品有完整的基礎建設足以讓你向用戶學習。發佈後則是透過不斷的向用戶學習、設定優先級、將學習變成可執行的步驟，並迭代產品。
這個過程通常被稱為找尋 Product/Market Fit。 在這個階段，新創需要回答的關鍵問題是：
我是否建置了一個人們想要的東西（Have I built something people want?）
但是要怎麼衡量有沒有達到 Product/Market Fit 呢？我們都會用 AARRR 模型中的 Retention 來判斷你所建置的產品是不是一個用戶想要的東西，並且讓他們願意持續的使用。當 Retention 高時，隨著 Pricing Model 的設計，也會為新創帶來基本的收益。
產品經理職能
在這個過程中，產品經理的職能只有一個 — —持續向用戶學習，並根據學習迭代產品，達到 Product/Market Fit。
那在這個大的職能下，其實分成幾個小的項目：
- 如何讓你有用戶可以學習？ — 建立 Acquisition 與 Activation Channel
- 如何向用戶學習？ — 建立質化與量化的 Feedback/Learning Channel
- 根據學習，該建立什麼樣的行動？ — 產品假設與實驗設計
- 在眾多可以執行的實驗中，要先做哪些？ — 產品優先級判定
- 如何讓實驗在產品上發生，推動下一次的學習？ — 產品迭代與假設驗證
當 Engaged.AI 在這個階段的時候，也犯了很多不同的錯誤，也對「產品經理應該要做什麼事情」有很多不同的迷思，以下分享我在這個階段中學習到的事情。
Learning #4: Product and Marketing are one and the same
「桃李不言，下自成蹊」是我過去對於產品的看法。我以為只要挖掘用戶的需求，在產品上提供有價值的解決方案，用戶就會自然找上門使用你的產品。也因此在那個時期，我們的迭代流程就是：根據用戶需求找到可以優化的方向，清楚描述用戶故事（User Story），然後配合產品設計與開發將功能發佈在產品上。
然而我們卻碰過很多次，明明就確定過這個功能優化能夠更好地幫用戶解決問題，也在研究階段得到正向的質化數據，實踐在產品上後卻與預想的結果差距甚遠。反覆發生這樣的錯誤之後才發現，我們總是只設計並開發了功能，卻沒有為用戶設計「讓他們知道這個功能」或者是「更好地理解功能價值」的體驗。
就像 Paul Adams（Vice President of Product, Intercom）所說：
Product and Marketing are one and the same. If you built a great product that no-one heard about, did you build a great product?
那在 Product 如何與 Marketing 結合呢？我們團隊在執行上會分成兩個層面：
- 如何透過不同的 Channel 讓用戶開始體驗產品價值的旅程
- 如何在旅程中，透過體驗的設計確保用戶可以體悟到 Aha-Moment
層面一：如何透過不同的 Channel 讓用戶開始體驗產品價值的旅程？
在 Engaged.AI，我們參考了 Intercom 在 Product Launch Prioritization 上的框架，並做了一些修正。
首先我們可以把各種功能根據「價值對象」與「創新程度」分成三種類型：
- P1：這種功能以更好且創新的方式為用戶解決問題，也是吸引新用戶最佳的機會。
- P2：這些是對既有用戶很有價值的新創新功能，或者是競爭對手已經有的功能，對吸引新的用戶僅有小部分的幫助。
- P3：這些功能主要是為了優化產品，或者是弭平產品與競爭者相比之下的不足。雖然對既有用戶很有價值，但沒有這些功能並不影響用戶的產品購買意願。
那根據我們自己的 Marketing Touch-points，我們會為不同類型的功能設定不同的 Launch Plan。
層面二：如何在旅程中，用體驗設計確保用戶可以體悟到他們的 Aha-Moment？
在確定這個功能會有哪些 Initial Touch-points 之後，我們會為不同的 Touch-points 和不同的用戶類型做 Experience Journey Mapping，幫助我們規劃在不同的階段，產品可以設計什麼樣的體驗，確保用戶可以在使用的過程中理解到功能的價值。
這個部分也常被稱為 On-boarding，大家可以參考 3PM Lab 之前的文章--「用戶增長的關鍵：如何設計一個良好的 Onboarding Experience?」了解更多。
另外，我自己在設計 End-to-End Experience 的時候，很喜歡使用 Glide-Nudge-Challenge Model，給大家參考。從 End-to-End Experience 的角度出發規劃並設計產品對我來說並不是一件很直覺的事情，所以除了透過明確的 Framework 幫助我之外，我也會在規劃 Epic 時用 Notion Template 強迫我自己去以 End-to-End Experience 的方式規劃。
Learning #5: Make sure that you are ready to learn from the users
我們都聽過被奉為圭臬的產品管理原則：「從用戶行為的質化與量化數據中找到產品下一個可以優化的方向」。但實際上要怎麼從這個 High Level 的原則落地到產品上並沒有一個明確的方式，Engaged.AI 也磕磕絆絆的花了很長的一段時間才把這個部分的產品基礎建立起來，使得我們能夠確保在每個環節都有流暢的 Feedback Channel 為我們收集用戶數據。
我們首先透過 User Journey Mapping 統整了用戶在 Engaged.AI 上的旅程。
接下來便是使用大家熟悉的 Goal-Signal-Measure 框架為我們追蹤用戶是否在各個階段都有達成我們想要引導他們完成的目標。除此之外，為了獲得質化的數據，我們與客服（Customer Success）合作，確保我們可以在用戶遇到問題時，能夠有條理的將客戶遇到的困難回應給我們，並了解問題背後隱藏的產品缺陷，作為下一次產品迭代的優化項目。
另外，與客服合作也是我們做日常 User Research 的方式。因為團隊規模與資源的限制，我們沒有辦法像大公司一樣有 User Research 團隊專責產品的用戶研究，所以產品便是和客服建立密切的溝通，了解當週產品最常遇到的客服問題是哪個類型，如果需要更進一步了解該需求，也可以透過即時的客服對話跟用戶預約 10–20 分鐘的簡單訪談。
不過這些情況都是在當你對於用戶在產品上會做什麼事情有明確的假設和定義的時候才能夠發生，但我們實際上並不能完全掌握所有可能的用戶行為。所以我們用了一個土法煉鋼的做法 — — 利用像是 Fullstory 或是 Hotjar 這種Experience Recording 的服務，為我們完全記錄用戶在產品上的 Session，讓我們能夠進行後續的觀察並讓我們盡可能地完善產品的 Feedback Channel建置。
Learning #6: The Balance of Speed, Learning, and Focus
所謂的 Agile/Lean 不是讓產品有每兩個星期為一單位的開發週期，而是讓你的團隊能在最短的時間內，獲得一個明確標的的大量知識，快速地讓產品成長。
當 Engaged.AI 的用戶人數爆發性成長時，我們也增加了工程師的數量，擴充了團隊，讓我們可以更即時根據用戶回饋迭代產品，並且推動產品在找尋 Product/Market Fit 上的進程。
當團隊變大時，溝通就變得困難了，我沒有辦法像以前一樣完全依賴 Private Conversation 就可以確定產品持續地在向用戶學習，迭代與優化。我需要一個辦法幫助我們時時刻刻都在同一個目標上共同努力，所以我引進了 Agile Sprint Process。
我們剛開始在採用 Agile Sprint Process 的時候結構如下：
一開始，Sprint 對於我們團隊來說，是一個協助我們在同一陣線上行動的流程，確保每位團隊成員都知道在這個 Sprint 內需要做哪些事。但在隨著 Process 的執行後，問題開始發生了。我們遇到的問題主要是以下兩個：
- Epics 在規劃時囊括了太多的產品優化項目，底下 Ticket 也很難在一個 Sprint 之類被實踐出來，導致產品經常長達一個月沒有進行重大的變動、或是從客戶身上發現新的意見。
- 當 Epics 被實踐完成後，並沒有完整的後續追蹤，確定是否有協助產品達成相對應的目標，更何況是根據學習進行下一階段的優化。
當我們重新檢視當時的 Agile Sprint Process 後發現，我們在開發的過程中忘記應該要「Ship to Learn」 — — 持續向用戶學習，並根據學習迭代產品，達到 Product/Market Fit。
那要怎麼透過產品的開發流程幫助我們持續地向用戶學習呢？我們利用以下這個 Mindset 幫助我們調整 Engaged.AI 的 Agile Sprint Process。
我認為產品最佳的學習路徑是在 Speed、Learning 與 Focus 三者之中取得平衡。
- Speed — 產品交付、迭代、跟學習是否有維持穩定的速度？
- Learning — 是否有從用戶身上取得洞見？
- Focus — 產品是否有一個明確的成長方向，還是像無頭蒼蠅一樣各處亂竄？
在這三者其中的 Focus 是新創階段很容易會忽略的面向，很容易因為看到市場上其他的可能性，或者是競品正在開發的功能，而偏離原本應該要專注提供的獨特價值主張（Unique Value Proposition）。
以這個 Mindset 作為基礎，我們對 Engaged.AI 的 Agile Sprint Process 做了以下調整：
- 每一個 Sprint 內都只有一個（至多兩個）Epic 作為目標，其他都是產品 Bug 或者是 Operational Changes，譬如追蹤碼調整、Loading 速度優化等。
- 在 Epic 的 Notion Template 中以 HMW Questions 作為 Problem Framing 的方式，提醒團隊有多種可能解決問題的方法。
- 在 Epic 的 Notion Template 中以 Hypotheses 與 Success Measurement 的欄位，確定我們需要在過程中驗證的假設，以及驗證的方式。
- 透過每月一次的 Product Review 與團隊一起檢核我們在兩個 Sprint 中得到的學習，以及根據學習對產品未來會產生的調整。
這部分的學習與 2019 年 Product Tank Taipei Meetup 中 Marty Cagan 提到的「突破敏捷的挫敗感？」有異曲同工之妙，大家也可以參考看看。第三階段：Scale
產品目標
達成 Product/Market Fit 是新創的第一個里程碑。通常在達成 Product/Market Fit 之後，這個產品都會有一定的成果，而下一步就會是把這個成果快速的擴大 — Scale。
在 Scale 階段，新創需要回答的關鍵問題是：
我要如何加速我的成長（How do I accelerate growth?）
產品經理職能
現在的 Engaged.AI 正在從 Product/Market Fit 的階段往 Scale 邁進，而我除了產品本身的優化與迭代之外，另外一個重要的職能則是持續地透過產品實驗找到方法推動產品的成長。
我們目前在團隊內建立了自己的 Growth Engine，並做了不同 Lead Generation 與 Revenue Generation 的嘗試。希望下一次能與大家分享我們在 Scale 階段的學習。
結語
在文章中，我跟大家分享了我在 Engaged.AI Problem/Solution Fit 以及 Product/Market Fit 階段的產品經理職能變化與學習。對我來說，做一個創新的產品並沒有一個絕對保證能夠成功的路徑，每個成功的產品有著各種適應這個市場的方法，但是失敗的產品的原因都大同小異。儘管如此，我們只要能夠小心的避開這些缺點、多觀察其他成功的經驗並改進套用在自己的產品上，就可以增加產品成功的機會。希望我的這篇文章對大家有幫助，我自己也還在學習，歡迎大家加我 Linkedin 一起討論！最後，我們最近正在擴充我們的產品團隊，也缺 Data Scientist、Interaction Designer 以及 UX Engineer，如果你有興趣的話也可以與我聯繫！
你可能也會有興趣…
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-20 個拍手；
如果想看更多「新創產品開發」相關文章，請盡情長按拍手（50個拍好拍滿）讓我們知道 👏🏻想要持續追蹤我們的最新文章，請記得追蹤「產品三眼怪實驗室」(◉◉◉)！
我們每週末都會認真更新文章唷！千萬別錯過了～
