流程:敏捷迭代與持續優化
流程的優化是產品開發效率與質量的保障。Cagan倡導采用教捷開發方法,通過快速迭代與持續反饋,確保產品能夠迅速響應市場變化與用戶需求。
這種靈活的工作模式,不僅加速了產品推向市場的速度,還提高了產品的適應性和競爭力。
軟件開發的精髓在于不斷探索與迭代。將項目分為”產品探索”與”產品開發”兩個階段。
前者專注于市場驗證與用戶反饋,后者則致力于技術實現。建議采用流水線模式,即當1.0版本進入開發,2.0版本進入第一個階段,來確保產品選代的連續性和效率。
一、產品探索
1.1 評估產品機會:科技視角下的戰略抉擇
在科技飛速發展的今天,市場不僅為新產品敞開大門,也為成熟產品提供了升級轉型的機遇。評估產品機會,實質上是在探尋科技的下一個風口。這不僅關乎成本與收益的考量,更是對未來趨勢的精準把握。
然而,在現實中,這一環節往往被簡化或忽視,決策依據常流于直覺或對大客戶的過度依賴,甚至產品選擇權可能在高管、市場部。
評估產品機會是為了淘汰壞主意,避免浪費時間和金錢,挑選合適的產品機會,團結團隊,理解產品,整合資源。
高效評估產品機會的關鍵步驟:
- 產品價值定位:產品要解決什么問題?明確產品旨在解決的核心問題,確保其與市場痛點緊密相連。
- 目標市場界定:為誰解決這個問題?精準識別目標用戶群體,理解他們的需求與期望。
- 市場規模分析:成功的機會有多大?基于詳實數據,客觀評估市場潛力,避免盲目樂觀。
- 度量與收益指標設定:怎么判斷產品成功與否?與財務專家緊密合作,建立科學的評估體系,確保產品成功有據可依。
- 競爭環境洞察:有哪些同類產品?為什么我們適合做這個產品?全面審視競爭對手,明晰自身競爭優勢。
- 市場時機把握:時機合適嗎?評估市場接受度,確保產品推出恰逢其時寸。
- 營銷策略規劃:如何把產品推向市場?制定有效的推廣計劃,確保產品順利觸達目標用戶。
- 解決方案可行性:成功的必要條件是什么?明確產品成功的必備條件,聚焦用戶核心需求。
- 決策節點設定:繼續或者放棄?確立繼續開發或放棄項目的明確標準。
1.2 產品原則:堅守核心,激發創新
意味著什么重要,什么不重要,哪些原則是根本性、戰略性的,哪些是臨時性的、戰術性的。這不屬于任意個產品專屬,而是一種價值概念,更好地激發設計靈感。
在做決策前必須解決以下幾個問題:
- 解決什么問題?
- 要為哪些角色解決這個問題?
- 要達到什么目標?
- 優先級是什么?
在許多情境下,盲目追加新功能往往適得其反,可能導致產品臃腫,而非增值。因此,我們提倡從另一個角度著手:優化。首要之務是設定清晰目標,全面審視產品現狀,鎖定優化焦點。這可能意味著精簡冗余功能,提升現有特性,或改善用戶體驗,而非一味追求功能疊加。
即摒棄傳統產品設計思維,不再追求終極形態,而是定義最基本的產品版本,僅保留實現商業目標不可或缺的核心功能,剔除一切非必要元素。
1.3 市場調研:洞察用戶,指引方向
市場調研能更好地回答以下關鍵問題,可以作為研發產品的依據和參考,但不能決定研發的方向。
以下關鍵問題的解答將為產品迭代提供堅實的基礎:
- 目標用戶是誰?明確用戶畫像,了解其需求、習慣和痛點。
- 用戶如何使用產品?觀察使用場景,捕捉未被滿足的需求:。
- 使用障礙何在?發現并解決用戶界面和體驗上的難題。
- 為何選擇你的產品?分析競爭優勢,強化品牌忠誠度。
- 喜愛產品的哪些特色?強化優勢,打造差異化賣點。
- 期待產品如何進化?收集改進建議,規劃未來功能。
常用的市場調研工具和方法有:用戶研討會、用戶調查、產品使用分析、拜訪用戶、可用性/現場測試、同類產品分析。
了解每個方法的局限性更好地幫助我們做好調研。
1)用戶調查:幾乎現在所有產品要求做用戶調研,注意兩點:
- 設計調查問卷需要技巧和經驗,結合具體情景,仔細設置問題;
- 調查結果為獲得解決方案提供一條途徑,但不是解決方案本身,哪怕所有用戶都回答喜歡X特性,我們還是可以提供Y特性更加實際地滿足需求。
2)產品使用分析:網站可以用工具分析用戶訪問網站的行為,越早分析越好,不斷觀察然后調整產品。如果非網站,可以設置埋點記錄用戶的行為,應該明確告訴用戶只收集統計數據,不涉及用戶隱私。
3)數據挖掘:渠道很多,除了產品使用分析,還有用戶賬單、賬戶信息、產品數據等。
4)拜訪用戶:效果最好,但是成本較高,視情況決定;
5)人物角色:面對的不是單一一類用戶,要找出若干主要用戶類型,深入了解后知道哪些是當前的用戶,哪些是潛在用戶;
6)可用性測試:盡早、反復地使用,觀察現有用戶對此的反應,收集反饋。可以考慮遠程工具,在異地進行可用性測試、記錄和分析用戶行為;
7)同類產品分析:往往會低估對手,每款產品都有做得好的地方。有必要找出成功經驗,并進行學習。
8)用戶研討會:讓用戶群面對面地溝通,但只有謹慎規劃。并不是每個用戶都知道想法是否可行的,對現有技術知曉很少,也不知道自己要什么,沒見到實際產品前很難憑空思考。并且人群聚集時,相互影響,難以獲取真實想法,極大可能變成善于表達者的專屬會議。這種調研比較適合政治活動,具有領袖意識的。
1.4 產品人物角色:精準定位,驅動決策
產品管理的關鍵在于明智決策,即把握機遇,解決問題,識別核心功能,聚焦主要用戶。
回答幾個問題:應該抓住哪些機會?解決什么問題?哪些功能最有價值?誰是主要用戶?
成功的產品需確保決策正確率高,人物角色在此扮演著至關重要的角色。人物決策又分為用戶特征記錄,通過與用戶溝通交流,確定典型的目標用戶類型,在理解各類目標用戶的特征的基礎上建立的人物原型,重點關注用戶的行為、態度和目標。
有以下好處:
- 篩選核心功能:聚焦目標用戶,舍棄非核心需求,打造精簡高效的產品。
- 避免自我投射:防止將個人喜好誤認為普遍需求,保持客觀。
- 用戶類型優先級:識別關鍵用戶體驗環節,優先優化。
- 統一團隊認知:清晰傳達目標用戶特征,促進團隊協作。
- 促進共識形成:確保團隊對產品愿景有共同理解。
不同的團隊使用人物角色的時間和目標不太一樣。產品經理進行人物角色的時間越早越好,深入參與創建人物角色的工作,尤其是要參與用戶交流和用戶調研,以及所有的可用性測試,抓住一切機會與用戶交流。
但是有些注意事項:
- 盡早啟動:產品經理應盡早介入,積極參與用戶調研,深化用戶理解。
- 針對性訪談:每次調研集中一類目標用戶,深入挖掘需求。
- 基于實證設計:避免憑空臆想,讓數據說話。
- 多樣化用戶參與:邀請不同背景的用戶參與測試,確保全面視角。
1.5 特約用戶:共創共贏,推動產品進化
無論是平臺產品、商業應用還是針對大眾的互聯網服務,用戶都希望看到他人使用的效果后在進行嘗試。
為了解決既要深入探索目標用戶的需求,又要贏得用戶對產品的推薦,采用征集特約用戶(用戶評審團、用戶顧問委員會)協助完成產品研發。
在項目開始階段找到至少6位積極、活躍、樂于分享的目標用戶(可以先8-10人,再從中篩選),要求是他們在產品的目標用戶中具有一定的影響力,只要他們認為未來的產品可以解決他們的問題。支持提前試用,降低他們為之付出的機會成本。
盡可能多地拜訪用戶,深入交流,參加每一次的可用性測試和特約用戶交流會。但是在組織過程中有一定的注意事項:
- 免費體驗:為用戶提供免費試用機會,減少參與門檻。
- 適度規模:控制特約用戶數量,確保深度交流與個性化關注,最好不超過10個。如果人數不夠,需要考慮產品計劃是否合理。
- 用戶類型甄別:區分產品嘗鮮者與目標用戶,確保反饋的有效性。
- 明確產品性質:一定提前強調產品面向大眾,非定制化服務。
- 合作關系構建:與特約用戶建立長期友好關系,視其為產品扣維廣的合作伙伴。
- 全程參與:貫穿于產品研發的各個解決,向他們展示原型,參與測試,請教產品細節等問題,幫助部署和發布備選版本;
- 滿意度保障:正式發布前確保每位特約用戶對產品高度滿意,成為口碑傳播的種子。
- 營銷協同:與營銷團隊緊密合作,不僅共同挖掘潛在特約用戶,也拼大產品影響力。
- 平臺產品的特殊考慮:對于平臺類產品,需特別關注應用開發我者的需求與反饋。將6個用戶要換成6個應用。
1.6 重新定義產品說明文檔
產品經理肩負重任,其核心使命在于向開發團隊交付一份富富有潛力的產品說明文檔,確保產品從概念到實現的無縫對接。
這份文檔應涵蓋以下關鍵要素:
- 全方位用戶體驗描繪:不僅深入理解用戶需求,更要詳盡闡述交互設計與視覺設計,確保用戶體驗的每個觸點都得到精心規劃。盡管產品迭代不可避免,但用戶體驗的完整性與連貫性至關重要,需被視為一個整體來審視。用例分析則作為有力補充,詳細描述產品行為,包括但不限于業務邏輯、發布標準及平臺交付要求。
- 精準描述軟件行為:文字與圖像雖為常用手段,但在必要時,引入視頻演示能更直觀展現軟件操作流程,彌補靜態材料的局限性。
- 直觀展示:采用易于理解的格式,如流程圖、圖表或原型,使文檔內容一目了然,便于快速吸收信息。且必須經過嚴格測試,邀請真實用戶參與,驗證其清晰度與吸引力,確保用戶既明白如何使用,又愿意主動使用,這一步驟不宜拖延至后期測試階段。
- 靈活可調整性:文檔應設計成可輕松修改的形式,以便根據項目進展或反饋進行適時調整,確保與產品演進同步。在文檔制作過程中,優先采用高保真原型,這不僅能生動展現用戶體驗,還能模擬后臺處理流程和數據交互,覆蓋所有關鍵頁面和用例,從而大幅降低意外錯誤的發生率。
- 版本控制:明確標注文檔版本,確保所有團隊成員都能訪問到最新、最準確的信息,避免因信息不同步導致的混亂。
1.7 原型測試:迭代優化的實踐指南
產品原型可以讓用戶體驗產品的創意,加深對未來產品的理解,避免對信息處理和接收的不一致。
以下是如何開展測試的過程:
1)物色測試者:
測試前,通過短信或電話確認測試者出席,避免放放鴿子現象。
- 定向邀請:針對特定用戶群體,直接發出邀請,確保參與者具有代表性;
- 行業展會招募:對于企業級產品,可在相關行業展覽或會義中尋找目標用戶。
- 在線征集:利用分類信息網站或社交媒體發布招募信息,設定定寬泛條件,后續進行篩選。
- 親友團試用:面向大眾產品,邀請親朋好友進行初步測試,注意排除過于熟悉或技術背景的個體。
- 數據庫篩選:利用已有用戶數據庫,挑選合適測試者。
- 公司網站招募:發布志愿者征集公告,過濾產品嘗鮮者,尋習求真誠反饋
- 定期測試活動:每兩周舉辦一次原型測試活動,邀請10-20位測試者參與。
- 現場招募:在目標用戶集中區域現場尋找測試者。
- 上門邀請:對于不便線上測試的項目,邀請測試者上門。,適當給予補償。
2)準備測試:
- 測試大綱:提前準備測試內容,重點評估用戶在主要操作上的的體驗,無需等待產品完全成熟。
- 首次接觸:初次測試時,讓用戶自由探索未加引導的界面。
- 用戶洞察:觀察測試者對產品首頁的第一印象,識別吸引點與價值所在。
- 深度訪談:任務完成后,通過問答了解用戶偏好,對比競品優就勢,評估凈推薦值,探討推薦意愿。
- 量化反饋:鼓勵用戶以評分形式給出評價,便于數據分析。
3)測試環境
- 監控設備:配備單向透明鏡、閉路電視與多角度攝像頭,記錄用戶行為與表情。
- 真實場景:理想情況下,測試應在用戶日常環境中進行,增強反饋的真實性。
- 遠程測試:利用遠程協助工具,跨越地域限制。
- 開發者參與:鼓勵開發者直接參與,增進對用戶需求的理解。
- 雙人組隊:安排一名主持人引導流程,另一名記錄員捕捉細蒂。
4)測試原型
- 簡短介紹:測試前簡單說明,不要和測試者交談過多。務必告訴測試者這是產品原型,初步的創意,不是正式產品,請說出真實的想法。
- 情緒管理:保持測試氛圍輕松,讓測試者盡量保持平和的情緒,重點看完成是否輕松,是否喜歡?
- 沉默觀察:測試過程中避免干擾,讓測試者自然反應。保持安靜,不要給提示,也不要做任何引導動作。
- 用戶態度解讀:留意用戶的非言語信號,判斷其對產品的興趣度與期待感。目的是看用戶如何看待產品解決的問題,通常三種結果:順利、遇到麻煩、受挫。如果表示要用其他產品,說明他們真的放棄了;
- 探究原因:主持人可以自言自語的技巧,一般測試者會主動告訴為什么要這么做;
5)更新原型
- 快速迭代:當2-3位測試者反饋相同問題時,立即采取行動修正。
- 果斷舍棄:若產品無法引起測試者的興趣或操作過于復雜,及時調整策略,勇于承認并改正錯誤。
1.8 產品驗證:確保方向正確無誤
指在正式開發和部署產品前,驗證產品說明文檔描述的產品是否符合預期的要求。不要總是等著公開測試前再收集反饋意見。
主要聚焦以下三個維度:
- 可行性測試:考察現有技術能否支撐產品設想,評估產品架構與技術棧的匹配度。
- 可用性測試:突出產品的功能特性,讓不同類型的用戶都可以明白如何使用。往往發現沒能成功實現的產品需求,甚至是原本被忽略的需求,最好規劃多次迭代,確保最佳的用戶體驗。一定要邀請真實的用戶體驗,從目標用戶中得到反饋信息。
- 價值測試:評估產品市場價值,探究用戶是否認為產品有益,是否愿意為之付費。同時,衡量用戶對產品設計的喜愛程度,確保產品不僅實用,也具備吸引力。
1.9 產品評審團:集思廣益,加速決策
產品評審團機制的目標是可以快速讓決策者和相關成員及時性做出決策,并且監督完成,而不是制定商業目標或者對產品細節做更正。
成員一般不超過10個人,由部門負責人、技術、市場、運營、產品、服務、質量和設計負責人組成,根據實際情況一個月一次或者一個月兩次。
二、產品開發
2.1 靈活應用敏捷開發:激發團隊潛能
Scrum方法,作為敏捷開發框架之一,特別適用于產品軟件開發領域,尤其當項目需求模糊、客戶期望多變時,更能發揮其優勢。
相比之下,定制軟件開發因其需求相對固定,更傾向于采用傳統的瀑布式開發模式。
以下幾點敏捷開發技巧,旨在提高團隊效率與項目成功率:
- 產品經理角色強化:產品經理兼任產品負責人,確保項目愿景與執行一致。理想狀況下,由同一人擔任,以減少溝通成本,加速決策進程。
- 縮短規劃周期:采用短周期迭代,輔以簡潔的機會評估機制,取代冗長的市場需求文檔,使團隊能夠快速響應市場變化。
- 先行一步的設計:產品經理與設計師應領先開發團隊1-2個迭代周周期,確保設計與原型經由開發團隊評估,保證技術可行性。
- 模塊化設計:將產品設計細分為獨立組件,便于并行開發,同時確保各部分均滿足基礎需求。
- 輕量化文檔:以產品原型與用戶故事取代繁重的產品需求文檔,直觀傳達產品概念,促進團隊間高效溝通。
- 迭代周期自主:鼓勵開發人員根據項目特性,自主決定迭代周期長度,以適應不同任務的節奏。
- 每日站會參與:產品經理與交互設計師需每日出席晨會,保持與團隊的緊密聯系,確保信息流通無阻。
- 質量把關:未經客戶驗收合格,嚴禁發布新版,確保產品質量符合預期。
- 迭代成果分享:每輪迭代結束,產品經理向團隊展示項目進展與下一迭代計劃,增強團隊凝聚力,共享成就感。
- 持續教育:定期組織敏捷開發培訓,提升團隊敏捷意識與技能,保持團隊活力。
2.2 瀑布式開發的理性應用:穩定與控制
瀑布式開發,一種經典的線性項目管理方法,特別適用于需求I明確、變更較少的項目。
其遵循的基本原則包括:
- 階段式開發:將項目劃分為需求分析、系統設計、編碼實現、測試驗證、部署上線等固定階段,確保每個環節有序進行。
- 階段評審制度:每個階段結束時,進行嚴格評審,確保階段性生成果達標,方可進入下一階段,有效控制項目風險。
然而,與敏捷開發相比,瀑布式開發存在明顯局限。產品交付周期較長,難以迅速響應市場變化,且一旦發現缺陷,修復周期往往漫長。
因此,在選擇開發模式時,需綜合考量項目特性與團隊能力,靈活運用敏捷與瀑布兩種模式,以達到最佳開發效果。
2.3 平滑部署:尊重用戶,平穩過渡
并非所有用戶都熱衷于擁抱新版本,抗拒升級的原因多樣,包括:
- 缺乏預知:事前未接獲更新通知,令用戶措手不及。
- 適應障礙:無暇學習新版本,加之產品公司未能提供過渡期使用指南。
- 技術故障:新版本存在穩定性問題,無法正常使用。
- 兼容性缺失:新版本無法讀取舊數據,造成不便。
- 功能質疑:用戶認為新增功能無實際價值。
- 頻繁更新:過于頻繁的版本選代,引發用戶厭煩。
- 習慣打斷:新版本改變操作流程,迫使用戶調整習慣。
為實現平滑部署,即合理地、謹慎地更新產品版本,我們需細致規劃,將負面影響降至最低,具體措施如下:
1)提前溝通:利用公告、郵件、在線教程等形式預告更新,提升用戶接受度。
2)徹底測試:確保新版本質量,避免緊急回滾。
3)恰當的部署方式:根據實際情況選擇,常見的有3種:
- 并行部署:維持舊版本運行,明確標識新舊版本,大型產品過渡期通常為數月。
- 區域性部署:先在小范圍內試水,再逐步推廣。
- 增量部署:將更新分解為若干小批次,逐步推送。
2.4 極速響應階段:發布后的守護
產品上線后,仍需保持高度警惕,進入”極速響應”階段。發布后的一周內,項目團隊應預留充足時間,專門處理用戶反饋,適用于各類產品,無論是大眾網絡服務、平臺產品,還是企業級解決方案。
成敗關鍵不在于問題是否出現,而在于問題解決的速度。
評估產品表現應該使用明確的、可量化的指標,最終取決于商業目標。并且,為每個指標確定優先級,保持持續的關注。對于什么樣的結果代表成功或者失敗,做到心里有數。
- 大眾網絡服務:借助免費或開源數據分析工具,實時監測產品性能。
- 企業級服務:提供現場安裝支持,迅速響應并解決客戶遇到的問題。
本文由 @萌沐 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!