Đặt vấn đề

Có bao giờ bạn gặp một trong các trường hợp sau đây:

Bạn release một sản phẩm ra thị trường và nó đã lỗi thời lúc bạn release
Bạn release một sản phẩm, và người dùng không thèm sử dụng.

Nếu bạn gặp vấn đề trên, hãy học bài viết này, nếu không bạn hãy đọc các bài viết khác trong website của mình www.phamduytung.com

Lưu ý nhỏ: Đây là mindset, không phải là toolset, nên chúng ta cần thực hành nó, cần sự trải nghiệm trong câu “kiến thức, kinh nghiệm, trải nghiệm” thì mới thấm dần dần được. Tại thời điểm viết bài viết này, mình chỉ có một xíu xíu trải nghiệm như vậy, có thể qua vài năm nữa, trải nghiệm của mình sẽ khác đi, và mình sẽ viết bài viết khác để cập nhật sự trải nghiệm của mình.

Mở bài

Từ trước tới nay, chúng ta thường vô tình bị đóng trong cái khung tư duy project, đặc biệt là các bạn trưởng thành từ freelancer. Hầu hết chúng ta là “lính đánh thuê”, với kiểu làm dự án A trong vòng 3 tháng, xong , lụm tiền. Nhảy vào dự án B, làm, lụm tiền. … cho đến khi bạn ra ngoài khởi nghiệp với một ý tưởng hay ho nào đó, hoặc bạn vào công ty product làm chỉ đúng 1 product.

Project là gì

Các dự án, theo định nghĩa, là những nỗ lực tạm thời. Một tập hợp các cá nhân và tổ chức đảm nhận các nhiệm vụ cần thiết để đạt được một mục tiêu cụ thể. Có một lịch trình, ngân sách, điểm khởi đầu và điểm cuối. Tiến độ của dự án được đo lường và kết thúc sau khi đạt được các mục tiêu và cột mốc định trước.

Nói tóm lại, một dự án bắt đầu với một kết luận được xác định rõ ràng và được hiểu rõ. Từ đó, nhóm phấn đấu để tránh đi chệch khỏi kế hoạch hoặc lịch trình. Các bên liên quan biết điều gì sẽ xảy ra, khi nào và chi phí bao nhiêu.

Product là gì

Sản phẩm là mối quan tâm liên tục. Mục tiêu của sản phẩm không phải là khi nào nó kết thúc. Các tổ chức sẽ sử dụng nghiệp vự tối ưu hoá của mình để cực đại hoá lợi nhuận và các KPIs liên quan, bằng cách phân tích mức độ sử dụng (usage), sự tăng trưởng (growth), và sự trung thành của người dùng (loyalty)

Một sản phẩm mới có thể là kết quả của một dự án hoặc nhiều dự án, nhưng sau khi sản phẩm được giới thiệu, vẫn có nhiều cải tiến và cập nhật lặp đi lặp lại. Công việc của nhóm sản phẩm sẽ không bao giờ kết thúc chừng nào sản phẩm vẫn còn trên thị trường.

Tóm lại, các sản phẩm liên tục phát triển dựa trên các bài học, phản hồi, sự thay đổi của thị trường ° và các nguyên tắc cơ bản về tài chính °° (financial fundamentals). Luôn có chỗ để cải tiến, nâng cao và mở rộng sang các thị trường và trường hợp sử dụng mới.

° Ví dụ như covid ập tới, chúng ta phải làm gì

°° Ví dụ như thuế gtgt giảm từ 10% xuống 8%

Đối với các nhóm khởi nghiệp, sản phẩm hiếm khi nào hoàn thành ngay lập tức ( trừ một số trường hợp đặc biệt). Hầu hết chúng ta thường đưa ra thị trường một bản thăm dò thị trường (có thể có 1 hoặc nhiều phrases, mỗi pharse sẽ hoàn thiện một tính năng nào đó) để đánh giá.

1. Một số hướng dẫn để chuyển tư duy từ project mindset sang product mindset

1.1 Tạo ra các team sản phẩm nhỏ

Nếu team member là coder , thua. Chúng ta đều có chính kiến, đều có niềm tự hào, đều có suy nghĩ , đều có ý tưởng | giải pháp “điên rồ” cho một vấn đề nào đó.

