和很多產品經理不同,我有一支強大的技術團隊。我不需要像其他產品經理那樣跪求開發去實現需求,也不需要陪吃陪喝第三下四。在團隊中,我是當之無愧的和技術老大平起平坐的角色。可是,我仍然做壞了一個前途大好的產品,這究竟是因為什麼?

2014年底,我進入V公司開始做產品,可以和業內享有聲譽的技術團隊合作,對我來說是一個不可多得的契機,即使在當時我也這麼認為。為了能快速上手業務,開始狂啃業務流程設計,希望儘快擺脫C端產品經理流於表面的壞習氣而儘早進入B端產品的角色,於是,一段過猶不及的旅程開始了。

產品究竟是為誰做的

我一直以為產品是為直接使用者做的,因此處心積慮的考慮怎樣能讓他們在使用時得到最大的方便。比如流程盡可能做短,盡量設計工具幫助用戶填寫表單等。現在發現,大多數此類功能都是過度設計。道理很簡單,B端產品的使用者雖然是一線員工在操作,但是這些操作流程都是要給他們的老闆看的,購買產品的單也是老闆買;因此,怎樣讓老闆通過這個產品更好的監控他們的員工是怎樣工作的,其意義遠大於讓員工更舒服的工作。

顯然,作為產品經理,需求都是我自己定的,越強大的團隊,越能把這些功能快速實現出來,然而,他們越快速,產品也就可能砸的越快。

到底要不要做那麼靈活

V公司是一個技術氣息濃郁的公司,言必稱系統可“靈活配置”。當時覺得牛逼透頂,什麼業務都能抽象到如此程度,簡直是上帝的邏輯。於是,在互金業務上,我也開始盡量抽象業務。為了抽象業務,我基本上把金融產品分析到自己知識能涵蓋的所有疆域,希望抽象出一個大而化之的業務模型,適配所有金融產品,用一個通用模版實現各類型金融產品的生命周期管理,銷售模型管理,持有人管理,違約管理,頭寸管理,支付渠道管理。當時熱情殊為熾盛,但是越設計越發現,字段表術語表內容越來越多,模版要包含的內容越來越多,最後,把自己給整傻了。

糟糕的是,在我的錯誤思潮帶領下,強大的技術團隊也投入到轟轟烈烈的抽象事業中,希望一口氣造個航空母艦。

我想跟技術團隊和測試團隊說聲對不起,如果我能不那麼自以為是,把自己當上帝,也許我們的產品早就出來了,我們也不會在年底集體遭到老闆的責難,最後走到集體崩盤的狀態。

作為產品經理,我不應該盲目聽信老闆所說的“先不急上線”,就覺得有足夠時間去抽象一個完美的產品。老闆的想法隨時可能根據市場的變化,搖身一變成為“怎麼還不上線?”到那個時候,整個團隊的主動性就已經完全喪失了。主動承擔更多市場分析工作,根據自己對市場的判斷來調整版本計劃,才是應有的大產品思維。

不配合BD是什麼心態

團隊中,產品和研發都是擅長邏輯思考的動物,不難形成共同語言。而BD是另一種動物。過去我很不喜歡聽他們說“你去忽悠他們一下啊”,“你去用你的專業知識嚇唬他們一下啊”,或者“你就說我們有這個功能嘛”。現在回憶起來,這的確是一種不成熟的想法。

一個人,既然追求俗世意義上的成功(即實現財務自由),就要按照俗世的規則去做一些事情,這是必要的代價。在任何時候都清高,只能證明自己的愚蠢。即使BD的語言方式在我的邏輯中是不嚴謹的,我都應該自帶編譯功能,用我自己可接受的方式,盡可能配合BD同事的工作,有可能並不是去“忽悠”客戶,或者“說我們有這個功能”,但是,只要能使用自己的專業能力有效幫助商務拓展工作,配合的工作也應該算完成的不錯。

然而在那個時候,我通常會一個白眼翻過去,“叫我去忽悠?你以為我是你哪!”

是的,整整一車開發,很大程度上由於我的原因,被帶溝里去了。不幸中的萬幸的是,由於我不是唯一責任人,他們並不恨我。

更多更細節的問題,大多是圍繞着“這個功能究竟有沒有必要現在做”這件事展開的。從溝里爬出來之後,我得到的最大的教訓就是:除非有特別確實的跡象證明這個功能要做,其餘一律不做。

 

本文由 @echo回聲 原創發佈於人人都是產品經理。未經許可,禁止轉載。