終于可以稍稍分清產品思維和開發(fā)思維了：

面對問題時：

產品：用戶為什么會有這個問題？已用戶需求為中心，滿足用戶需求，創(chuàng)造用戶需求為目標
開發(fā)：這個問題可以解決嗎？已解決問題為中心，邏輯要緊，不容有錯

在討論問題時：

產品：為什么會有這個需求？需求場景是什么？這個需求是核心需求嗎？
開發(fā)：這個需求我可以這么解決，不行這個需求有問題實現(xiàn)不了，這里需要這個數(shù)據嗎？這里邏輯有漏洞，這樣做肯定會有問題的

最終結果：

開發(fā)：很有可能會把問題弄的越來越復雜
產品：讓問題越來越清晰，解決起來越來越簡單，最后把問題變的不是問題

談談各種模式：

需求 -> 開發(fā) -> 交付
業(yè)務/用戶提需求 -> 開發(fā)解決問題  -> 提交成果


需求 -> 開發(fā) -> 產品 -> 開發(fā)  -> 交付
業(yè)務/用戶提需求 -> 開發(fā)解決問題 -> 解決不了問題了阿，需要產品幫忙搞一高 -> 繼續(xù)開發(fā)  -> 提交成果

做出來的東西用戶覺得不是他們想要的
可是開發(fā)覺得就是按你們的需求做出來的啊
開發(fā)途中遇到各種困難，還不容易解決了，你們說不滿意就不滿意，搞啥子呀？

用戶覺得這樣做不能解決問題
怎么這里有問題？為什么那里又不行？需求怎么又變了（不是需求變了，是開發(fā)根本不知道需求是什么）

用戶提出新需求
不就這樣嘛，1->2->3->4就解決啦，搞一搞就搞啦（通常搞一搞就搞出很多問題了）

需求 -> 產品 -> 設計 -> 開發(fā) -> 交付
業(yè)務/用戶提需求 -> 產品對需求進行分析 -> 需求不清晰再次和業(yè)務確認
產品明確需求 -> 設計師參與進行設計 -> 業(yè)務/用戶確認這樣的設計是他們想要的
產品告訴開發(fā)，我們想要做這樣一個東西出來，可以做的出來嗎？-> 做不出來想想有沒有其他方案
可以實現(xiàn) -> 開發(fā)實現(xiàn) -> 業(yè)務/用戶對成果確認

做出來的東西，是可以解決用戶的問題的

用戶提前預知做出來的東西原來是長這模樣的

用戶體驗產品，確認真的可以解決問題