以原則為中心的產品經理(二):將正確的事推動
如果說產品經理的職責是「將用戶體驗做到極致」,不知有多少人會同意,反正我是不同意的。
「以原則為中心的產品經理(一):做什麼大於怎麼做」出了後,我想了好久都找不到接下來的主題。有一段時間我想寫「從用戶場景出發」,腦圖大綱都出好了,準備動筆之際,最近的一個項目卻再次暴露了自己經驗的不足——項目沒有按時上線。
方案出的倒是準時準點,但中途因為各種意外狀況,比如人員請假,高優先順序的需求插入等等,項目排期整整延後了半個月。方案沒拖,聽起來好像沒我啥事,但這其實就是我在事前計劃及事中跟進時缺乏經驗的表現。
我的計劃里沒有緩衝、沒有對平台近期緊急需求的預測,人員排期里沒有並行而用的是瀑布式開發,需求優先順序降低時我沒有及時調動空閑資源。我有一萬種方法可以讓工期跟上進度,可我卻傻傻的坐在原位感嘆無能為力。
我費了多少心思在用戶場景里啊,可是項目到現在都還沒上線呢。要知道有些需求一旦延後,效果將大打折扣。
當然我並不是認為用戶體驗不重要,但確確實實,產品經理不是對用戶負責的,他同時對用戶、公司和實現負責。產品經理想的應該是如何將正確的事推動。
正確的事
德魯克老先生關於「做正確的事情」有一段經典論述:效率是以正確的方式做事,而效能則是做正確的事。效率和效能不應偏廢,但這並不意味著效率和效能具有同樣的重要性。我們當然希望同時提高效率和效能,但在效率與效能無法兼得時,我們首先應著眼於效能,然後再設法提高效率。
那現在的問題是,對產品來說,什麼是正確的事,什麼是有效能的事。
注重用戶體驗對產品來說是一件正確的事,但我們仔細想想,提高用戶體驗的目的是什麼??歸根究底其實還是希望用戶能夠「購買」產品,只不過我們通過提升體驗,從更長遠的角度來提升盈利的機會。
如果一個產品用戶體驗優秀,但是商業模式不清晰以至於預期內都無法盈利,我會認為這是個失敗的產品。但是我佩服他們以用戶為導向的價值觀。
答案在我心裡越發清晰,產品所謂正確的事是平衡,是在努力考量過用戶體驗、商業盈利和技術實現後,找到一個最佳的可實行方案能將三者的價值都最大化。
剩下的就是,如何推動。
將事情推動
推動是一件很難的事,能把事情推動直至推成並不是靠執行就能完成的。都說產品經理沒有實權,是的,產品推動人靠的不是職務或者排期,靠的是影響力。
這裡不得不說一句,產品經理是一個很辛苦的職位。雖說工作在於獎懲清晰、職責分明,但作為一個有影響力的產品,可能壓根沒有職責的區分。需求文檔提交後,開發沒有看沒有重視,這是開發的問題,但更多的是產品經理的失職,你為什麼沒有想辦法讓他重視起這個需求,如果他不重視,是不是你的方案本身就沒有傳遞出有意義的價值?
回想起自己在開發評審時的狀態,我像一個戰士一樣回擊每一個質疑,這不是推動事情時該有的心態和行為啊。我給自己定了個規矩,開發評審時,理性的評判每一個質疑,以尋求更好的解決方案為目標。其實再仔細想想,開會更多是一種形式,達成共識的大部分精力和機會應該是在會前完成的。早應該在開會之前,我們就需要面對面的和開發進行溝通取得共識。
推動還可以從文檔下手,出方案是一回事,讓開發明白是另外一回事。我們出的文檔當然越簡單越好,但更重要的是,符合開發的思維習慣。我曾經想用一個文檔貫穿到設計、標註、後端和前端的所有過程,但發現技術和設計的思維是不同的,設計喜歡看列舉好的頁面,他們的思維是窮舉。技術喜歡看歸整好的頁面,希望知道哪些頁面可以復用,他們的思維是邏輯流程和歸納。產品經理是有義務為需求文檔整理出更好的展現形式的,方便了開發,人家心情一好,工期不就趕上來了嘛。
我在一開始思考方案時,會屏蔽掉技術實現,完全從用戶角度出發,實現的問題可以之後再和技術討論,這樣產品堅持自己觀點時也是有用戶場景作為支撐的。但其實再仔細想想,在構思方案時,是不是也能在不影響用戶體驗的基礎上,想一些能方便開發實現的方案。比如關於介面的請求,在頁面順序設計上,我們可以儘可能減少介面請求的次數,而把返回的結果集中到一個頁面。
不能否認有些開發對不懂技術的產品是存在赤裸裸的排斥的,這時我想借用下別人文章的描述(引用自,產品經理最重要的能力,產品經理最重要的能力):
工程師不理解需求,我們不論是畫圖、寫文檔、做原型還是直接表演給他們看,一定要弄到他們理解需求為止;合作夥伴不配合,我們不論是威逼還是利誘,拍桌子紅臉還是跪在地下磕響頭,一定要弄到他們配合為止;老闆不支持,那我們就用最小的代價和完整的邏輯證明你的觀點,說服他,沒日沒夜地說服他,廁所里堵住他說服他,電梯里拖住他說服他,滿地打滾,以頭搶地,把刀架在自己脖子上說服他;自己團隊的同事解決不了的技術或者業務問題,不論是買書自學還是徹夜查資料還是找到其他行業大牛在他樓下跪一夜,一直到想辦法找到解決方案為止。
推動的另一個難點在於和上級和老闆的溝通,我們經常會抱怨老闆總是突發奇想的插入新需求,但好的產品經理會在優先順序上和老闆達成共識(觀點來自,戴雨森,好的產品經理/糟糕的產品經理)。和老闆有了共識,調動其它部門的資源也會更加容易。
再有一個難點在於項目管理,再次引用別人的觀點,好的產品經理把有限的資源聚焦在最能夠推動產品目標的少數事情上。(觀點來自,戴雨森,好的產品經理/糟糕的產品經理。好的產品文章其實就那麼幾篇的,這篇強烈推薦)關於這點,自己經驗不足,還有待加深體會,希望以後能用自己的文章表達給大家。
結語
像我這樣一個入行不深的新人,卻妄想寫好「以原則為中心的產品經理」這系列文章,其實很難。原則這東西雖然相通,但是要把它簡練成真理一般的存在,我目前是做不到的,真誠的希望各位可以把你們總結出,認為十分重要的原則通過公眾號與我交流哦,公眾號請搜索wumuwizard,謝謝~
推薦閱讀:
※課程篇(14):產品設計-設計中的用戶體驗
※一隻煎餅的互聯網夢想
※0013數據處理:重複數據處理之條件格式法
※「經驗」與「方法論」
TAG:產品經理 |