不管是做 2B ( to business，面向企業用戶 ) 產品還是 2C ( to customer，面向個人、普通大衆 ) 產品，在確定產品解決方案之後，都沒法保證這個解決方案是否已經被實現及市場驗證。當前最好的方式是進行市場調研或產品調研。如果當前市場上已經有這個產品了，那你就要決定是否還要繼續進入這個市場。如果當前市場上沒有這個產品，那你就要仔細分析爲什麼當前市場是沒有這個產品（是因爲沒有需求？還是很難產生商業價值），然後決定是否還要繼續進入這個市場？

我做了簡單的市場調研，當前市場上跟早報相關的產品主要集中在兩部分：

1. 專注早報格式的編輯器。如：圖怪獸等各大編輯器，可編輯精美的圖文早報，但內容要自己提供。

2. 專注內容的。如：fenng 大大的產品「Readhub」，可通過小程序訂閱每天早報，但目前還不支持定製。

目前，還沒有通過定製的方式滿足我的需求的產品。所以，爲了提高自己的效率，我決定爲自己做這個產品。

二、確定產品形態：小程序？App？公衆號？網頁端？

不管選擇哪種產品形態，首先要能滿足需求。對於「簡報生成器」來說，一個十分重要的需求是「能給不同的用戶發送不同的消息（早報）」。這個需求對產品形態的選擇起着十分重要的作用。

這個時候，我多麼想我能懂技術啊。我想這一點或許是技術背景出身的產品經理的一大優勢吧。那不懂技術怎麼辦？不要亂猜測，不要亂設計！最好找研發做個簡單的技術調研，確認不同的產品形態是否都能滿足「給不同的用戶發送不同的消息」這個需求。如果都能滿足的話，再考慮其它的點。如果只有一種形態能滿足，那想再多也沒啥用。

經過與研發的溝通與調研，以上產品形態均能能滿足需求。

那接下來該怎麼選呢？我們來簡單看看每種形態的優缺點。

在調研小程序能否滿足「給不同的用戶發送不同的消息」這一需求時？我陷入了一種思維慣性，認爲小程序是不滿足需求的。因爲小程序只能發送模版消息，也就是說每個人只能收到相同的消息，做不到不同的人收到不同的消息。但是轉念一想，模版消息不就是通知用戶早報已經生成了。

同時，我們只需要定製一個消息通知的模版消息，用戶進入小程序之後就可以查看用戶自己定製的內容了。給用戶發送模版消息通知用戶早報已經生成，就是爲了告知用戶該信息，以免用戶遺忘。不知道你有沒有因爲思維慣性而怎麼也找不到「答案」的時候呢？

綜合考慮滿足用戶需求、開發成本、用戶體驗等多種因素，我決定通過「小程序」實現。

三、功能列表，確定產品的範圍

當產品經理可以列出產品的功能列表，那麼你已經定義出了這個產品的範圍，也就是這個產品包含哪些功能特性。那「簡報生成器」這個產品的範圍層包括哪些功能列表呢？我們先看下「簡報生成器」包括哪幾部分：

灰色背景的部分（簡報佈局、簡報生成）屬於產品後端功能，用戶在使用過程中對這部分內容基本無感知～

第一部分：簡報佈局

格式包括：純文字格式和圖文格式兩種，需要預先配置在產品中以供用戶自主選擇。

優先級：低。內容本身比格式更重要。

優先級是用來描述功能（模塊）對產品的重要性，爲後續產品研發做參考。

這部分是整個產品的核心，目的是生成用戶自己的簡報。

優先級：非常高。內容的獲得是重點，也是難點。

簡報生成主要包括四大部分：

