一、戰略失誤
我做的第一款產品在今天看來，絕對是屬於戰略失誤的典型。從整個市場來看，這款產品的領域已經存在太多的典型和優秀的產品，和絕大多數領域和絕大多數產品經理一樣，在產品層面上都不會有創新，做的事情只是“複製”一份產品方案，就是一種“重造輪子”的複製一份市面上的解決方案服務商的產品或競品的功能。時至今日細細思考，這款產品的特色和功能價值不突出，功能不穩定，交互體驗差。耗時耗力、費盡心思不斷地做大量相關瀏覽、梳理、歸納、總結綜合而成的產品，設計奇葩，交互奇怪。通過觀察，這類型的領域很多，比如在線教育、電商、知識付費等領域。對於這類型領域的產品，實際上是不值得這樣花費的，這些領域在市面上有很多產品解決方案的服務商，幾千或者一兩萬就能夠購買到一套成熟的產品方案，但是如果自己研發，時間成本+人力成本，一年至少百萬以上。最爲重要的是時間成本，很有可能讓公司錯失了關鍵的或最佳的運營窗口期。
在同類型產品領域市場已經存在太多的典型產品的情況下，我們應該通過“運營”的角度來設計產品功能。不同領域不同產品，真正的創新是在“運營”層面上的，根據不同的“運營場景”來設計產品功能，考慮產品需求的市場背景和運營場景。而這款產品在設計之初，就過多的對標了競品的功能和設計，導致花費大量研發時間和人力在產品的功能上，反而應該是產品本身的特色和附加值的基本盤和核心競爭力，均沒有時間進行集成和開發。試錯成本很高，我要感謝公司給我的寬容及成長。
二、戰術失誤
此外，在第一款產品上，戰術同樣失誤。由於產品的功能和現有市場領域產品的功能相似，在研發力量不足的情況下，耗費太長週期“重造輪子”，沒有充分利用開源的力量。產品實現的功能，在GitHub這樣的技術社區也能找出N多個來，類似功能控件等模塊化的方案，在許可允許的條件下我們都可以引用於產品中，這樣可以加速我們的產品功能實現。將錢和研發力量花在運營層面上，纔是最高回報率的投入。
實質上產品本身僅僅只是一個內容的承載平臺，而我們卻花費了一年多的時間在產品本身的功能實現上，內容運營本身還未來得及投入研發力量着手解決，業務需求已經開始推着我們不得不投入力量進行內容運營的開發工作。這就導致我們的工作越做越多，一旦有突發事件和應急事宜，項目成員都會手忙腳亂。完全打亂之前的節奏，等應急事宜忙完回來，項目又得重新開始進行梳理。
三、管理失誤
從項目管理角度上來看，也是存在着很明顯的失誤。包括每天代碼的提交，最開始項目的構建完全是程序員本地進行開發，項目成員之間通過相互拷貝代碼的方式進行代碼合併和代碼版本管理。導致每次版本的合併及更新都會出現問題，有時甚至分不清楚主次版本，甚至還會導致部分代碼丟失。這完全是屬於代碼管理上的嚴重失誤，在影響效率的同時，也造成項目開發的混亂。後續採用git等工具進行代碼版本管理，情況稍微得到改善，由於我本人並沒有進入開發，僅管控進度，項目成員之間的代碼質量屬於放養式管理，項目開發人員沒有定期進行Code Review，代碼質量出現不可控因素，也導致後續一系列的功能優化和修改均費時費力。
我在項目中給予了他們非常充分的信任，信任他們可以把一切事情都做好。但我沒有在正確的時候給予他們正確的指引，項目中出現的困難點，我也沒有幫助他們解決，甚至於沒有給出思路。所有的一切，都靠他們自己完成。我在這個項目裏做的，就是對接需求，催進度。再無第三件事。
基於以上原因，我掉以輕心，沒有在項目初期進行項目的設計和規劃，未指定任何開發規範。僅僅告訴開發的同事要多複用，也未檢查他們是否真的複用了。
項目開發中的需求變更，需求反饋意見，我都僅僅是告知他們一聲，未做詳細的修改規劃，所有事情都靠嘴說，所有變動都放在了我和他們的腦子裏。
對項目上心程度不夠，未對需求變更做控制和管理。所有變更都壓給了開發的同事。
整個項目以及其不規範的方式在運行，我也未在其中起到控制作用，項目開發一團亂麻。
項目開發過程中，也未讓開發間互相進行代碼review，也沒有進行代碼評審會。其實代碼中出現了很多問題，最後檢查代碼的時候，發現各種命名不規範、代碼複用不到位、簡單邏輯複雜寫等等。而這些問題，很大一部分都是早期未做規定，未指定人負責項目、未進行早期code review造成的。開發各自爲戰，難免造成代碼問題。代碼質量的問題，淋漓盡致的體現的在項目中，項目中的諸多bug，都是因爲代碼不規範引起的。甚至於開發人員自己對自己寫過的東西，都有些拎不清了。
綜上，導致這款產品的特色和功能價值不突出，功能不穩定，交互體驗差。現在還在投入研發力量進行修補和優化。