Có một tầng nhu cầu trong tháp nhu cầu maslow gắng liền sâu xa với cái này, mình cảm thấy vậy.

1.2 Đón nhận sự thay đổi và chấp nhận sự thích nghi

Tư duy sản phẩm bắt nguồn từ việc tạo ra trải nghiệm độc đáo cho người dùng dựa trên việc học hỏi và phản hồi. Để thúc đẩy môi trường này, nhóm phải luôn cởi mở để thường xuyên điều chỉnh kế hoạch… và đôi khi loại bỏ chúng hoàn toàn.

1.3 Đừng dí dealine

Áp lực tạo ra kim cương, tạo ra sự đột phá hay áp lực tạo nên tâm lý sợ hãi, cuộc sống bế tắc, chán nản, sợ ngày chủ nhật, sợ ngày X phải release sản phẩm ….

Tuỳ

1.4 Đừng cố gắng bấu víu vào ý tưởng đầu tiên

Tư duy của product là tư duy mở, đón nhận những sự thay đổi một cách liên tục, cho nên sản phẩm khi hoàn thành đến tay người dùng nó có thể đi xa một vạn tám ngàn dặm so với ý tưởng ban đầu của mình rồi.

1.5 Cố gắng gắng kết roadmap với mindset

Có một thứ gọi là Theme-Based Roadmap được sử dụng trong tư duy product. Nó sẽ được sử dụng để thay thế cho feature roadmap

2. Một số kinh nghiệm về product mindset

2.1 Trao giá trị, không trao tính năng

Hầu hết, người dùng không cần tới những tính năng, họ cần những thứ mà có thể giải quyết được vấn đề của họ. Chúng ta cần thực sự hiểu được giá trị thực sự mà những thứ chúng ta làm ra sẽ mang lại gì cho người dùng, lúc đó, team sẽ thực sự hiểu tại sao cần phải làm nó và đó mới là sản phẩm có ích.

Để trao được các giá trị có ích, team member cần biết được vấn đề là gì. BA hoặc PO hoặc PM phải hiểu được việc cần làm mang lại giá trị gì. Dev cũng cần hiểu “vấn đề là gì” để đưa được các lập trình phù hợp và có thể góp ý ngược lại cho BA.

Nếu dev chỉ hiểu tính năng -> BA cực -> DEV yêu cầu BA mô tả phải thật sự rõ ràng. (dev lúc này chỉ là ông coder)
Nếu phương án của BA không hợp lý -> vấn đề chưa được giải quyết trọn vẹn.
Tam sao thất bản giữ các lần trao đổi , từ đối tác => Sale => BA => Dev -> Dev cần có mặt trong các cuộc thảo luận của BA với khách hàng, với sale (cái này hơi khó, nhất là khi làm dự án với đối tác Nhật)
Thiếu định nghĩa / mô tả rõ ràng về việc hoàn thành tính năng -> bem nhau -> toang.

2.2 Phát triển sản phẩm dựa trên dữ liệu (Data Driven development)

Data Driven là một thuật ngữ kinh doanh đề cập đến việc sử dụng dữ liệu để cung cấp thông tin giúp bạn ra quyết định nhanh hơn. Nói cách khác, quyết định được đưa ra với bằng chứng thực nghiệm thực tế chứ không phải suy đoán hoặc kinh nghiệm cá nhân.

Data driven là thứ bắt buộc phải làm để có thể xây dựng sản phẩm thành công. Mọi thứ cần được đo đạc ở tất cả các khâu, và là nền tảng của việc ra quyết định.

Việc đánh giá một tính năng có hoàn thành hay không cũng phải dựa vào con số, phải định lượng được, không thể phan bừa phán bậy được. Nếu chúng ta không định lượng được kết quả bằng một con số cụ thể thì việc ta có làm hay không làm sẽ chẳng khác gì nhau cả.

Chúng ta cần chọn thang đo để đánh giá, nếu chọn sai thang đó thì giá trị của dữ liệu rất thấp. Thang đo phải được đánh giá rất cần thận để có được dữ liệu có giá trị. Dữ liệu cần được đặt trong một ngữ cảnh cụ thể thì mới phát huy được hết giá trị của dữ liệu. Còn nếu không có ngữ cảnh, thì dữ liệu đó cũng chỉ là dữ liệu rác mà thôi.

