這是我總結(jié)的一個方法論，一個驚艷或者普通的idea，是怎么變成一個可執(zhí)行的產(chǎn)品方案呢？

當(dāng)我們提到一些常見的功能時，可以一筆帶過，簡單的描述一下就可以了，比如：對于微信登錄，手機號注冊。

那如果我們提到的是一些比較復(fù)雜的，具備一定創(chuàng)造性功能的時候，又該如何呢？

比如：APP推薦分享功能，老用戶A將APP下載分享頁，分享到朋友圈，或微信好友，微博，新用戶B，C，D通過分享下載APP裝機并注冊，老用戶A獲得積分或其他獎勵。

類似問題，會成為產(chǎn)品經(jīng)理的一道分水嶺，于我們而言，不只是想一些好的東西，還要有辦法將他實現(xiàn)，這需要我們對技術(shù)有一定的基礎(chǔ)認(rèn)知。

常規(guī)的技術(shù)實現(xiàn)邏輯

幾乎所有的互聯(lián)網(wǎng)產(chǎn)品均會包含這四個環(huán)節(jié)：數(shù)據(jù)庫，后端，接口，前端。但在某些產(chǎn)品里，可能會增加環(huán)節(jié)，或者用另一個方法來代替上圖的某個節(jié)點，也可以減少一些環(huán)節(jié)。

“數(shù)據(jù)庫”的存在可以被“日志”來代替。

一款無需網(wǎng)絡(luò)支撐的“計算器”則只需要前端的功能支撐。

對于產(chǎn)品經(jīng)理而言，我們有義務(wù)將一個idea轉(zhuǎn)化成可用代碼實現(xiàn)的方案，實際上這個轉(zhuǎn)化過程正是產(chǎn)品經(jīng)理重要技能的一環(huán)。

不僅僅是想到需求，還要確保需求可被實現(xiàn)。

對于互聯(lián)網(wǎng)產(chǎn)品而言，一個idea一般都會牽扯到這4個環(huán)節(jié)，我們以登錄為例。

這是一個簡易的泳道圖，我們可以這樣來解讀這幅登錄的泳道圖：

1. 用戶在前端執(zhí)行了登錄的操作
2. 前端通過接口，將用戶輸入的帳號和密碼上傳到后端
3. 后端將這些信息與數(shù)據(jù)庫的用戶信息表進行匹配
4. 后端將匹配結(jié)果通過接口返回給前端
5. 前端根據(jù)后端返回的信息來確定下一步是成功還是失敗。

擴展

我們所說的異常保護，就是在上述的過程中，每一個環(huán)節(jié)都有可能出現(xiàn)錯誤，我們無法將所有的錯誤都進行預(yù)設(shè)，通常會將異常做分類。

沒有返回以及返回的信息，不是“對”，也不是“錯”。

所以一個登錄功能，除了我們所看得見的登錄成功，登錄失敗，還會有請求失敗，請求錯誤這兩個“功能需求”。

對于登錄這類比較常規(guī)并且固定的功能，產(chǎn)品不需要過細(xì)的思考，但在一些個性化比較強的需求處理時，我們就需要將他盡可能的貼近實現(xiàn)方案。

復(fù)雜需求

案例

APP推薦分享功能，老用戶A將APP下載分享頁，分享到朋友圈，或微信好友，微博，新用戶B，C，D通過分享下載APP裝機并注冊，老用戶A獲得積分或其他獎勵。

這個是基于分享的泳道圖，他能滿足我們分享的需求，但顯然，這不能完成案例中的復(fù)雜邏輯。我們來看看另外一副泳道圖。

這個圖補充了B用戶在微信打開被分享出來的鏈接所對應(yīng)的操作，但是這任然是不夠的。

我們再來看看案例：

老用戶A將APP下載分享頁，分享到朋友圈，或微信好友，微博，新用戶B，C，D通過分享下載APP裝機并注冊，老用戶A獲得積分或其他獎勵。

我們還有幾個問題沒解決：

• 我們?nèi)绾沃繠用戶打開的是A用戶分享出來的網(wǎng)頁呢？
• 我們怎么知道訪問的人，下載的人，注冊的人是同一個人呢？（條件是B下載裝機并注冊，A才獲得積分）

第一個問題很好解決，A用戶分享出去時，將用戶的profile信息一起傳給后端就可以記錄下，“誰分享的”。

同時，在B用戶訪問時，我們也去記錄下訪問人的信息，微信提供了這樣的支撐能力，在用戶訪問一個H5鏈接時，我們可以獲得訪問用戶的微信ipen ID，這樣就能知道誰訪問了。

