本文轉譯自Quora，原文鏈接見末尾。

Ian McAllister, Director at Airbnb

首先你需要確定一個優先順序的評判標準，這樣可以大大幫助你去做類似的決定，這個標準框架包括：

  • （攻）你的產品或者公司的目標願景。這個是指導你投資發展業務的最高級別的指導綱領。你的目標可能是增加新用戶、提升轉化率、留住老用戶、提升產品性能、拓展國際市場。需要注意的是，你所做的個別產品項目並不是你的目標。所謂的目標應該是橫向通用的，目標應該要儘可能少且精簡，在決策中有指導地位。
  • （防）基本需求：指其它的東西，比如質量標準、設計標準、可用性、性能指標或者其它基準規範，這些東西可能沒有上面說的目標願景優先順序高，但其實也挺重要的，不能忽視。

一旦你有了上述的評判標準框架，你就可以分配一定的資源來滿足你的基本需求，並把剩下的資源投入到你的目標願景上。如果你把很多額外的精力投入到你的基本需求上，那麼你就可能在你的目標願景上投入資源不夠，也就沒有辦法拓展你的業務。如果你發現滿足了基本需求後，沒有足夠的資源來應對目標願景，那麼你的人手也會不夠，那你就可以把你的基本需求再往下調整一點。

如果你能夠適當的調整資源（比如輪流安排工程師來做基本需求），那麼你就可以獨立安排（攻防需求）基本需求和目標願景之間的優先順序。根據我的經驗，這比根據具體情況確定兩者（比如新需求與bug）的優先順序要簡單的多。

Michael Wolfe, five startups and counting

從理論上講，所有的產品資源投入都應該與業務目標相匹配，所以產品管理團隊應該在新需求、質量、規模和工程團隊所做的一切事情上投入資源。許多產品經理持有這樣的看法。但是，我發現這個東西在實踐中總是有一些問題，原因可能如下：

  • Bug導致更多Bug。即使是一個用戶永遠也不會遇到的Bug，也有可能會有一些隱藏原因或者造成連帶問題，修復它可能會產生比預期更大的影響。
  • Bug會榨乾技術支持及工程團隊的資源。通常，產品經理們纔不會看到工程團隊投入了多少資源來修復用戶的Bug。
  • 產品經理們平時的工作就已經夠煩的了，平時就得要時常評估新需求，還要求爹爹告奶奶討開發資源。然後還要把幾十個Bug的修復加進決策範圍內，他們就會陷入無數次優先順序的討論，幾十個小項目的拉鋸戰中。
  • 討論質量問題可能會對工程團隊帶來不好的影響，也可能會拖累企業文化。就算是大老闆說質量是首要的工作，那也會導致，產品經理與工程師們無休止的討論是否應該修復這個Bug以及對應的優先順序。
  • 工程師有的時候也挺難的，會覺得自己在為產品管理而工作，而且每次做需求都要徵求許可。除非他們自己覺得這個東西應該做，偷偷不告訴產品經理的時候，才會覺得自己是在做一個項目。說「產品經理也得處理一些Bug」可以讓工程師們說「OK，我需要負責那些東西嗎？」

我更喜歡「工程師來決定質量問題」的方法，工程團隊決定一個需求在質量達標的時候發布，以及決定當一個Bug出現的時候投入多少資源去解決它。工程團隊來決定處理Bug用多少開發資源，剩下的資源就用來開發新需求。

原文鏈接：quora.com/As-a-product-


推薦閱讀：
相關文章