創業公司的特點:錢少,人不夠,時間緊。和大公司的成熟產品思路會有顯著差別。

一,精益迭代,快速交付,快速驗證

因此,第一點是要全員貫徹一個思路:瀑布流式的產品模式不再行得通,精益迭代是更好的辦法。

精益迭代不是口頭說說而已,而是貫穿整個開發過程的思路,核心思想就是:

關鍵點:

  • 一:洞察需求后,快速完成demo來驗證需求是否真實
  • 二:根據驗證結果來決定每一次迭代加強什麼,減去什麼
  • 三:將需求拆分到每周可交付,每個月可上線更新
  • 四:觀察用戶的行為:他最喜歡點哪裡,他經常會點錯哪裡,他到哪裡就不進行下去了,他抱怨什麼,他問了什麼問題,等等。

我們自己的例子:

在初期我們快速測試了4個模塊的重要性:遠程外包,程序員展示,用戶活躍激勵,解決方案。然後根據用戶行為的反饋(對什麼感興趣,願意點擊哪個模塊,不會關心什麼,討厭什麼,等)來決定每一次迭代加強什麼,減去什麼,最終形成了現在的產品的路徑。

每次測試的時間不超過2周,一周出demo,一周上線給用戶使用。

程序員客棧產品模塊演化表

關鍵功能演化圖

探索期收穫(3個月,用戶0-1500)

快速測試尋找能夠直接為用戶帶來利益的功能點(頁面熱點分析,用戶反饋,訪談等)

外包分發(最熱門且利潤空間最大,但難度最大)

解決方案銷售(開發者對於做售後比較排斥,有難度)

程序員招聘(熱門但競爭激烈,難度小)

首頁熱點圖

二:而進行優化充分滿足需求的時候,又同時要考慮這麼幾點:

用戶可感知:你的C端客戶,B端客戶,後台使用者

用戶不可感知:系統性能提升,系統安全性,SEO

例子:只關注用戶可感知的部分,不關注不可感知但是重要的部分,會有什麼問題?

參考資料:論產品的內外兼修

要同時協調好這兩個方面的規劃,才能讓你的產品內外兼修,帶給用戶持續的滿意。

三,創業過程中,我認為重要的產品文檔:

是要可以讓閱讀者一目瞭然自己要做什麼,怎麼做的。

複雜不是目的,溝通實現才是。

1:產品總述:

說明本次主要要做什麼事情,優先級別如何,負責人是誰。

我自己web和 APP 的文檔一般是分開寫,這樣負責人比較固定。

以下部分的文檔,一般都會嵌入到總述裏面,組成完整的產品文檔。

2:產品架構圖:產品的全局觀

並不是每次迭代都要做,當你有部件上的改變的時候才需要更新。

相當於骨架。

產品架構圖一般用腦圖完成,目的在於描述整個產品的結構,模塊以及頁面數量。

3:業務流程圖

就是用戶如何通過產品來解決痛點的核心流程。

主要用於闡述核心業務流程,便於後端開發業務邏輯,以及各端配合。

4:產品線框圖(每個頁面布局及交互)-我們常說的原型

以程序員客棧某期的登錄流程為例,線框圖及交互的目的在於根據功能需求設計每個頁面的布局,以及頁面與頁面之間的交互。

這一步的關鍵是布局,以及頁面切換邏輯。高保真不是必要的。

可以使用的工具:

Axure, Sketch, modao,Balsamig mockups, PPT,one note, 都可以。

還可以用principle, pixate來做交互的輔助。

我自己一開始用modao, 然後當頁數變多后墨刀的速度變慢,並且墨刀不能直接導出交互圖(當時),因此改用sketch了, 一般效果如下:

APP 3.0 原型-預約流程.png

5:頁面描述表

這一步是對於主要頁面進行分解詳述,讓設計師,開發者明白每個部分如何展現,作用是什麼。

例子:待定。

6:測試用例

在從細節上反過來完善產品,以及為下個版本的優化提供素材。

7:產品的路徑規劃表:平衡資源,用戶感知以及不可感知的部分,找到其中的節奏來發展產品。

四,最後來講講,怎麼獲取用戶反饋

做客服:產品經理花時間來做客服是很值得的事情,每天兼職做1,2個小時,或者可以查看之前的客服記錄,了解用戶主要會針對哪些地方提問題,那麼這些地方就是你之後要考慮解決的問題-真正的好產品,是讓用戶流暢使用下來沒有問題的。

關注相關社區對於自己的討論:我們會經常到V2EX, 知乎,或者其他的程序員社區去看是否有相關的討論,並給予即時的回答。

為了能夠及時獲取相關討論,我自己做了一個爬蟲工具,每天爬取指定網站的信息,便於我及時了解並反饋。

鼓勵用戶在自己的社區討論並給與即時的反饋:我們現在除了嵌入了可即時反饋的客服應對系統以外,還有一個公開展示的意見反饋欄。目的就是為了鼓勵用戶,有問題就提出來,我們會即時解決。

意見反饋

作者@喵在野

來源@簡書

本文由 @喵在野 授權發佈於人人都是產品經理 ,未經許可,禁止轉載。