走到這一步，我們已經(jīng)能夠?qū)⑦@個案例實現(xiàn)大部分了。

A用戶將下載頁分享到微信，B用戶訪問了A分享的下載頁，并做了下載動作。

第二個問題怎么辦呢？

我們怎么知道訪問的人，下載的人，注冊的人是同一個人呢？（條件是B下載裝機并注冊，A才獲得積分）

文章里已經(jīng)用了較多的泳道圖了，后面就不再貼圖啦，大家可以自己畫一畫

我們在微信環(huán)境所記錄的訪問ID ，是以微信提供的Open ID 作為唯一標(biāo)識的，第二個問題實際上是我們沒有辦法將Open ID 與用戶注冊時生成的User ID進行關(guān)聯(lián)。

我們無法知道一個新注冊的用戶，是從哪里下載的。

然后

我很喜歡一句電影臺詞：如果不是喜劇結(jié)尾，那是因為電影還未完結(jié)。

我們設(shè)計到這里，已經(jīng)能夠發(fā)現(xiàn)問題了，那就能夠找到問題的解決方案。

解決問題，產(chǎn)品經(jīng)理應(yīng)該是專業(yè)級的。

解決方案（參考）

我們要做的是將注冊ID與訪問用戶的openID進行關(guān)聯(lián)，中間欠缺一個可鏈接的橋梁。

于是，我們可以建設(shè)另一個橋梁，來起到替代作用。

我們可以在下載頁作一個活動，每次用戶訪問這個頁面時顯示一個處理后的參數(shù)，這個參數(shù)是根據(jù)計算得到的，就像微信的open ID 一樣。

訪問者ID加上分享者ID再加上一些其他的參數(shù)，生成一個新的參數(shù)，我們可以將其稱為幸運ID。

B用戶只要在注冊過程中，甚至注冊以后的正常使用過程中，輸入這個幸運ID，就能建立起這道橋梁。

于是，問題變小了。

現(xiàn)在的問題在于，如何讓用戶輸入“幸運ID”。

這個問題是不是變得簡單了？

我們只是需要尋找一個能夠讓用戶輸入“幸運ID”的動機就好啦。

比如：

• 輸入幸運ID，看看哪些朋友也在用
• 輸入幸運ID，領(lǐng)取紅包
• 輸入幸運ID，可以抽獎

結(jié)局

這并不是唯一的解決辦法，實際上很多需求都可以用不同的實現(xiàn)方法來解決。案例中的問題，我也沒有將其完全描述出來，相信還剩下許多細(xì)節(jié)問題，留給大家思考。

工作過程中，我們經(jīng)常會遇到非常棒的想法，但卻無法將他實現(xiàn)出來，研發(fā)會向我們反饋“技術(shù)無法實現(xiàn)”。

據(jù)我了解，很多時候的“技術(shù)無法實現(xiàn)”是指無法實現(xiàn)這個方案，往往，我們換一個方案就可以實現(xiàn)了。

這就需要我們具備一定的技術(shù)認(rèn)知，能夠考慮到技術(shù)如何實現(xiàn)，他的思路邏輯是怎么樣的。

案例中有一個小的細(xì)節(jié)，我們通過微信的open ID 來知道訪問者是誰，如果沒有這個open ID,那么這套方案就是“無法實現(xiàn)”的。

來看這個小故事：我們把微信的場景改變成QQ場景。

PM：我想知道有多少人在QQ訪問了我們的網(wǎng)頁

研發(fā)：這做不到，我只能幫你查查被打開了多少次，我不知道是“誰”訪問了網(wǎng)頁，因為他沒有登錄。（沒有記錄“人”，就沒辦法知道“多少人”訪問）

PM：哦 好吧。

PM：我們可以用QQ的第三方登錄嗎，這樣用戶在QQ訪問時，QQ就會把用戶的信息傳給我們。

研發(fā):這樣就沒問題了，但你需要提一個需求，以前的數(shù)據(jù)就沒辦法了，這個需求實現(xiàn)以后，就可以統(tǒng)計了。

PM：好吧我去提個需求。

新需求：用戶在QQ訪問網(wǎng)頁時，需要使用QQ提供的一鍵登錄。

#專欄作家#

枯葉，近6年經(jīng)驗的產(chǎn)品經(jīng)理，微信公眾號：枯葉咖啡館，人人都是產(chǎn)品經(jīng)理專欄作家。擅長社交，社區(qū)，細(xì)分群體挖掘。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。