“作爲產品經理或者技術人員，很多人都想使用先進的技術、採用科學的流程做一個「高大上」的產品。比如「簡報生成」這個模塊，可以採用高大上的語義識別、機器算法精準的獲取簡報內容（標題和摘要），甚至還可以識別標題黨，重新生成符合內容的標題……但是這個天馬行空的過程忽略了最重要的一點，產品是用來幹啥的？滿足用戶需求對不？那作爲需求方的我，當前想要的產品就是採用技術所不屑的關鍵詞匹配的方式提高我自己的工作效率，我不在乎你採用什麼高大上的技術，只在乎能不能滿足我的需求。所以，很多時候我們不要陷入自己的怪圈，要時刻記住「技術是爲產品服務的，產品是爲用戶服務的」。後續產品滿足基本的用戶需求之後，可以繼續迭代、優化產品，做得更完美。而當前最主要的事情就是趕緊上線使用。”

第三部分：簡報設置

簡報設置的目的是爲了用戶設置簡報的格式以及簡報內容的自定義。

優先級：高。核心模塊。

具體包括以下內容：

第四部分：簡報展示

本部分主要用於展示簡報和查找歷史簡報。除此之外，以防簡報生成出現故障或者用戶需要預覽自己的設置，需要提供「手動生成簡報」的功能。

優先級：中。

第五部分：登錄

本部分主要用於匹配用戶信息和用戶的簡報設置。

優先級：低。

爲什麼需要登錄？

因爲需要將用戶信息和用戶設置的簡報內容相匹配。另外，因爲產品形態爲小程序，所以可以直接授權微信的用戶信息。

那可不可以不登錄？

不是所有的產品都需要登錄。如果用戶不登錄，用戶只能查看通用的簡報信息，「簡報生成器」也只是向所有用戶推送一樣的簡報內容。所以，如果只使用這些功能，那完全可以不登錄。這也就是所謂的「訪客模式」。

總結 1. 這一階段，產品經理需要輸出什麼文檔？

這一篇我們做了從產品解決方案到產品功能的工作，需要輸出「規劃的功能列表」，形式可以是思維導圖，也可以是 Excel。

🔗 我們做了需求分析的工作，需要輸出「需求可行性分析報告」，以確定這個產品能不能做。不過，大多時候沒有強制要求，平時的工作也不會寫類似的報告。

🔗 我們對用戶做了訪談，需要輸出「用戶調研報告」，並同用戶確認自己記錄的內容，以免自己錯誤的解讀或遺漏部分信息。在平常的工作中，2B 產品大多一封郵件就能解決問題，2C 產品需要做用戶訪談的原始記錄以留檔。

2. 當你找到一個解決方案時，你需要做什麼？

當前的產品解決方案，首先需要評估「使用現有技術是否可以實現？」。如果現有的技術不能實現，那你只是提出了一個理想的解決方案。在「簡報生成器」這個產品中，我們第一步在選擇產品形態時，就進行了技術調研，看現有的產品形態是否能滿足當前的需求。

其次，需要評估技術難易程度如何？如果這個技術本身很難，鮮有人懂這門技術（語言），那後續的團隊建設會遇到麻煩。

最後，還需要評估開發的時間成本如何？這裏只需簡單預估一下工作量，同時產品經理需要簡單判斷「有沒有時間做這件事？」，以決定這件事要不要開始。

3. 2B 解決方案 和 2C 解決方案需要考慮哪些方面？

如果是 2C 產品解決方案，那你需要回答以下問題：

如果是 2B 產品解決方案，那你需要搞清楚以下幾點：

給自己和團隊一個前行的方向，確定產品的邊界，雖然後續很有可能會調整。

爲技術選型、技術框架的搭建提供參考，就能避免後續提的需求被研發以「當前技術框架不支持，如果增加這個需求的話，我們需要重構 balabala…」爲理由而拒絕。

5. 定了產品的功能列表之後，要做什麼？

定義產品的 ROADMAP，也就是產品規劃。產品規劃就是說明我們怎麼一步一步實現產品功能列表的計劃。這個東西有什麼用，敬請期待下一篇。

好的，今天這篇文章到這裏就結束了，我們的《一個項目帶你走進產品經理的世界》系列文章完成進度如下：

黃色爲當前進度：

作者：左耳，微信公衆號：產品碎月

本文由 @左耳 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議

聲明：該文觀點僅代表作者本人，搜狐號系信息發佈平臺，搜狐僅提供信息存儲空間服務。