使用者在使用一款軟體時，所呈現的功能到底為什麼是這樣設計的?為什麼你認為重要的功能，遲遲不能被實現?是因為產品經理像吐槽中那麼LJ呢還是另有起因? 一般，我認為做產品可以大體分為這幾個類型：異想天開型、業務驅動+用戶驅動型、業務驅動+使用者驅動+資料驅動型。
第一種 異想天開型
其實，這一種是最常見於新手中的，或者是大學社團組織中(本人在此深有體會)，因為這一類型的產品往往是由於在負責人的突發奇想下誕生出來的，只是從表像需求，就單方面認為產品有可行性。舉一個本人的例子，在大學時期做產品的時候，認為現在21世紀還用貼海報的形式來宣傳活動太low了，而且雖然學校在教學樓也有LED做活動宣傳之用，但學生們卻經常不會去留意。接著又從個別學生那裡得知其實他們很想瞭解學校有哪些活動，苦於不知道從哪裡獲取這些活動資訊。因此，就得出一個初步的結論：弄一個基於web端/移動端的學校活動資訊展示平臺，應該會讓學生歡迎的。所以就大張旗鼓地開搞了，最後.....現在一天只有幾十個PV。 所以，基本上所有異想天開型的產品不是在實現過程中夭折，就是在實現後不就折戟成沙。除非，你是那幸運的0.000000000001%?
第二種 業務驅動+用戶驅動
經歷了第一種的慘敗，再怎麼稚嫩的產品經理都會長點記性了。所以他們開始懂得思考產品的真正價值，為用戶、公司帶來的價值。這個功能不再是因為我喜歡，而是因為使用者需要。這個功能應該放到後面在做，因為這是解決少數人的需求，還有其他更加緊急重要的需求先要被滿足。 所以到了這個階段，產品經理已經走在了成為平衡木高手的征途上，他需要權衡各個需求，是滿足業務為先還是滿足用戶，或者滿足其他一些部門的需求，同時還要考慮到團隊成員的整體水準。
所以當使用者在看到軟體所呈現的功能時，一般都是產品經理在左右權衡之後帶點無奈的選擇。因為，老闆會說A重要些，關於B的都先放下;因為，設計人員會說這個效果已經足夠了啦;因為，開發同事會說你這個需求實現起來比較困難，坑挺多了，要做好專案延期的準備。但是一個優秀的產品經理，應該要有底線，就算有再多的客觀的原因，只要這個方案是急切需要被實現的，那麼就應該嘗試去說服，堅持做下去。(不過，很多新人經常會被對方一兩句話被堵得啥也說不出來)
第三種 業務驅動+使用者驅動+資料驅動型
客觀分析統計資料，為你的方案提供據理力爭的事實依據。
留言列表
