起點(diǎn)課堂會(huì)員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會(huì)特權(quán)
個(gè)人IP打造特權(quán)
30+門專項(xiàng)技能課
1300+專題課程
12場(chǎng)職場(chǎng)軟技能直播
12場(chǎng)求職輔導(dǎo)直播
12場(chǎng)專業(yè)技能直播
會(huì)員專屬社群
榮耀標(biāo)識(shí) 產(chǎn)品新人第一次獨(dú)立負(fù)責(zé)新功能的上線，如何才能hold?。?/h2>
之前在一篇文章中看到說互聯(lián)網(wǎng)公司給實(shí)習(xí)生做的是比較不費(fèi)腦或繁瑣的工作，競(jìng)品分析和收集用戶反饋已經(jīng)算高級(jí)的了。如果這種觀點(diǎn)成立的話，那我做的事情應(yīng)該算是略高級(jí)的了，我一般都是進(jìn)行競(jìng)品分析、收集用戶反饋，并且給出方案，能被評(píng)審?fù)ㄟ^的方案就采納執(zhí)行。
前幾天和部門的產(chǎn)品leader一起吃飯，談?wù)摿瞬簧佼a(chǎn)品相關(guān)的話題。他說我對(duì)產(chǎn)品的理解是比較到位的，理論知識(shí)也比較扎實(shí)，但是缺少項(xiàng)目實(shí)踐經(jīng)驗(yàn)，說回去讓我自己自己考慮一個(gè)方案，并且自己負(fù)責(zé)跟進(jìn)方案的落實(shí)。于是我這個(gè)產(chǎn)品新人便有機(jī)會(huì)自己負(fù)責(zé)一個(gè)小的功能的上線全流程，功能上線后還是很有成就感的，也反思總結(jié)了下功能從0到1的全流程，望各位前輩不要見笑。
一.需求調(diào)研
需求的來源一般有產(chǎn)品本身、數(shù)據(jù)分析、競(jìng)品、用戶反饋、PM自發(fā)、來自BOSS這幾類，但并不是說所有的需求都要進(jìn)行滿足，首先應(yīng)該去分析辨別是真的需求還是只是偽需求，是否為剛需，需求頻次如何，需求的用戶基數(shù)有多大。然后也需要結(jié)合產(chǎn)品的定位，公司的資源，開發(fā)實(shí)現(xiàn)的難易程度，優(yōu)先級(jí)，性價(jià)比去將合理的需求轉(zhuǎn)化為產(chǎn)品需求。
我們這個(gè)產(chǎn)品的需求來源于用戶反饋，通過用戶反饋的數(shù)據(jù)發(fā)現(xiàn)確實(shí)是有此需求，并且根據(jù)數(shù)據(jù)來看需求的人數(shù)較多。于是我便又去調(diào)研了幾個(gè)直接競(jìng)品(與我們產(chǎn)品的業(yè)務(wù)模式重疊性較大，目標(biāo)用戶相同)的處理方式，根據(jù)分析調(diào)研后的數(shù)據(jù)得出這個(gè)需求應(yīng)該需要滿足的結(jié)論，于是我針對(duì)兩種典型的用戶采用了兩種不同的處理方案，考慮到類型二用戶的特殊性，我又將類型二的用戶細(xì)分為兩種方案（暫定為方案a與方案b），方案初步定下來之后我便去找mentor初步評(píng)審去了。
二．產(chǎn)品評(píng)審
方案評(píng)審前一定要自己想清楚方案的細(xì)節(jié)，以及作出此方案決定的緣由，最好是有數(shù)據(jù)支撐或者其他支持。切勿拍腦袋下定論，這樣評(píng)審的時(shí)候會(huì)死的很難看，別問我怎么知道的。還有在定方案的時(shí)候如果牽扯到技術(shù)的問題，請(qǐng)?zhí)崆罢壹夹g(shù)確認(rèn)，提前找技術(shù)確認(rèn)，提前找技術(shù)確認(rèn)，不要等方案定下來之后，然后技術(shù)說實(shí)現(xiàn)不了。Mentor說理論上來講一般的需求都是能夠?qū)崿F(xiàn)的，只是實(shí)現(xiàn)成本大小的問題，當(dāng)然還有和技術(shù)的熟識(shí)程度。不停的請(qǐng)吃飯、請(qǐng)吃飯、請(qǐng)吃飯，陪加班、陪加班、陪加班就能快速和技術(shù)們打成一片了……
方案一初審就通過了，沒有什么問題，Mentor關(guān)于方案二的兩種情況細(xì)致的問了幾個(gè)問題，便問我為什么不采用另外的一種處理方式，我說考慮到可能需要對(duì)接API的問題，然后Mentor說這個(gè)不需要對(duì)接API，碰到這樣的技術(shù)問題你應(yīng)該去找技術(shù)確認(rèn)。我說知道了，便回去重新修改了一下方案二中的兩個(gè)方案。Mentor確認(rèn)之后讓我就方案二中的a方案和b方案去找技術(shù)評(píng)審確認(rèn)下采用哪種方案。
三．技術(shù)評(píng)審
最開始我是在RTX和技術(shù)Leader溝通的，Mentor問我打算什么時(shí)候和技術(shù)溝通的時(shí)候，我說正在溝通啊，然后Mentor告訴我這種復(fù)雜的問題應(yīng)該是提前和技術(shù)預(yù)約好時(shí)間段，進(jìn)行當(dāng)面溝通，在評(píng)審前做好準(zhǔn)備工作，盡可能的將需要問到的問題提前列舉出來，提升溝通的效率，在溝通完成之后需要就會(huì)議內(nèi)容進(jìn)行整理總結(jié)。
于是我在整理好方案，并做好準(zhǔn)備工作之后便提前和技術(shù)Leader預(yù)約了個(gè)時(shí)間點(diǎn)，我把需求和方案拿給他的時(shí)候，他說:“方案一沒什么問題，方案二需要改動(dòng)的東西太多，實(shí)現(xiàn)不了”。我的內(nèi)心幾乎是崩潰的，于是我就和他說需求已經(jīng)定下來了，一定需要做。技術(shù)Leader確認(rèn)后問到“已經(jīng)確定要做了是吧？”我說“是的?！?/p>
然后我們就方案a和方案b進(jìn)行了討論，技術(shù)Leader問了好多邊界問題，有的我考慮到了，有的邊界問題我根本沒有想到。雖然我被虐的慘無人道，還是要說技術(shù)的思維嚴(yán)謹(jǐn)程度真是太贊了。最后得出的結(jié)論是方案a要優(yōu)于方案b，但是…還是采用方案b吧。我問技術(shù)Leader“以后應(yīng)該還是要使用方案a的啊”，技術(shù)Leader說“方案a是比較合理的，估計(jì)以后也會(huì)使用方案a的。但是方案a需要改動(dòng)的東西太多了，就先采用方案b吧?！蔽艺f“那以后需要用到方案a的時(shí)候怎么辦？”技術(shù)Leader說“那到時(shí)候再改吧?！蔽?#8230;…
然后就決定采用方案b了，后來我默默地去問技術(shù)的同事“你們是不是通常都是這么處理？”技術(shù)說“對(duì)啊對(duì)啊，都是哪種實(shí)現(xiàn)方式最容易，改動(dòng)最小就使用哪種方式?！蔽艺f“那就是不停的改改改么？”得到技術(shù)肯定的回答之后，我就問“那以后牽扯到很大的改動(dòng)的時(shí)候豈不是就要整個(gè)架構(gòu)重構(gòu)了？”他沉默了……
四．產(chǎn)出原型圖
對(duì)于已經(jīng)確定的方案，可以在產(chǎn)出原型圖的時(shí)候把一部分的工作就交由技術(shù)開始并發(fā)執(zhí)行，比如需要接口啊，技術(shù)需要看一下之前的代碼啊，先考慮采用哪種實(shí)現(xiàn)方式，出現(xiàn)問題及時(shí)溝通，不要等到所有的方案都定下來之后才去找技術(shù)人員。
在產(chǎn)出原型的時(shí)候需要將邊界問題、默認(rèn)值、極限值這些東西想清楚，確定用戶的主要使用流程、支線流程、異常流程，以及異常情況的處理方式，提示語、操作反饋等。同時(shí)還應(yīng)該注意操作的前置條件，是否涉及賬號(hào)、權(quán)限問題，在操作成功之后的情況又是什么樣子的，有無進(jìn)行數(shù)據(jù)上報(bào)的需要，這些都是需要自己想清楚的。這里面有很多坑雖然自己現(xiàn)在并不能夠都考慮到，但是也會(huì)盡可能的去考慮的全面一點(diǎn)。
五．勾搭UI
Mentor要求功能要在四天之內(nèi)上線，留兩天的時(shí)間給技術(shù)人員進(jìn)行開發(fā)，所以在進(jìn)行項(xiàng)目之前，我繪制了一個(gè)小型的甘特圖，方便自己跟進(jìn)項(xiàng)目，后來發(fā)現(xiàn)那只是理想的狀況，事實(shí)是遇到了很多問題。方案推倒重來花了半天，技術(shù)Leader根本沒時(shí)間，約個(gè)時(shí)間評(píng)審就等了兩個(gè)多小時(shí)，導(dǎo)致最后視覺稿只能延遲到第三天。然后快下班的時(shí)候驚悉UI妹紙明天請(qǐng)假了，所以我就在臨近下班的最后去找的UI幫忙產(chǎn)出視覺稿。
在UI妹紙很是嫌棄的目光中，我把線框圖交給她了，UI妹紙很是幽怨的說道“哪有你這樣的啊，快下班了才來提需求的，??？”我說“本來是打算明天請(qǐng)你出視覺稿的，不是剛剛才知道你明天不上班么?！边€好之前部門聚餐的時(shí)候發(fā)現(xiàn)UI妹紙是屬于典型的吃貨，就說回頭請(qǐng)她吃飯，UI妹紙立刻兩眼放光的回道“好啊好啊”，于是有驚無險(xiǎn)的產(chǎn)出了視覺稿。產(chǎn)出視覺稿之后，我又將方案完善了一下，然后去找技術(shù)Leader預(yù)約資源，技術(shù)Leader給我分配了個(gè)技術(shù)人員，準(zhǔn)備第二天開發(fā)。
六．研發(fā)測(cè)試
研發(fā)并沒有什么問題，整個(gè)流程中技術(shù)就和我確認(rèn)了幾個(gè)具體的問題，其他都正常進(jìn)行，技術(shù)花了接近兩天的時(shí)間實(shí)現(xiàn)了功能。功能研發(fā)完成之后，就發(fā)到測(cè)試環(huán)境了，我測(cè)試了兩個(gè)小時(shí)之后發(fā)現(xiàn)沒有什么問題，就讓技術(shù)把新功能上線了。
雖然說只是上線一個(gè)小功能，但也算是自己第一次獨(dú)立負(fù)責(zé)的一個(gè)功能的全流程，功能上線之后還是感覺略有成就感的，感謝隊(duì)友們，雖然目前我可能還會(huì)有點(diǎn)坑，但是我也會(huì)繼續(xù)努力快速成長(zhǎng)的。
回過頭來總結(jié)一下這個(gè)功能上線的全過程，順便也將自己踩過的坑和經(jīng)驗(yàn)心得匯總一下，希望能夠幫助到像我一樣的新人。
心得之一：一定要采用技術(shù)和UI常用的方式進(jìn)行交流，用他們的語言說話；
心得之二：下結(jié)論的時(shí)候一定要想清楚，有哪些論據(jù)可以支撐你的結(jié)論；
心得之三：說服別人時(shí)用調(diào)研得到的數(shù)據(jù)說話，爭(zhēng)取做到有理有據(jù)，事實(shí)說話，不要摻雜過多的主觀因素；
心得之四：自信，做完了相關(guān)的準(zhǔn)備工作之后，說話一定要有自信，如果說你自己都不能相信你自己的Idea,你怎么能夠去把你的Idea推銷給別人呢？
心得之五：討論之前先界定問題的邊界，確定你們討論的是同一個(gè)話題，定義的是同一個(gè)內(nèi)容。Mentor關(guān)于某一個(gè)問題在RTX上和我討論了近5分鐘，他一直捉急我沒有g(shù)et到他要表達(dá)的點(diǎn)，我一直捉急我本就就是使用他說的那種方式，沒有改動(dòng)的必要。后來我們面談的時(shí)候，我才發(fā)現(xiàn)他錯(cuò)把我們產(chǎn)品正在使用的樣式當(dāng)成了我的Demo。
心得之六：可并行執(zhí)行的事項(xiàng)就并行執(zhí)行，由于時(shí)間有限，所以需要提前合理的安排好，將能夠同時(shí)進(jìn)行的工作同時(shí)展開。
心得之七：優(yōu)先級(jí)，做事一定要分優(yōu)先級(jí)，可按照重要程度與緊急程度來進(jìn)行劃分，先做重要緊急的事，最后做不重要不緊急的事情。先做重要的事情，酌情處理緊急的事情，不然很可能會(huì)一直疲于奔命于緊急不重要的事情。
心得之八：性價(jià)比，做事需要考慮投入產(chǎn)出比，優(yōu)先做性價(jià)比高的事情，減少做性價(jià)比不高的事情，甚至根本就不去做性價(jià)比低的事情。
以上就是產(chǎn)品新人第一次負(fù)責(zé)一個(gè)新功能上線的全部流程，希望能夠?qū)δ阌心呐乱稽c(diǎn)點(diǎn)的幫助，也希望廣大前輩們不要見笑，人艱不拆啦……
關(guān)于我：起點(diǎn)學(xué)員王家郴，公眾號(hào)（產(chǎn)品經(jīng)理從0到1），每周都會(huì)在公眾號(hào)上寫點(diǎn)東西，歡迎關(guān)注,求指教、求分享、求交流。目前是大四黨、產(chǎn)品經(jīng)理實(shí)習(xí)生，奔走在產(chǎn)品的道路上，漫漫產(chǎn)品路，與君共勉。
本文系起點(diǎn)學(xué)院廣州1509期優(yōu)秀學(xué)員@王家郴 原創(chuàng)發(fā)布，未經(jīng)作者許可，禁止轉(zhuǎn)載。
更多精彩內(nèi)容，請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
之前在一篇文章中看到說互聯(lián)網(wǎng)公司給實(shí)習(xí)生做的是比較不費(fèi)腦或繁瑣的工作，競(jìng)品分析和收集用戶反饋已經(jīng)算高級(jí)的了。如果這種觀點(diǎn)成立的話，那我做的事情應(yīng)該算是略高級(jí)的了，我一般都是進(jìn)行競(jìng)品分析、收集用戶反饋，并且給出方案，能被評(píng)審?fù)ㄟ^的方案就采納執(zhí)行。
前幾天和部門的產(chǎn)品leader一起吃飯，談?wù)摿瞬簧佼a(chǎn)品相關(guān)的話題。他說我對(duì)產(chǎn)品的理解是比較到位的，理論知識(shí)也比較扎實(shí)，但是缺少項(xiàng)目實(shí)踐經(jīng)驗(yàn)，說回去讓我自己自己考慮一個(gè)方案，并且自己負(fù)責(zé)跟進(jìn)方案的落實(shí)。于是我這個(gè)產(chǎn)品新人便有機(jī)會(huì)自己負(fù)責(zé)一個(gè)小的功能的上線全流程，功能上線后還是很有成就感的，也反思總結(jié)了下功能從0到1的全流程，望各位前輩不要見笑。
一.需求調(diào)研
需求的來源一般有產(chǎn)品本身、數(shù)據(jù)分析、競(jìng)品、用戶反饋、PM自發(fā)、來自BOSS這幾類，但并不是說所有的需求都要進(jìn)行滿足，首先應(yīng)該去分析辨別是真的需求還是只是偽需求，是否為剛需，需求頻次如何，需求的用戶基數(shù)有多大。然后也需要結(jié)合產(chǎn)品的定位，公司的資源，開發(fā)實(shí)現(xiàn)的難易程度，優(yōu)先級(jí)，性價(jià)比去將合理的需求轉(zhuǎn)化為產(chǎn)品需求。
我們這個(gè)產(chǎn)品的需求來源于用戶反饋，通過用戶反饋的數(shù)據(jù)發(fā)現(xiàn)確實(shí)是有此需求，并且根據(jù)數(shù)據(jù)來看需求的人數(shù)較多。于是我便又去調(diào)研了幾個(gè)直接競(jìng)品(與我們產(chǎn)品的業(yè)務(wù)模式重疊性較大，目標(biāo)用戶相同)的處理方式，根據(jù)分析調(diào)研后的數(shù)據(jù)得出這個(gè)需求應(yīng)該需要滿足的結(jié)論，于是我針對(duì)兩種典型的用戶采用了兩種不同的處理方案，考慮到類型二用戶的特殊性，我又將類型二的用戶細(xì)分為兩種方案（暫定為方案a與方案b），方案初步定下來之后我便去找mentor初步評(píng)審去了。
二．產(chǎn)品評(píng)審
方案評(píng)審前一定要自己想清楚方案的細(xì)節(jié)，以及作出此方案決定的緣由，最好是有數(shù)據(jù)支撐或者其他支持。切勿拍腦袋下定論，這樣評(píng)審的時(shí)候會(huì)死的很難看，別問我怎么知道的。還有在定方案的時(shí)候如果牽扯到技術(shù)的問題，請(qǐng)?zhí)崆罢壹夹g(shù)確認(rèn)，提前找技術(shù)確認(rèn)，提前找技術(shù)確認(rèn)，不要等方案定下來之后，然后技術(shù)說實(shí)現(xiàn)不了。Mentor說理論上來講一般的需求都是能夠?qū)崿F(xiàn)的，只是實(shí)現(xiàn)成本大小的問題，當(dāng)然還有和技術(shù)的熟識(shí)程度。不停的請(qǐng)吃飯、請(qǐng)吃飯、請(qǐng)吃飯，陪加班、陪加班、陪加班就能快速和技術(shù)們打成一片了……
方案一初審就通過了，沒有什么問題，Mentor關(guān)于方案二的兩種情況細(xì)致的問了幾個(gè)問題，便問我為什么不采用另外的一種處理方式，我說考慮到可能需要對(duì)接API的問題，然后Mentor說這個(gè)不需要對(duì)接API，碰到這樣的技術(shù)問題你應(yīng)該去找技術(shù)確認(rèn)。我說知道了，便回去重新修改了一下方案二中的兩個(gè)方案。Mentor確認(rèn)之后讓我就方案二中的a方案和b方案去找技術(shù)評(píng)審確認(rèn)下采用哪種方案。
三．技術(shù)評(píng)審
最開始我是在RTX和技術(shù)Leader溝通的，Mentor問我打算什么時(shí)候和技術(shù)溝通的時(shí)候，我說正在溝通啊，然后Mentor告訴我這種復(fù)雜的問題應(yīng)該是提前和技術(shù)預(yù)約好時(shí)間段，進(jìn)行當(dāng)面溝通，在評(píng)審前做好準(zhǔn)備工作，盡可能的將需要問到的問題提前列舉出來，提升溝通的效率，在溝通完成之后需要就會(huì)議內(nèi)容進(jìn)行整理總結(jié)。
于是我在整理好方案，并做好準(zhǔn)備工作之后便提前和技術(shù)Leader預(yù)約了個(gè)時(shí)間點(diǎn)，我把需求和方案拿給他的時(shí)候，他說:“方案一沒什么問題，方案二需要改動(dòng)的東西太多，實(shí)現(xiàn)不了”。我的內(nèi)心幾乎是崩潰的，于是我就和他說需求已經(jīng)定下來了，一定需要做。技術(shù)Leader確認(rèn)后問到“已經(jīng)確定要做了是吧？”我說“是的?！?/p>
然后我們就方案a和方案b進(jìn)行了討論，技術(shù)Leader問了好多邊界問題，有的我考慮到了，有的邊界問題我根本沒有想到。雖然我被虐的慘無人道，還是要說技術(shù)的思維嚴(yán)謹(jǐn)程度真是太贊了。最后得出的結(jié)論是方案a要優(yōu)于方案b，但是…還是采用方案b吧。我問技術(shù)Leader“以后應(yīng)該還是要使用方案a的啊”，技術(shù)Leader說“方案a是比較合理的，估計(jì)以后也會(huì)使用方案a的。但是方案a需要改動(dòng)的東西太多了，就先采用方案b吧?！蔽艺f“那以后需要用到方案a的時(shí)候怎么辦？”技術(shù)Leader說“那到時(shí)候再改吧?！蔽?#8230;…
然后就決定采用方案b了，后來我默默地去問技術(shù)的同事“你們是不是通常都是這么處理？”技術(shù)說“對(duì)啊對(duì)啊，都是哪種實(shí)現(xiàn)方式最容易，改動(dòng)最小就使用哪種方式?！蔽艺f“那就是不停的改改改么？”得到技術(shù)肯定的回答之后，我就問“那以后牽扯到很大的改動(dòng)的時(shí)候豈不是就要整個(gè)架構(gòu)重構(gòu)了？”他沉默了……
四．產(chǎn)出原型圖
對(duì)于已經(jīng)確定的方案，可以在產(chǎn)出原型圖的時(shí)候把一部分的工作就交由技術(shù)開始并發(fā)執(zhí)行，比如需要接口啊，技術(shù)需要看一下之前的代碼啊，先考慮采用哪種實(shí)現(xiàn)方式，出現(xiàn)問題及時(shí)溝通，不要等到所有的方案都定下來之后才去找技術(shù)人員。
在產(chǎn)出原型的時(shí)候需要將邊界問題、默認(rèn)值、極限值這些東西想清楚，確定用戶的主要使用流程、支線流程、異常流程，以及異常情況的處理方式，提示語、操作反饋等。同時(shí)還應(yīng)該注意操作的前置條件，是否涉及賬號(hào)、權(quán)限問題，在操作成功之后的情況又是什么樣子的，有無進(jìn)行數(shù)據(jù)上報(bào)的需要，這些都是需要自己想清楚的。這里面有很多坑雖然自己現(xiàn)在并不能夠都考慮到，但是也會(huì)盡可能的去考慮的全面一點(diǎn)。
五．勾搭UI
Mentor要求功能要在四天之內(nèi)上線，留兩天的時(shí)間給技術(shù)人員進(jìn)行開發(fā)，所以在進(jìn)行項(xiàng)目之前，我繪制了一個(gè)小型的甘特圖，方便自己跟進(jìn)項(xiàng)目，后來發(fā)現(xiàn)那只是理想的狀況，事實(shí)是遇到了很多問題。方案推倒重來花了半天，技術(shù)Leader根本沒時(shí)間，約個(gè)時(shí)間評(píng)審就等了兩個(gè)多小時(shí)，導(dǎo)致最后視覺稿只能延遲到第三天。然后快下班的時(shí)候驚悉UI妹紙明天請(qǐng)假了，所以我就在臨近下班的最后去找的UI幫忙產(chǎn)出視覺稿。
在UI妹紙很是嫌棄的目光中，我把線框圖交給她了，UI妹紙很是幽怨的說道“哪有你這樣的啊，快下班了才來提需求的，??？”我說“本來是打算明天請(qǐng)你出視覺稿的，不是剛剛才知道你明天不上班么?！边€好之前部門聚餐的時(shí)候發(fā)現(xiàn)UI妹紙是屬于典型的吃貨，就說回頭請(qǐng)她吃飯，UI妹紙立刻兩眼放光的回道“好啊好啊”，于是有驚無險(xiǎn)的產(chǎn)出了視覺稿。產(chǎn)出視覺稿之后，我又將方案完善了一下，然后去找技術(shù)Leader預(yù)約資源，技術(shù)Leader給我分配了個(gè)技術(shù)人員，準(zhǔn)備第二天開發(fā)。
六．研發(fā)測(cè)試
研發(fā)并沒有什么問題，整個(gè)流程中技術(shù)就和我確認(rèn)了幾個(gè)具體的問題，其他都正常進(jìn)行，技術(shù)花了接近兩天的時(shí)間實(shí)現(xiàn)了功能。功能研發(fā)完成之后，就發(fā)到測(cè)試環(huán)境了，我測(cè)試了兩個(gè)小時(shí)之后發(fā)現(xiàn)沒有什么問題，就讓技術(shù)把新功能上線了。
雖然說只是上線一個(gè)小功能，但也算是自己第一次獨(dú)立負(fù)責(zé)的一個(gè)功能的全流程，功能上線之后還是感覺略有成就感的，感謝隊(duì)友們，雖然目前我可能還會(huì)有點(diǎn)坑，但是我也會(huì)繼續(xù)努力快速成長(zhǎng)的。
回過頭來總結(jié)一下這個(gè)功能上線的全過程，順便也將自己踩過的坑和經(jīng)驗(yàn)心得匯總一下，希望能夠幫助到像我一樣的新人。
心得之一：一定要采用技術(shù)和UI常用的方式進(jìn)行交流，用他們的語言說話；
心得之二：下結(jié)論的時(shí)候一定要想清楚，有哪些論據(jù)可以支撐你的結(jié)論；
心得之三：說服別人時(shí)用調(diào)研得到的數(shù)據(jù)說話，爭(zhēng)取做到有理有據(jù)，事實(shí)說話，不要摻雜過多的主觀因素；
心得之四：自信，做完了相關(guān)的準(zhǔn)備工作之后，說話一定要有自信，如果說你自己都不能相信你自己的Idea,你怎么能夠去把你的Idea推銷給別人呢？
心得之五：討論之前先界定問題的邊界，確定你們討論的是同一個(gè)話題，定義的是同一個(gè)內(nèi)容。Mentor關(guān)于某一個(gè)問題在RTX上和我討論了近5分鐘，他一直捉急我沒有g(shù)et到他要表達(dá)的點(diǎn)，我一直捉急我本就就是使用他說的那種方式，沒有改動(dòng)的必要。后來我們面談的時(shí)候，我才發(fā)現(xiàn)他錯(cuò)把我們產(chǎn)品正在使用的樣式當(dāng)成了我的Demo。
心得之六：可并行執(zhí)行的事項(xiàng)就并行執(zhí)行，由于時(shí)間有限，所以需要提前合理的安排好，將能夠同時(shí)進(jìn)行的工作同時(shí)展開。
心得之七：優(yōu)先級(jí)，做事一定要分優(yōu)先級(jí)，可按照重要程度與緊急程度來進(jìn)行劃分，先做重要緊急的事，最后做不重要不緊急的事情。先做重要的事情，酌情處理緊急的事情，不然很可能會(huì)一直疲于奔命于緊急不重要的事情。
心得之八：性價(jià)比，做事需要考慮投入產(chǎn)出比，優(yōu)先做性價(jià)比高的事情，減少做性價(jià)比不高的事情，甚至根本就不去做性價(jià)比低的事情。
以上就是產(chǎn)品新人第一次負(fù)責(zé)一個(gè)新功能上線的全部流程，希望能夠?qū)δ阌心呐乱稽c(diǎn)點(diǎn)的幫助，也希望廣大前輩們不要見笑，人艱不拆啦……
關(guān)于我：起點(diǎn)學(xué)員王家郴，公眾號(hào)（產(chǎn)品經(jīng)理從0到1），每周都會(huì)在公眾號(hào)上寫點(diǎn)東西，歡迎關(guān)注,求指教、求分享、求交流。目前是大四黨、產(chǎn)品經(jīng)理實(shí)習(xí)生，奔走在產(chǎn)品的道路上，漫漫產(chǎn)品路，與君共勉。
本文系起點(diǎn)學(xué)院廣州1509期優(yōu)秀學(xué)員@王家郴 原創(chuàng)發(fā)布，未經(jīng)作者許可，禁止轉(zhuǎn)載。
想知道怎么提升對(duì)產(chǎn)品的理解
感謝作者大大的分享，讀到這篇文章的您，
如果想具備系統(tǒng)產(chǎn)品知識(shí)技能，
有一套體系化的個(gè)人項(xiàng)目作品，
想工作和求職，都更加的順暢！
那體系化的學(xué)習(xí)訓(xùn)練就很有必要，
點(diǎn)這里，先看看公開課： http://996.pm/7GVQ4
寫的好好，現(xiàn)在看你文章的我是一名準(zhǔn)大四黨。大三結(jié)束就趕緊找了一份產(chǎn)品實(shí)習(xí)生，但是感覺我的理解能力遠(yuǎn)遠(yuǎn)不行。感覺你寫的很好。