中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文作者嘗試按照不同方面來列列看，到底有哪些事情是產品經理認為同樣很重要，但是可能其他人不這么認為的”小事兒”。

今天在知乎里看到一個問題：

作為一個產品經理或產品負責人可能會忽視哪些實際上很重要的小事？

覺得這個問題很有意思，所以，這篇文章就根據我的角度來嘗試回答一下這個問題。

題目既然說的是小事，那么我就不說產品經理最重要的一些事情，例如：

• 我個人認為的最重要的四個素質：溝通能力、業務能力、理性思維、邏輯思維；
• 產品經理基本工作內容的落地執行；
• ……

我們就嘗試按照不同方面來列列看，到底有哪些事情是我認為同樣很重要，但是可能其他人不這么認為的”小事兒”。

合作方面

1、合作過程中多積累

產品經理經常需要和不同的人進行溝通和對接需求，例如公司領導層、運營、投放、商務、業務、設計、開發、測試等。

不同的人，都會站在不同的立場、出于不同的目的，向你提需求或者反饋意見。

在大前提他們的需求合理的情況下，你是直接根據他們的做了呢？還是多多向他們請教一下呢？

• 運營投放們需要你配合的時候，不要以為自己不相干，要多看看他們的活動類型、多思考他們的投放渠道、多問問為什么這么選擇；
• 開發們圍在一起溝通技術細節的時候，不要以為不關自己事兒，要多聽聽、多了解下他們是如何實現需求的；
• 設計們出設計稿給你的時候，不要一味著收到稿子完事了，多和設計們討論和請教一下，為什么這么做的原因；
• 老板覺得要提前做某個需求，不要只把自己放在執行的位置，要多想想為什么這么做，對公司有什么好處，公司最近有什么變動，如果想不明白，可以嘗試問問看；
• ……

這些都是寶貴的各個角度的實踐知識啊，都是需要看專業書才有可能看到的東西或者有可能連書里都沒有。現在，你通過一個個需求，就慢慢都了解了，這么一個大好的補充各方面知識的機會擺在你面前，怎么能浪費呢？

不說好處的都是耍流氓，這么做的好處如下：

• 對其他和你合作的人以及他所在的崗位有更深入的了解；
• 慢慢積累自己對各方的大概知識框架；
• 基于前2點好處，相互之間的溝通會越來越順利；
• 在之后的需求時間預估和項目排期上會更加有把握一些。

合作過程中，多問為什么，這個在之前的文章里有解釋過，這里就不在多說了。

2、擺正和各方關系的心態

產品人要端正幾個態度，那就是：

• 不要把設計師們、開發們、測試們當做實現需求的機器；
• 不要把運營、投放、商務、老板等人當做只會提需求的臭傻逼。

經常在各種地方看到產品人在各種吐槽，例如：

• 就是簡單的移動一下位置、放大一下，想不明白為什么美工做不出來；
• 一個簡單的功能，代碼狗們都搞不清邏輯，實在是太弱了；
• 老板只會嗶嗶嗶的提需求，太坑了；
• ……

你用這種對立的心態去看待你的伙伴、你的組員，那么你和大家的關系怎么會好呢？人家跟你關系不好，更是不可能愉快的共事啦。

想讓別人尊重你的前提是，你得尊重別人。

這么做的好處：

• 伙伴們能夠在愉快、相互尊重的氣氛中工作；
• 對于個人，是一種素質的提升。

產品工作本身

1、多從整個產品的角度考慮問題，而不是僅從產品崗位角度考慮問題

舉個例子，這個版本的需求都已經確定，版本上線時間也已經確定了。但是，運營和投放因為某種原因，要在下個版本做一波大活動和投放，需要產品這邊配合開發一些東西，這個時候怎么辦？

如果僅從產品崗位考慮問題的話，會覺得這個太臨時了。如果應承下來做的話，不但要臨時給自己增加工作量，還需要和設計師們、開發們重新溝通時間、調整計劃。他們也可能因為臨時的工作量而導致一些負面情緒的出現，你還得理性/感性的進行安撫。

但是，從整個產品考慮的話，這又是一件需要并且最好做掉的事情。畢竟，在整個團隊有數據壓力的情況下，需要用一些外在方法來帶來新增和日活，這樣對整個團隊都好。

再舉個例子，一些小白產品們總是會糾結在一個公司里，到底產品更重要還是運營更重要的問題?？傆X得公司重視運營，不重視自己，從而很難過。

其實，這種想法并沒有什么意義，如果站在整體考慮的話：需要強運營的產品，自然偏重運營；需要強功能的產品，自然偏重產品。

偏重問題，只是量的問題，并不是質的程度。考慮怎么對產品好，這才是最需要糾結的問題。

這么做的好處：

