檸檬和柚子，兩個委屈的產品經理：
“最小可行化迭代≠沒做好!”
檸檬設計了公司的一個創業項目。她和幾個技術加班加點，每天都是辦公室最晚走的人，但她覺得委屈的是：領導和其他同事話里話外好像都嫌棄新做的功能不完善。
“一期的東西怎么能苛求完善!“檸檬心里在咆哮“這叫最小可行化產品好嗎!MVP呀!連這都不知道!“
絕望……拒不標注優先級的龐大需求
柚子是個國企小產品，公司氛圍一片和諧，但柚子覺得自己很可悲，因為組里每個人都不理解產品工作方式，他覺得心累。
比如今天，戰略部出身的項目總監扔給他一個需求：開發一個供應商管理后臺，密密麻麻的4頁A4紙，總監講了足足1小時，柚子昏昏沉沉聽完：“您給標個優先級吧?咱們一期先做最核心的，一步步迭代。”
”這些都是最核心的呀，缺哪個都沒法用!“
柚子感到絕望，最少半年能做完的后臺，總監卻堅持每個點都是核心功能，拒不接受分期實現。
一、不能妥協的原則：堅持小步快跑，不憋大招
《精益數據分析》是我看的第一本產品專業書，在這本書里知道了MVP-最小可行化產品這個概念。
在這種產品開發方式下，一次優秀的迭代比拼的不是完善——恰恰相反——比拼的是簡單：功能點拆分得有多細，步子邁得有多碎，迭代頻率有多高，對用戶和時長響應時間有多快，這些是踐行最小可行化迭代或者說精益開發原則的產品經理們追求的節奏。
簡單說：就是步子小且快，而且在每一步校對方向。
我本人是這種開發方式的忠實擁泵。這種方式的好處已經得到無數論證，如果你想讓你的產品迭代跟得上快速變化的市場，而且盡量避免做無用功，最小可行化是應該選擇的方式。
爬上一個臺階再夠另一個臺階，不管是產品經理還是技術團隊都會覺得更輕松。但遺憾的是：別的崗位未必能理解這種好處。
假設一個電商的活動策劃，當然希望有各種花樣能玩，恨不得一次性做出個淘寶來才好。這時候你對他說，咱們剛上線一個月有很多事要做，要不先做個基礎優惠券，只能打折沒有任何玩法可以嗎?
他必然是不高興的。
你錯了嗎?沒有，你選擇的是最靈活最不容易讓技術團隊走彎路的工作方式。活動策劃錯了嗎?也沒有，他需要的是盡可能多的玩法好實現獲客目標。
在這種時候，產品經理怎么爭取其他崗位的理解呢?
我的辦法是：如果是相對復雜的功能，不管一期能實現什么都要制定較長時間排期，并且把遠景和近景都告訴需求方，讓他清楚“不是砍需求，只是拆分需求分期實現，因為這樣效率最高”。
具體分3步溝通：
提需求時不要說“不”：讓對方知道你是愿意配合的，把需求都記錄下來，并且請對方定下優先級，至少3級。管住自己，盡量不說“做不了”，即使“APP圖標和手機殼顏色保持一致”這樣的需求，還有接下來的機會拒絕，這時候開放的態度比什么都重要。
規劃全景：把對方提出的完整需求進行規劃。不合理的需求充分溝通后砍掉;合理但是優先級不高的需求放到一個較長的排期了，這樣做的目的是讓對方知道你真的有計劃做。較長時間的排期不用擔心被打亂，畢竟互聯網公司，計劃就是用來被打亂的……
做完以上2點后，雙方就能關注在合理且優先級高的需求上了。
二、小步快跑原則下，半年排期有意義嗎?
答： 就我個人的經驗，拒絕標注優先級的需求方，一般都是擔心低優先級的需求被砍掉才會堅稱每個細節都是核心功能。
沒有一個人真的質疑“小步快跑”——實際上，不管什么崗位，每個人都認同重要的事優先做。
可問題是每個人都希望：即使自己最不重要的需求，也比別人最重要的需求優先級高。所以每個人都會刻意強調每個功能的重要性，資源緊張時尤甚。
所以這時候取得對方信任非常重要。雖然都知道排期到半年后≈不做，但這種態度會讓對方安心：
“看，我已經寫進計劃里了，不會抵賴”。
京公網安備 11010502049343號