TOB產品經理如何規避項目招投標帶來的困擾

0 評論 1187 瀏覽 3 收藏 7 分鐘

To B產品經理的工作可能會涉及到項目招投標的相關事務,如果經驗不足,產品經理可能就會陷入手忙腳亂的情境。那么,To B產品經理要怎么規避招投標事務所帶來的困擾?一起來看看本文的分享。

引言:相信從事過TOB領域的產品經理都經過這樣的場面:在處理日常產品需求計劃的同時,還要響應項目部或者一線部門發來的各種規格的招投標需求。并且令人最惱火的是,這些大多都是急活兒。在這種情況下,迫于市場壓力,產品經理不得不放下手中的產品工作,優先處理招投標所需的產品相關文件。筆者很榮幸,曾經在一家TOB的企業摸爬滾打了幾年,見證了日常產品工作由忙亂到規范的過程。

作為一名TOB產品經理,所涉及的產線不像TOC產品一樣,用戶覺得行就支付,不好便就放棄,也不需要簽核合同、走個招投標流程什么。但TOB產品不一樣,一般都是服務于特定行業、特定人群,涉獵金額也較大,招投標流程是免不了的。因此,TOB的產品經理在處理產品相關工作的同時,還要擔任招投標文件中產品的編寫工作,甚至有些企業的產品經理還要充當講標人的角色。

假如,您是一名剛踏足TOB領域的產品經理,筆者有以下幾點建議:

一、理解招投標流程

我們先來看一張圖,先對招投標流程做個整體的認識。一個完整的招投標流程大致分為以下幾個部分,分別是編制招標文件、發布招標公告、投標、開標、評標、確定候選人名單、公示、簽訂合同等環節。

基于我們所見的招標流程,可能一些小伙伴會認為產品經理應在投標環節開始參與,但現實情況并不是如此。大多時候在編制招標文件節點上,產品人員就開始介入技術參數的編寫工作了,這里不做過多解釋,理解萬歲。

二、產品模塊化及版本劃分

筆者建議,產品經理在設計產品之初就要做好模塊的規劃以及版本的規劃,比如基礎版、標準版、旗艦版等。只有先確保產品模塊化,才能合理的進行版本規劃和定價。因為總有一天這個工作還會落在產品經理身上。

并且,我們還需針對相應版本編寫對應的技術參數文檔和產品應標文件。在編寫技術參數和應標文件編寫環節,不能馬虎,越詳細越好,因為有時候評委也看厚度,產品應標文件多一些也是對整個投標文件的一種加持。

三、產品控標項

產品控標項是編制招標文件中非常重要的環節,其關鍵價值“我不丟分,你丟分”??貥隧棽皇桥呐哪X袋就得出的,背后是需要產品經理做大量的競品調研和需求調研得出的(如下圖),并且控標項還要做到能控標且不雞肋(如果將一個不實用的功能作為控標項,可能會來了被質疑的風險)。

與此同時,在這個環節,筆者建議:如果是新上線產品還沒有經過大量客戶的使用,不建議使用性能作為控標項,因為用戶量達不到相關數據值,自己也無法提供相應的書面證明,也容易把自己整折了。

四、產品演示腳本

在評標過程中,一般都會有產品展示環節。一般企業會將技術參數的控標項同時作為演示項。什么是演示項呢?我們可以理解為是控標項的詳細描述,就是將控標項里面的每一句話,在腳本中盡量拆解為多個步驟。并且在這個環節產品人員要充分拿捏“全部滿足得x分,否則不得分”這句話,保證“我不丟分,你丟分”。

五、做好V1和V2的輸出

參與過招投標的產品人員應該都知道,投標少于3家是不能開標的。因此,產品經理會接到一些所謂不可思議的要求,在負責當前產品招投標文件編制的同時,還要負責V1和V2的文件的需求。因此,針對V1和V2提前做好安排,免得到時慌張,因為V1和V2短時間是不好搞出來的。

綜上所講,作為一名TOB產品經理,在TOB的旅途中,可能隨時面臨一線部門或者項目部發來的響應投標的需求,只有我們提前做好產品模塊化和版本規劃。針對版本,提前編寫每個版本對應的技術參數、應標文件、產品控標項、演示腳本以及一些其他文件,才能以不變應萬變,才能從招投標事務中抽身,將精力更好的放在產品需求澄清以及產品規劃設計方向。

本文由 @王振永 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!