• 對整體產品比較好，不會因為產品的私人考慮而有所偏差或者停滯；
• 對個人發展比較好，不斷的鍛煉自己的全局觀思維。

2、多和團隊伙伴溝通業務

有時候，能看到產品人抱怨他們的團隊成員。比如，我們組里的人都不關心需求、他們只知道做，做了又做錯，真是無語。

這個時候，其實你要反思一下，是不是你從來不和他們溝通為什么需求要這么做，才慢慢導致這種情況的呢？

當然，我也清楚，不是所有的開發們、設計們都對為什么要做這個需求有興趣，但是如果連懂都不懂，你怎么指望大家設計、開發出你想要的東西呢？

不妨在每個版本溝通需求的時候，順便把每個需求這么做的原因也和他們溝通一下，不管是從數據分析結果、用戶反饋，還是公司高層出于戰略考慮，都可以說一說。

畢竟，我還是堅信，基于理解基礎上的需求實現，從長遠上看比較“安全”。

這么做的好處：

• 基于理解的設計和開發，可能能夠在照顧到現有需求的前提下，考慮到一些可能的坑和未來的改動；
• 長久，大家會更有團隊的感覺。

3、看數據結果前，辯證數據的真偽

很多產品經理會經常說：

從數據結果可以看出balabalaba……

這都快成為一種口頭禪了。

但是我要告訴你，如果數據本身就是錯的，那么你所謂的數據結果就是個無稽之談。

可能你會很疑惑，數據怎么會錯呢？當然會啦：

• 可能因為不同平臺的不同算法，導致數據和你真正想要的算法不同，從而出錯；
• 可能因為開發埋點的時候不小心弄錯了，從而出錯；
• 可能因為開發實現某個相關功能的時候，實現方式的不同，導致連帶影響到數據偏高或者偏低，從而出錯；
• ……

數據出錯的可能性很多，因此，在說出“從數據結果可以看出”這句開場白之前，先去了解清楚數據本身是否出錯。

這么做的好處：

• 不會把時間浪費在錯誤的數據上；
• 對數據分析會有更深入的理解；
• 更容易得出真實的數據結果。

4、產品材料一定要文字留檔

這是個非常非常非常重要的事情，請一定要記住。

剛進公司的時候，我發現公司里居然么有產品文檔可以共享。了解產品基本靠多使用；要修改某個功能，基本靠經手人的記憶力。

這樣是非常傳統并且不科學的方法。一旦出現經手人離職的情況，接手人分分鐘懵逼，說不定得讓開發們找對應的代碼才能僅僅解決了解概況這個問題。

而其中最重要的是，產品的增刪演變歷史以及對應的需求文檔。

這么做的好處：

• 出現問題或者需要相關需優化的時候，可以根據文檔找到具體參考；
• 從歷史中了解變遷，有助于需求的管理；
• 有助于項目的交接。

5、需求要對接完整

工作中，會經常出現要和第三方溝通對接需求的情況，這個第三方有可能是公司外部的，也有可能是公司內部其他小組的。

有些產品覺得既然是技術對接，那么所有的事情就都可以等技術對接的時候再去做咯，然后就把所有的東西都丟給技術了。但實際上真是這樣嗎？

• 也許流程可以先梳理起來；
• 也許對接文檔可以讓對接方先準備起來；
• 也許測試環境可以讓對方先搭起來；
• 也許要配置的接口可以讓對方先設置起來；
• ……

和第三方對接，本來就存在很多坑（文檔不齊、接口不ok、對接時間超長等等），產品最好要能夠在對接前期先準備起來，這樣開發們在對接的時候也會比較方便和省時間。

盡量把對接控制在可控制的范圍內，而不是任由發展。

這么做的好處：

• 和你合作的開發們會比較舒服一些；
• 對接完成的時間相對可控一些，從而計劃好的上線時間也相對可控一些。

6、要做好準備再拉人開會/討論

越是工作到后面，越是討厭開會，有時候甚至討厭小撮人的討論。為什么呢？

• 往往沒有一個討論重點
• 有重點，但是都是頭腦風暴

沒錯，頭腦風暴是好的，但是同一件事，如果每次開會都是頭腦風暴形式的，那么是非常讓人心煩的。

因此，無論是開會還是討論，都應該在之前就列出討論的主題、圍繞主題的一些點。這樣大家就可以根據列的內容進行有條理性的討論了，從結果上，也更容易有效果，搞定事情。

個人思維方面

1、不要害怕變化

舉個例子，產品比較小的時候，需求可以有很多，面臨的方向也可以有很多，大家都在進行不斷的調整。這個時候，有可能會因為某些因素（公司要求產品盈利等等），而出現你原本安排好的下一版需求沒辦法做了或者需要推遲做，要優先做其他的。可能這個時候你已經做完了所有的需求分析，一旦改變，那么就要趕時間做新的東西了。

