要踩夠多少坑，才能成為一個合格的產品經理——我，是一枚硬體研發轉型的產品經理。2016年進入一家智慧硬體初創公司，至今一年半，沒有成功的產品經歷，只有踩過的一個又一個的坑。

一、公司背景介紹

公司是以技術起家，公司創始人是在學校孵化產品原型，在這一塊有技術積累，參加創業大賽拿到風投後，快速推出產品上市。我加入時，公司註冊半年，人數30左右，一代產品剛上市。公司除了一個產品總監，沒有其它產品人員，產品總監也是研發轉型。

坑點：對於產品新人，找個有人能帶你的團隊，事半功倍。

一定要重視這點，重要的事情放在最前面說。

二、用研：沒抓住一個使用者的心，卻說自己是產品經理

沒做透使用者調查，就開始做產品功能，這是我犯過的最痛心的錯誤。上面也說了公司是技術孵化，第一代產品是創始人扮演產品經理的角色，除了特色功能，產品的功能與市面的產品重合度很高。我進公司的第一個產品是一代的改進版本，一代上市後遇到很多問題，公司準備推出一個迭代版本替代一代產品。

作為一個新人，我很自然理解為改進原有產品問題，提高使用者體驗。

去看現場使用，電話回訪使用者使用問題，內部收集問題，再加上自身體驗發現問題，前期花了很多時間在蒐集問題和改善方案上。隨著工作的開展，卻發現產品本身的功能和定位存在很大問題，使用者沒有粘性，使用者活躍度低的可憐。可是這個時候產品已經在開發中，而我已經陷在專案開發中，爬都爬不出來。

現在回顧，產品的使用者群沒有定義清晰，典型的使用場景也沒有定義清晰，一代的功能和產品定義本身就有問題，新版本再怎麼優化體驗其實都是徒然。

前天去面試，面試人讓我舉例證明自己的需求分析能力，我有點恍惚，證明的沒有，失敗的慘痛的倒是有一個：使用者要找準，核心功能要做透，滿足著兩個前提再去優化體驗和周邊。

一些初創公司倒在產品定義上，很多都是犯了這個錯誤，沒有掌握一套有效的方法去迭代。還有就是網際網路產品的反饋系統、資料監測、軟體更新已經非常成熟的，但是智慧硬體產品上還相對不成熟，我所在的公司就對反饋、資料監測，韌體更新等重視不夠，沒有辦法形成一套反饋優化迭代的流程，產品出去了不能及時獲取到反饋資訊，進行快速迭代更新。

很多公司硬體產品賣出去了，也不關心日活躍怎麼樣，那就更不用說去改善了。

三 、質量：一次事故

入職2個月時的某一天，正在用墨刀畫著原型，有個市場的兄弟反饋產品的App核心功能訪問不了。馬上找開發的兄弟確認原因，原來是一個開發兄弟自己測試後，直接打包釋出到應用市場，而打包用的是測試後臺的程式碼。我只能內心默默說一句：尼瑪，這也可以！

發生這件事後我開始意識到公司產品開發流程的缺失帶來的問題：公司的現狀是完全的原生態，沒有流程，沒有文件規範，沒有稽核，但是公司開發人員又在擴張，這樣是很容易出質量問題的。拉著產品總監和軟體總監，討論開發流程中的問題，最後結論是後續App打包由軟體總監負責，由產品經理確認後釋出，並且儘快補充測試人員。

這件事情同時也帶來了一點負面影響，軟體總監認為我懷疑他個人的把控能力，有抵觸情緒，撕了一架。和開發撕，只要是對的，多堅持一點。很多時候，開發一句實現不了，你放棄了就真的沒有然後了。上一家公司部門的原則可以借鑑：開發可以說不能做，但是要是其它公司做出來了，這個開發績效打C。

四、職責：產品經理與專案經理

初創公司沒有專案經理是比較常見的事情，所以產品經理通常也要兼任專案經理。作為一個產品新人不知道里面有什麼坑，開始的時候覺得挺好的，把以前在HW產品經理、規劃、SE和專案經理乾的事情都承擔了。

然而二個月後，老闆整天“這個事情怎麼又延遲了”，“這個方案怎麼這麼難看”，“這些細節怎麼都沒人處理”；開發的兄弟也不讓人省心，Bug一波接一波：“這個功能我們CES前實現不了”，“機器人的音量、語音反饋速度怎樣才算OK，產品要給個標準”…