Thang đo này sẽ sử dụng các giá trị chúng ta đã thu thập ở trên, để đưa ra nhận xét.

Ví dụ kinh điển: Khi cần dev một sản phẩm mobile mới mang lại giá trị ABCD … cho khách hàng, team dev bị vướng vào bài toán, chọn react-native, hay flutter, hay kortin + swift …

Để đánh giá, chúng ta cần phải xây dựng một thang đo dựa trên dữ liệu định lượng. ví dụ công nghệ có ổn định? có nhiều thư viện hỗ trợ?, có cộng đồng mạnh? có group telegram lớn hơn 100 ngàn dev , có tay to ở sau chống lưng, ….

2.3 Tập trung vào sản phẩm

Cái khác hàng mong muốn là là sản phẩm, là giá trị, khách hàng không quan tâm công sức chúng ta bỏ ra là bao nhiêu, chúng ta đã tối ưu code bằng giải thuật này giải thuật nọ, chúng ta sử dụng công nghệ A, công nghệ B,… hầm bà lằng.

Nói một cách hơi phũ, công nghệ có tốt tới mức nào mà không giải quyết dược vấn đề của khách hàng thì nó là vô nghĩa. Bản thân mình cũng hay bị chú tâm quá mức vào công nghệ, kéo dữ liệu, kéo source code về để thử tính năng này , chức năng kia, bla, bla, bla, mà không nhận thức rằng nó không phải là mối quan tâm đầu tiên. Ở đây mình cần mở ngoặc một chút là nếu công nghệ đưa ra mà tạo ra giá trị lớn thì lúc nào cũng được welcome.

Phát triển UX

Một sản phẩm tốt mà có UX tồi thì cũng khó có khả năng lôi kéo, giữ chân khách hàng, cái này để lại cho các bạn trải nghiệm để mời ông Designer vào :)

2.4 Minimum Viable Product

Minimum Viable Product MVP, là một sản phẩm có đủ tính năng để thu hút khách hàng chấp nhận sớm và xác nhận ý tưởng sản phẩm sớm trong chu kỳ phát triển sản phẩm. Trong các ngành công nghiệp như phần mềm, MVP có thể giúp nhóm sản phẩm nhận được phản hồi của người dùng càng nhanh càng tốt để lặp lại và cải thiện sản phẩm.

Eric Ries, người đã giới thiệu khái niệm MVP như một phần của phương pháp Lean Startup của mình, mô tả mục đích của MVP theo cách này: Đây là phiên bản của một sản phẩm mới cho phép một nhóm thu thập số lượng tìm hiểu tối đa được xác nhận về khách hàng với ít nỗ lực nhất.

Một công ty có thể chọn phát triển và phát hành một sản phẩm khả thi tối thiểu vì nhóm sản phẩm của họ muốn:

Phát hành sản phẩm ra thị trường càng nhanh càng tốt
Thử nghiệm ý tưởng với người dùng thực trước khi cam kết ngân sách lớn cho sự phát triển đầy đủ của sản phẩm
Tìm hiểu những gì cộng hưởng với thị trường mục tiêu của công ty và những gì không

Ngoài việc cho phép công ty của bạn xác nhận ý tưởng cho một sản phẩm mà không cần xây dựng toàn bộ sản phẩm, MVP cũng có thể giúp giảm thiểu thời gian và nguồn lực mà bạn có thể cam kết

Các xác định Minimum Viable Product

Làm thế nào để bạn phát triển MVP và làm thế nào để nhóm của bạn biết khi nào bạn có MVP sẵn sàng ra mắt? Dưới đây là một vài bước chiến lược cần thực hiện.

Đảm bảo MVP theo kế hoạch phù hợp với mục tiêu kinh doanh

Trước khi cân nhắc những tính năng nào cần xây dựng, bước đầu tiên trong việc phát triển MVP là đảm bảo sản phẩm sẽ phù hợp với mục tiêu chiến lược của nhóm hoặc công ty bạn.

Những mục tiêu đó là gì? Bạn đang làm việc hướng tới một con số doanh thu trong sáu tháng tới? Bạn có nguồn lực hạn chế? Những câu hỏi này có thể ảnh hưởng đến việc liệu bây giờ có phải là lúc để bắt đầu phát triển MVP mới hay không.

