產品經理,如何應對“老闆改需求”?
從零開始學運營,10年經驗運營總監親授,2天線下集訓+1年線上學習,做個有競爭力的運營人。 瞭解詳情
釋放雙眼,帶上耳機,聽聽看~!
00:00
00:00
老闆對產品經理價值的評估,同樣取決於是否為公司創造了價值。身為產品經理,你要考慮不僅只是使用者的需求,還要同時考慮到老闆的需求。
在創業公司以及一些中小型公司裡,很多產品經理會遇到這樣的問題,在專案執行的過程中,因為老闆不參與需求的評審,所以很多事情都沒辦法去跟老闆確認。但是等到專案結束,版本上線以後,老闆會非常認真的參與試用,然後提出很多問題。
當然,如果只是一些小的問題,比如UI沒做好,互動效果不是很理想,可以直接線上修正,或者發個小版本迭代掉。
但是如果遇到功能與業務目標不一致的時候,會出現專案需要返工,然後整個專案組的人都要加班加點的完成,無論是從士氣上,還是從工作強度上,都不是一件很好的事情。那麼,遇到這種情況,產品經理應該如何去面對?
其實並沒有一個方法可以完美的解決這個問題,只能是作為產品經理的我們,從一開始就注重各種流程環節,儘量把這種可能性降到最低。
一、首先先修煉內功
產品經理與老闆之間的博弈,往往是付出與收穫之間的博弈。老闆發了工資,就希望員工產生相應的價值,產品經理也不例外,很多時候很多老闆評估產品經理是否為公司創造了價值的唯一標準就是,產品經理做出來的東西是否符合自己的要求。那麼這個時候,就需要產品經理先修煉自己的內功。
你要非常清楚在這個公司裡,什麼樣的功能是老闆最為關心的,什麼樣的使用者是老闆最為在意的,而你在設計功能的時候,一旦覺得觸碰到了老闆的敏感區域,就要及時做好心理準備。
為什麼我們說初級的產品經理才關心使用者體驗,高階的產品經理一般只關心利益,原因其實很簡單。產品經理做出來的產品往往是為公司的利益服務,而不是為了某一個使用者服務。
很多產品經理認為,如果不是因為使用者覺得這個產品有用,他們也不會去使用產品,也不會為產品買單,其實這是很初級的想法,在後網際網路時代,驅動一個使用者去使用一款產品的原因一定是使用者的目的性得到滿足,也就是我們所謂的使用者痛點。但是這樣的痛點基本不會是因為一個功能體驗的好與壞能決定的,而是公司的業務決定的。
舉個例子,在傳統的企業採購業務流程中,電子合同是一個非常高效且低成本的業務,如果你是一個可以為使用者提供這個業務需求的產品,那麼即使你的使用者體驗做得不好,自然也會有人去用。所以忘記所謂的使用者體驗,迴歸到公司利益上來吧。
二、然後你要理解清楚老闆說的話
很多老闆在下任務的時候,往往說的非常不清楚,也許只是一句話,也許是隨手扔了一篇報告,這個時候就需要考驗產品經理對老闆說的話如何理解清楚。
很多產品經理在得到老闆的指示的時候就會去想功能應該怎麼設計,其實這並不是一個明智的做法,是因為有可能連老闆他自己都不知道自己想要的是什麼,如果你把老闆的話當成是需求來分析的話,你就會發現他提出來的壓根就不是一個需求,那麼即使是你想破腦袋都不一定能想出一個是他真正想要的。
曾經我的老闆給我下過一個任務,他需要知道每個銷售商,每個合作商每個月的銷售情況,我一開始以為他要的是一個分銷體系以及財務報表系統,等我花了一個多星期時間設計出來以後才發現,其實他要的只是一個邀請碼功能,並且在管理後臺可以看到每個訂單是由哪個銷售商和合作商的使用者產生的訂單。
三、再然後你要從內部評審開始
嚴格意義上來講,內部評審這個環節其實屬於產品研發流程中最為重要的一個環節,但是很多產品經理不會去重視這個環節,甚至還有很多產品經理並不知道有內部評審這個環節的存在。在他們的思維裡,認為評審就是跟開發把需求詳細得過一遍,就進入開發階段。
其實這是不正確的,很多時候功能上線了以後,發現與老闆的預期出入太大,往往是在內部評審環節出了問題,那麼我們首先要搞明白內部評審到底是評審什麼?
在開始講內部評審環節時,產品經理需要非常清楚的知道一件事情,那就是如果對公司當前業務不會造成太大影響的版本迭代,往往可以忽略掉這個環節,那麼這個時候就是需要考驗產品經理的經驗。
1. 評審業務解讀是否正確
如果當前版本計劃中,涉及到對業務的解讀,產品經理一定要在內部評審環節跟老闆確定自己對業務的解讀是否有誤,包括業務的流程,業務的邏輯,都要鉅細無遺的跟老闆過一遍,及時查漏補缺。因為往往產品的功能流程和功能邏輯一定是要與業務流程和業務邏輯相符合的,如果脫開了業務,設計出來的功能再好,那也是沒有任何作用的。
產品的價值體現在為業務創造價值之上,所以業務解讀是非常重要的。
曾經我在設計一個報價功能的時候,因為不清楚業務中是由報價方來給出價格中是否包含稅費,所以在內部評審的時候發現功能設計得有誤,好在及時發現,將功能修正了過來。
2. 評審功能設計是否能達到預期
內部評審的過程中往往會因為需求可能來源於運營部門,所以在評審的時候,產品經理需要與運營部門去討論功能的設計是否能達到預期。
比如涉及到秒殺、抽獎這類的活動功能的時候,運營經理往往都想要設定一個可以手動去調整中獎白名單的功能,或者是線上修正抽獎概率的功能,那麼這個時候產品經理應該提前能夠預知到運營經理可能會存在哪些額外的功能需求,並在進行功能設計的時候一併規劃進去。
即使需求不是來源於運營部門,你也需要把相關人員都聚集在一起,把你的設計的功能的大致邏輯給所有人都講一遍,力求功能的設計能達到他們的預期,只要大方向保持一致,細節上的問題是可以被允許的。
3. 評審人力資源是否能滿足要求
內部評審環節很多時候會因為工作量較大,而選擇讓開發組的組長、測試組負責人以及UI組長提前參與到評審的過程中來,所以這個時候就需要在內部評審會議上,跟研發部門相關負責人確認清楚人力資源是否能夠滿足要求。甚至可以在內部評審階段,就評估出一個大致的研發週期。
四、不要忘了及時將資訊同步給老闆
在絕大部分中小型公司裡,老闆往往對於公司裡的大小事務都會過問得鉅細無遺,一個功能怎麼做,一個活動獎品怎麼設定,恨不得每個工作都要親自參與進去。
這種勞模型的老闆,其實對於員工來說是非常痛苦的,因為他們會覺得老闆每時每刻都在監控著他,做起事情來也是束手束腳,生怕一個沒做好,就收到老闆的訓斥。
其實很多老闆並不是真的懂得如何去做這些執行層面的工作,他們只是每天都在迫切的想要知道員工拿著公司發的工資,到底有沒有好好的幹活。所以長期以往,就會導致員工和老闆之間會產生隔閡,產生矛盾。
那麼其實對於產品經理而言,很多時候要反其道而行之,要知道產品經理有一個職業素養很重要,那就是主觀能動性。你要學會主動將資訊同步給老闆,你不要怕老闆嫌你煩,因為這是一個職場人應該具備的最基本的職業素養。
1)開完內部評審會議以後,無論老闆是否有參加會議,你都要把評審會議的結果以正式郵件的形式傳送給所有與會人,並告知給老闆,在這封郵件中,你需要詳細的把評審過程中所記錄的問題以及相關的解決方法都列出來,等老闆答覆確認郵件後,再行啟動開發。但是在這個過程中,一定要區分什麼樣的內容要同步給老闆,什麼的內容部需要同步給老闆,不要讓老闆認為你很沒有主見。
2)你可以定期或者不定期的給老闆洗腦,無論是在評審會議上,週會上,例會上還是在跟老闆吃飯、泡澡、喝茶的時候,你都要抓住機會給他洗腦,讓他對你這次的版本迭代內容做到牢記於心,以防止後期他以不記得會議內容來讓你返工。
五、還要記得抓住一切機會給老闆科普
你永遠都不要認為自己的老闆對網際網路很精通,你也永遠不要認為做一個網站一個App很簡單,老闆不會不知道。我見過很多土豪出生的老闆創辦網際網路公司,甚至自己只是會玩幾個APP而已,我也見過很多老闆看過幾篇文章,能說得出幾個專業術語也是僅此而已。
那麼作為產品經理,就要學會抓住一切機會給老闆科普。你要告訴他產品的研發流程是什麼樣的,一旦專案啟動研發以後,臨時改變需求會給多少人造成多大的困擾,會讓多少人做無用功。
你要告訴他一個功能從設計出來到發版上線,中間要做多少工作,功能是基於什麼樣的場景,什麼樣的需求被設計出來的,如果一旦做出改動,會造成多大的影響。
你可以曉之以情動之以理,也可以恐嚇他,你可以使用一切你覺得合情合理的方法讓老闆認為輕易改變需求是一件很不好的事情,要讓他感覺到內疚。
六、最後硬氣面對老闆改需求
很多時候,當我們已經把前期的鋪墊工作做完以後,難免會遇到就是很軸的老闆,版本上線了死活要改需求。老闆的任務當然要執行,但是我們在執行任務的過程中,其實可以做得更好。
1)給一個折衷的方案給老闆,既能以最小的工作量去修改功能,也能滿足老闆的要求;
2)學會拒絕老闆的任務,不是所有的任務都需要去執行的,你要學會拒絕。但是你在拒絕的時候,一定要跟老闆講清楚,為什麼這個任務不能做,原因是什麼。
與老闆相處其實沒有那麼難,重點在於你是否能夠站在老闆的角度去思考,是否能夠站在公司的角度去思考,不要一味的沉浸在你的功能設計中,好的產品經理更多的應該是傾向於老闆。
#專欄作家#
大V姐姐,微訊號公眾號:PM咖(PMzone),人人都是產品經理專欄作家。7年網際網路產品和運營實戰經驗,專注社交營銷領域,提供運營顧問諮詢。
本文原創釋出於人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基於 CC0 協議