首先，我是一個程式設計師(2年菜鳥)。也就是說不是做產品的，在開發過程中避免不了和產品經理進行討(si)論(bi)。於是經常被這樣“你沒有站在使用者的角度去思考”或者這樣“你不能跳出你自己的特定使用者去思考”總之各種理由反駁地只能默默地擼程式碼。為了能夠更加地提高使用者體驗，擁抱使用者，增加團隊凝聚力·············(裝逼的話就不多說了)，我於是開始學習產品思維，也同事寫下自己的學習過程，希望對一些同學有一定的幫助。
我們公司原來只做一個產品，在稍大的公司算一個產品線吧。公司的組織架構也比較完整，技術，運營，產品等部門架構齊全（老闆牛逼）。
所以整體而言，就有：
1.BD(Business Development 商務拓展)&PM(Project Manager 專案經理)做使用者調研,收集使用者需求，然後對使用者需求進行分析，然後整理成需要做的功能。
2.寫PRD交付給我們(開發)，和開發一起進行討論邏輯，評審工作量。
3.開發人員進行開發，測試（一般兩週一個迭代），然後交付給PM稽核
4.如有bug進行修補，最後一切OK，上線。下面繼續。
這幾步只是大體的概括下，真正執行的時候要細緻很多。包括各個時間節點，產品和開發的協作，流程管理等。（下圖借鑑人人都是產品經理）

以上就是團隊的大體情況。下面記錄下我的學習認知（先看的人人都是產品經理，對我這種菜鳥還是有概念的指導作用的。）
首先是產品的概念，產品就是用來解決某個問題的東西。
比如我們做的APP就是這個東西，解決的問題是為了滿足家長想安排孩子課外時間但資源不足的需求。如果只滿足使用者的需求，對使用者產生價值，而對公司不能產生價值，那麼這個產品也活不長。（雖然現在一般是拿投資人的錢去運作，但是如果沒有使用者量，即使有使用者量但不能轉化帶來利益，一樣堅持不了多久。這樣的例子太多了，死在沒有使用者量的居多，有使用者量但是沒有轉化率帶來收入的也是投資人苦惱，如墨跡天氣和今日頭條）。
所以好的產品不能要解決使用者的需求，消除使用者的痛點，為使用者產生價值同時還要能夠為公司引流，具有相對成熟的商業模式，能夠為公司創造價值。
在這裡順便記錄下專案和產品的異同。舉個例子，一家公司找你們公司定製一套軟體，時間為半年，那麼這就可以說是在做一個專案。我們面對的是付錢的客戶，而不是直接面對軟體的終端使用者。如果我們做一個東西直接面向市場，然後根據市場的反饋進行不斷的修改，這就是在做一個產品。主要不同：1.生命週期 2.軟體的直接面對人群
當然，專案都有個性化，我們儘可能把專案產品化，把相似的功能能夠做的通用，提高開發效率，也能夠更好地對功能進行打磨。