這個時候，你該怎么辦呢？

我其實理解很多人會因為個人原因去拒絕這種變化，大家都是人，怎么會不明白呢？

但是，做產品人不可以這樣，因為有可能會因為你的執意，導致團隊在做錯的事情。

這個時候，需要考慮的不是個人增加工作量的問題，而是對整體產品好不好的問題。如果確定對整體產品比較好，那么就該摒棄個人的負面情緒，順勢好好的執行下去。

這樣做的好處：

• 對整體產品好、對團隊成員好；
• 順便鍛煉自己的應變能力和心臟承受能力。

2、要把鍋背起來

產品經理是需求的開始，也是需求的結束。只要上線了，那么就說明你是允許這個上線行為的。

如果上線后程序有大bug了、某個功能被用戶罵死了等等，產品經理都要學會去負起責任，如果負不了責任，那么至少要先把鍋背起來。

要端正自己的態度，不要出問題就賴開發碼太多bug了、測試不給力什么的，畢竟，你才是最終決定上不上線的人。

這么做的好處：

• 團隊對你有信任感；
• 個人學會承擔也是一種極大的成長。

3、靈活看待制度

舉個例子，一般公司都會規定版本上線的時間。但是如果App臨上線前發現了一個大bug或者比較影響體驗的bug。那該怎么辦呢？是推遲上線，等修復后再上線呢？還是不管三七二十一，制度說要上，那就上呢？

不同人有不同的選擇，但是出于對產品的考慮，是不是選擇前者更為好呢？

一上線就bug反饋papapa，崩潰率papapa，用戶差評papapa，這真是你要看到的結果嗎？

你這個時候再去因為這些papapa去修復、去重新再上一個新版本，這又是多曲折。

當然，我并不是鼓勵不遵守制度，而是說要靈活的遵守制度。畢竟，情況是復雜滴，人是活滴。

4、執行想法成功落地本身比想法更重要

很多人會說，“我想法多”、“我思維活躍”，但是想法多真的有你想象中那么重要嗎？

想出來了，那之后呢？總要執行的吧。如果執行不了，那么你的想法就等于什么也不是。（當然，這里排除光靠想法去融資的，畢竟你的執行就是找到了人替你的想法買單）

不要不看重想法，但也不要把想法看的太重。真正創意意義上的想法，我認為注定是少數。而絕大部分的產品經理，你要清楚，你也許是暫時沒有這個能力的。

你覺得我看死了你的能力？并沒有。所有的創新其實哪里是憑空想出來的，都是基于對大勢或是對環境或是對行業或是對用戶的深刻理解，沒有一定的經驗是出不來的。我個人是不相信偶然事件的。
既然，暫時無法做創新，那么就該把當下的事情做好，在執行的過程中積累，為未來做準備，同時，從結果論上來說，也對結果負責了。

5、節操不要太高，但底線一定要有

很多產品經理很唾棄產品之間相互借鑒這件事，不管三七二十一，看你產品長的差不多就說你像素級抄襲，這其實是很小白的行為。（電商都長一樣，你能說他們抄襲嗎？）

我不是為了反對這些人的想法而反對，而是說：

• 借鑒什么功能、適合用什么形態來展現，這些都是需要根據不同產品的特色去選擇的、去體會的。即使是借鑒，也是做了大量的思考和改良的。而這個差別，就是有些產品能夠借鑒成功，有些不行。
• 跨界的借鑒從行業上來說更具有意義。

如果正向的解釋你看不懂，那就從反向想一想：目前這個互聯網上，有什么產品功能或者產品形態是真正意義上沒人做的嗎？如果真的沒有，那么你趕緊拉幫人去創業吧。

既然是已經存在的事物，那么人家坑都幫你踩平了，你何不借鑒一下現成的東西，再根據自己產品的情況去改良一下呢？還非得自己去全部踩一遍坑才滿意嗎？

大家都是成年人了，就不要相信什么抄襲可恥了，應該認為借鑒有益才對；

大家都是成年人了，也不要太執著于自己的愛豆是喬布斯了，并不是人人都可以是喬布斯。

以上，對于“產品借鑒”的看法，是為了說明在很多事情的思考上，并不需要一板一眼，能夠解決問題的方法就是好方法，而不需要給自己設定一條無形的線，這個不可以做，那么不可以做。那樣，你會把自己給累死。

雖然不需要那么有節操，但是底線還是要有的。違法亂紀相關的事情還是不能做滴，這個就不多加贅述了。

好啦，暫時想起來這么多，如果覺得有補充的，可以在評論中告知哇～

#專欄作家#

killifer，微信公眾號：killifer，金融資訊&工具類產品經理。腦洞大、笑點低、間歇性“有毛病”的理工科實力逗比少女。

本文原創發布于人人都是產品經理，未經許可，不得轉載。