不管是做?2B 產品，還是?2C 產品，在確定產品解決方案之后，都沒法保證這個解決方案是否已經被實現及市場驗證，最好的方法是先進行市場調研或產品調研。

上一篇???我們已經對「簡報生成器」這個產品做了初步的需求分析，并且已經明確我們有比現有解決方案更好的方案。

一、To?be?or?not?to?be?？

首先我們來簡單回顧總結下我們提出的解決方案：按照用戶預先設置的規則定時爬取各大新聞網站的新聞標題及摘要，然后將新聞標題歸類整理在既定的早報格式中，然后將最終版的早報發送給用戶。

產品解決方案已經確定了，那我們就可以開始做產品了么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第一部分：簡報布局

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

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

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

第二部分：簡報生成

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

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

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

1. 內容獲?。盒枰鶕脩粼O置的信息源和類型、內容限制規則等爬取內容；
2. 內容緩存：為了提高效率和解決并發問題，需要有合適的緩存策略。因為用戶對簡報生成時間的要求相對比較集中，早上?8：00?–?9：00?會是一個高峰，如果沒有合適的緩存策略，如果用戶量較大，輕者會導致簡報生成時間延遲，重者會導致產品宕機；
3. 內容整理：內容需要去重，以及需要按照類型整理內容；
4. 內容生成：按照固定的格式生成簡報；
5. 內容發送：包括主動發送簡報和被動發送簡報兩種。

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

第三部分：簡報設置

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

優先級：高。核心模塊。

具體包括以下內容：

• 簡報名稱：可支持用戶自定義多個早報。
• 格式：可選擇「第一部分：格式設置」內的格式。
• 信息源：設置自己的簡報信息源，具體表現形式為添加網址。不過考慮到各種安全因素和減少惡意添加網址的可能性，第一版會提供固定的信息源供用戶選擇，后續可以通過用戶反饋添加信息源。
• 類型：設置自己的簡報類型，比如「科技」、「創投」板塊，可通過關鍵詞匹配實現，具體表現形式為添加類型名和添加對應的關鍵詞。
• 內容：設置簡報的內容范圍和內容限制，比如取什么時間范圍內的內容，簡報內容的數量限制等等。第一版會以滿足我自己當前的需求為主，通過簡單的關鍵詞匹配查找和爬取內容。后續為了讓更多的用戶使用，會增加多種規則設置完善簡報內容。
• 自定義生成時間：設置早報的發送頻率和發送時間。

第四部分：簡報展示

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

優先級：中。

第五部分：登錄

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

優先級：低。

為什么需要登錄？

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

那可不可以不登錄？

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

總結

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

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

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

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

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

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

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

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

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

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

• 這個解決方案解決了什么問題？這個問題是真實存在的嗎？這個問題還有沒有其它的解決方案，各有什么利弊？
• 市場上有沒有這個解決方案？沒有的話，為什么沒有？有的話，你和現有的解決方案有什么異同？

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

• 這個解決方案的目的是什么？為了賺錢？為了支撐業務發展？
• 老板會不會同意你做這件事？為什么會？為什么不會？
• 老板是怎么考慮這個問題的？老板的關注點在哪里？

4. 產品的功能列表有什么用？

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

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

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

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

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

黃色為當前進度：

相關閱讀

一個項目帶你走進產品經理的世界（1）：從收到一個需求談起

一個項目帶你走進產品經理的世界（2）：需求分析

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

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

題圖來自Unsplash，基于CC0協議