很多初創公司的產品經理做著做著，會覺得自己像一個產品質量管理員。當你把大量的時間花在進度、質量和日常瑣事上後，自然沒有足夠的精力投入到產品設計和優化中。睡覺前想想自己每天處理這些糟心的事情，有點心酸，你知道這樣是做不出好產品的，但又只能沿著這條路前進。當你由於進度只能拿出一個糟糕的方案時，你已經慢慢忘記自己是個產品經理了。

坑點：產品與專案職責中有矛盾的地方，產品要把控標準和體驗，專案要把控進度和成本，很多時候好的方案和體驗都是與時間和成本矛盾的，特別是硬體產品，1個月一個迭代週期很正常。背後的本質是使用者視角和開發視角的衝突。

對於經驗豐富的產品經理或者周邊部門配套完善的公司來說，可能會好點，但是對於初創公司，這真的是一個頭疼的問題。

以我的觀察來看，將軟體產品經理和硬體產品經理分開，由硬體產品經理來負責硬體的專案管理，減輕產品經理在專案開發中的負擔，或者單獨招聘專案經理，會有幫助。

不管哪種人員配置，建議先把開發流程理順，分階段和節點管理專案，這樣能更好控制開發進度；將團隊成員的職責劃分清楚，什麼階段什麼事誰主導誰配合規定清楚，可以讓專案跑的順利點；然後採用一套適合公司的任務管理工具，讓開發過程可視可跟蹤。

五、進度：不斷變更的開發週期

入職1個月後被安排負責下一代產品的開發，在開發過程中，我負責的產品由計劃的4個月上市，變成6個月，然後變成9個月，最後變成至今未上市。現在反思整個過程，犯了太多錯誤。

4個月變成6個月，主要是我樂觀估計了App的開發週期。前期公司高層不斷給壓力，要早點出來趕上CES時間，評估是基於原型評估，但是後面細化需求和UI後，開發評估時間不能實現後，CES演示內容刪減，產品計劃重新梳理，變為6個月。

這個過程中最大的問題是產品這邊和開發的溝通問題。早前的需求是通過文件和會議傳達，基於原型評估，過程會有很多變動和理解差異，體現出來就是產品不能有效將需求傳遞給開發，資訊不對稱，這個過程也是和開發矛盾最多的時候。

這個問題在建立需求評審流程、和建立工單系統後得到改善，在這兩個流程開展半年後，和開發之前的溝通問題明顯好轉，隨著不斷完善，開發端的溝通逐步正常化。17年公司總結，開發部和產品部都表示認可這套機制，尤其是之前矛盾集中的軟體開發。記得在起點學院，一個創業導師講在公司早期需要明確產品開發流程，現在想起來深表認同。

6個月變成9個月，9個月變成至今，是起始於一個小的變更。這個變更最開始確實很小，需求點是優化產品的硬體外觀，把走線隱藏起來。最開始我和開發一起想辦法優化走線方案，由於公司Boss比較關注，這個問題也慢慢升級演變，後面變為更換關鍵零部件來徹底解決，而這個關鍵零部件公司也打算自己研發。

我們確實也提出了更好的解決方案，而且很快驗證了原型，大家也看好這個技術點，也申請了專利。公司預期的開發週期會導致產品延期三個月，Boss決策要等這個問題解決後釋出，而且關鍵零部件自己研發對於公司意義重大。產品也認可這一點，認為無論對於公司還是產品都會提升競爭力。

然而現實情況是這個關鍵零部件的開發一再延期，由於技術出身而又缺乏經驗，公司研發樂觀估計了開發週期。

坑點：不成熟的技術方案，在正在開發中的專案應用，要慎重，這種變更帶來對專案週期的影響往往被低估。

中間市場一再催促產品上市，我提出採用替代方案，讓產品儘快上市，後續自研成功後再替換，這樣可以兩步走。Boss也直接Pass掉了這個方案，因為這個方案現在代價也很大，人力也不支撐，已經箭在弦上不得不發，這個部件必須研發成功。

坑點：Plan B要有，而且在變更一開始就要有。木已成舟後，執行Plan B的成本會增加，甚至變得沒有可行性。

這直接導致了產品至今還沒有上市，更重要的問題的是：們之前規劃的特色產品功能，隨著競爭對手產品的釋出，頓時變得尷尬起來。回首這一切，深感痛心。

坑點：不要低估專案延期帶來的影響，永遠都不要忘記還有競爭對手。

如果當初更加堅持，不是因為Boss決策就遵從，而是更加堅持去深究合理性，結果會不會不一樣，還是沒有擺脫唯上的心理，默認了“老闆是不會錯的”。Boss一個想法，一紙令下，改變了一個產品的命運，這也是創業公司最容易遇到的問題之一。