Ngoài ra, hãy hỏi mục đích của sản phẩm MVP này sẽ phục vụ gì? Ví dụ: nó sẽ thu hút người dùng mới trong một thị trường liền kề với thị trường cho các sản phẩm hiện có của bạn? Nếu đó là một trong những mục tiêu kinh doanh hiện tại của bạn, thì kế hoạch MVP này có thể khả thi về mặt chiến lược.

Nhưng nếu ưu tiên hiện tại của công ty bạn là tiếp tục tập trung vào các thị trường cốt lõi của bạn, bạn có thể cần phải gác lại ý tưởng này và thay vào đó, tập trung vào một MVP được thiết kế để cung cấp chức năng mới cho khách hàng hiện tại của bạn.

Bắt đầu xác định các vấn đề cụ thể mà bạn muốn giải quyết hoặc các cải tiến bạn muốn kích hoạt cho tính cách người dùng của mình.

Bây giờ bạn đã xác định kế hoạch MVP phù hợp với mục tiêu kinh doanh của mình, bạn có thể bắt đầu suy nghĩ thông qua các giải pháp cụ thể mà bạn muốn sản phẩm của mình cung cấp cho người dùng. Những giải pháp này, mà bạn có thể viết trong câu chuyện của người dùng, không đại diện cho tầm nhìn tổng thể của sản phẩm — chỉ là tập hợp con của tầm nhìn đó. Chúng ta chỉ có thể phát triển một lượng nhỏ chức năng cho MVP của mình.

Bạn sẽ cần phải có chiến lược trong việc quyết định chức năng hạn chế nào sẽ đưa vào MVP của mình. Bạn có thể dựa trên các quyết định này dựa trên một số yếu tố, bao gồm:

Nghiên cứu người dùng
Phân tích cạnh tranh
Bạn sẽ có thể lặp lại một số loại chức năng nhanh như thế nào khi nhận được phản hồi của người dùng
Chi phí tương đối để thực hiện các câu chuyện người dùng

Chuyển chức năng MVP của bạn thành một kế hoạch hành động phát triển.

Bây giờ bạn đã cân nhắc các yếu tố chiến lược ở trên và giải quyết chức năng hạn chế mà bạn muốn cho MVP của mình, đã đến lúc chuyển điều này thành một kế hoạch hành động để phát triển.

Lưu ý: Điều cần thiết là phải ghi nhớ chữ V trong MVP — sản phẩm phải khả thi. Điều đó có nghĩa là nó phải cho phép khách hàng của bạn hoàn thành toàn bộ nhiệm vụ hoặc dự án và cung cấp trải nghiệm người dùng chất lượng cao. MVP không thể là giao diện người dùng với nhiều công cụ và tính năng được xây dựng dở dang. Nó phải là một sản phẩm hoạt động mà công ty của bạn sẽ có thể bán.

Ví dụ các công ty khởi nghiệp với Minimum Viable Product

Có hai ví dụ kinh điển thường được nhắc tới, đó là:

Airbnb

Khởi đầu việc kinh doanh với một số vốn ít ỏi, các nhà sáng lập Airbnb đã sử dụng chính những căng hộ của họ để kiểm chứng ý tưởng của họ để tạo ta market offering short-term, peer-to-peer rental housing online (mình để từ tiếng anh ở đây , là từ khoá cho các bạn tham khảo). Họ tạo ra một trang web rất tối giản, quăng lên đó hình và chi tiết về ngôi nhà của họ, và gần như ngay lập tức, đã có khách hàng trả tiền cho dịch vụ của họ.

Giả sử trong trường hợp vài tháng sau không có ai thuê nhà, các nhà sáng lập Airbnb sẽ làm gì tiếp theo nhỉ? :) :)

Foursquare

Foursquare là một mạng xã hội được sáng lập năm 2009, được ra đời với một MVP duy nhất: “offering only check-ins and gamification rewards” - check-in -> kiểm điểm -> nhận thưởng.

Nhóm phát triển Foursquare bắt đầu thêm vào các tính năng recommendations, city guides đến khi nọ kiểm chứng dược ý tưởng của mình, thước đo của kinh doanh là sự tăng trưởng của người sử dụng dịch vụ.

Tài liệu tham khảo

Cảm ơn các bạn đã theo dõi bài viết, hẹn gặp lại ở các bài viết tiếp theo

Tư Duy Làm Sản Phẩm - The Product Mindset