論產品經理的自我修養

如何避免和開發的日常撕逼...

實在是不想寫開篇語了...

算了,還是寫吧,要不顯得文章沒頭沒尾很敷衍...

思考中:怎么寫能引起大家的興趣,使大家讀下去呢...

算了, 不玩套路了,直接來:產品和開發的日常撕逼,看似正常,其實可以避免,之前老K一直強調溝通能力的重要性,其實,最最根本的,是產品經理要有基本的自我修養

下面,論產品經理的自我修養:

別YY需求

產品經理提出任何需求,原因一定不是,不是,不是:老板想要、運營需求、競品已有等等這類**的理由(老K曾在產品經理7神器——說服程序猿一文提出過說服程序猿的法寶,這明顯是用來搞笑的,聰明如你們,一定懂得吧)。任何需求,都要從產品目標&用戶需求兩個層面去考慮,首先找到充足的理由說服自己,然后再去說服技術。

舉個例子:比如理財產品都涉及綁定銀行卡這樣的功能,一般需要手動去輸入銀行卡號,體驗很差。所以PM提出優化方案:用拍照識別銀行卡來代替手動輸入。這個需求,從產品目標上講:符合產品科技金融的定位&簡化操作可以提高轉化和留存;從用戶需求上講,極大的優化了體驗,用的爽!

做好信息共享

很多PM在需求評審時只告知要做什么,而不說明為什么要做。是啊,程序猿負責實現功能就好了,說其他的有什么用?然,這種想法是絕對錯誤的,大家同屬一個Team,一定要讓每一個人都明確目標,同時也明確自己的努力可以向目標邁進一步。

而且,經驗豐富的程序猿會想到功能可能的延伸方向,提前做好可擴展性。

不要強行評估工作量

即使是技術出身的PM,也不要強行去評估工作量并確定工期。切記,專業的事兒交給專業的人去做。

盡量別改需求

對產品來說,改需求是一句話的事兒;對技術來說,改需求可能意味著代碼廢棄、框架重構...簡單說來就是通宵兩天寫的幾千行代碼沒用了。。

所以,承接第1條,別YY需求,所有的需求都從產品目標&用戶需求的兩個層面去考慮周全,避免在開發的過程中改需求。

及時反饋結果

功能上線后,達成的效果要及時反饋給程序猿(挑好的說),雖然大部分程序猿并不關心運營指標,但自己的努力取得了很好的效果,他們還是很高興的。同時,也會建立程序猿對PM的信心,信任PM的眼光,由此形成良性循環,溝通上會更加順暢。

把握好"度"

前段時間看《我的前半生》,其中賀函對唐晶的一句話讓我印象很深刻:你學會了我的所有技能,唯獨欠缺的是把握一個"度"(具體臺詞忘了,大概這個意思...)。

其實很多同學都缺乏這個,怎么講呢,舉個簡單的例子:需求會后定好了上線時間,但是在測試過程中發現一個BUG影響很大,難以解決,怎么辦?逼開發通宵加班解決BUG?講道理你沒錯,確定好了時間就一定按照時間節點走,但這類難以預見的問題影響開發進度,該怎么辦呢?

所謂的把握好"度",所謂的人情世故,大概這樣吧...


-end

關注公眾號:產品經理日記(ID:p_m_diary)回復“PRD”,獲取鵝廠內部需求文檔模板!

2條評論 添加新討論

11月10日評論

而且產品的很多創新很難被別人理解,同一行業甚至對同一產品的看法,產品經理內部都可能觀點不一致,各有道理,但哪個更有理?哪個更能被市場和用戶接受? 很難衡量,在理論站得住腳的前提下,只能實踐去檢驗,否則就沒有敏捷開發這一說了

回復
11月10日評論

你說的根本不現實,老板要,運營要,競品有,這些理由看似不上臺面,但很有效。 你的所有前提是建立在企業氛圍特別好,產品經理真正的在做產品的前提下,現在這個環境,有幾個公司能提供這種環境。 人性太復雜了。

回復
登錄后參與討論
Ctrl+Enter 發表