我比較深的體會是產品越沒有自己的意見和調查結果時，越容易被Boss主導，Boss也越容易拍腦袋下決定，一不小心就拍到屁股上。這個過程中，Boss和產品就像博弈的雙方，產品沒有充足的理由時會淪為結果的執行者。

六、產品迭代：MVP+讓正確持續發生

產品經理最重要的兩個價值點：一是做對，二是做好。而背後的方法和流程、資源是支援這一切發生的元素，最關鍵的資源是人。

創業公司的早期產品很可能不被市場認可，銷量不佳，但是要有一套快速不斷迭代，趨近對、趨近好的方法。《精益創業》裡面講述的MVP+快速迭代很適合創業公司。

一個好的產品，不是產品經理一個人能決定的。除了產品層面，公司的層面其實也是需要不斷迭代的，快速磨合，讓適合的人出現在適合的崗位上，公司本身在人、運轉上是要有競爭力的。

公司之間的競爭與戰爭是很相似的，公司的管理層猶如軍隊的作戰指揮員，不能放上一個沒有經驗人去指揮，等著他成長，他長大了戰也打完了。產品哪一塊有問題，回頭去看這一塊的指揮員，可能會發現這一塊的人崗不匹配。

創業公司早期應該格外關注上面兩個問題，要想辦法去創造一個讓正確發生的環境，去產生持續正確，而且速度還要足夠快。創業公司的負責人在這個裡面的角色非常之重要，通常他是這個環境的締造者。

七、培訓：員工成長

初創公司人員相對大公司，團隊的知識儲量是相對較弱的。另外，通常創業公司人員質量也參差不齊，這是初創公司的風險和人力資源薄弱導致的。在這種小團體內，知識是有侷限的，如何高效利用內部和外部的知識，以及補充團隊知識的短板，是很重要的。不進步或者說進步太慢，看不到行業的全域性會限制初創公司的發展。

一個組織進步獲取新知識主要來自三個方面：

1. 自我學習，例如開展培訓、從合作伙伴身上學習；
2. 吸收新成員，新成員帶進來新的知識和經驗；
3. 組織自身經驗積累。

培訓和總結對於初創公司是一種相對低成本的成長方式，它能擴充套件成員的知識邊界，也會加強成員之間的溝通，為團隊帶來統一的交流語言。《創業維艱》的作者很看重培訓，從我看到的情況，真的很有必要。我覺得這可以作為產品新人找公司時的一個問題，看看面試你的公司是否足夠成熟。

八、智慧硬體：在硬體這條路上一去不復還

智慧硬體類創業公司，如果創始團隊之前沒有硬體開發和生產經驗，比較容易放的錯誤有兩個：一是過於樂觀估計開發週期，實際週期乘以2乘以3是常見的；二是對產品品質意識不夠，對出現的個別問題重視度不夠，對生產端重視度不夠。硬體產品的質量是要全流程把控的，影響最終效果的因素太多，負責生產和品質的人一定要經驗豐富，否足容易遲遲走不上正軌。

目前智慧硬體類的產品經理相對比較稀缺，網際網路產品經理轉型做智慧硬體，常見問題是質量不行；傳統的硬體產品經理，通常又很不網際網路。一個是網際網路重塑了產品經理的職責內涵，二是同時有軟硬背景的人比較少，有一定工作經驗的更少。

做好一個智慧硬體產品經理真的有難度，硬體+軟體+內容，做好一個領域都夠人折騰的，更別說三箭齊發。一些公司會劃分軟體產品經理和硬體產品經理，然後根據產品形態指定一個為產品總的負責人，也有一些公司會讓產品經理同時負責軟體和硬體。

起步階段的創業公司可能會採用第二種，因為早期沒人，然後隨著產品形態的成熟和產品線的擴充慢慢過渡到第一種方案，當然這個也因公司而異。

不管怎麼樣，本質都是融合，線上和線下的融合，軟體和硬體和融合。到後面，小公司的智慧硬體產品經理需要更加全面而又在某一塊足夠專業，大公司就是分工協作，崗位進一步細分。

九、股份與期權：慎重

股份與期權也是到創業公司經常遇到的一個問題。有一情況儘量避免：降薪+股份或期權加入創業公司，這樣會導致不合適時你退出損失比較大，因為通常這種股份或期權的兌現是有各種限制的。如果不能避免，最好和公司確定好退出時股份如何處理，是否可以折算或者轉讓。

另外，創業公司的股份或期權合同可能有一些漏洞，後面容易引起紛爭，最好讓專業人員稽核下內容。之所以寫這些，因為這兩種情況我都遇到過。