@NguyenNn1 Chị share một xíu góc nhìn của chị hen~~ hy vọng giúp ích được cho em <3
1/ Có nên quay lại làm full discovery từ đầu?
team đã chốt idea và bắt tay vào làm rồi ạ.
Đầu tiên thì chị thấy point này “team đã chốt idea và bắt tay vào làm rồi ạ.” hơi imply là chốt rồi thì không reverse được 
Nhưng thực tế sẽ không bao giờ thực sự có chốt ideas, mà nó chỉ là chốt idea ở ver 1, ver 2, ver 3, và hoàn toàn có thể take bất kỳ input nào để iterate cho vòng tiếp theo (bản chất của agile trong Lesson 8, tụi chị có share online video)
“full discovery từ đầu”
2 quá trình discovery và delivery nó cũng không đi từng phase tách bạch theo kiểu linear ấy, mà em sẽ luôn làm tụi nó song song. Discovery không nhất thiết phải là “full discovery từ đầu” như em nói, mà mình cứ chia 2 nhóm thui, các bạn dev cứ ship, còn em cứ discovery phần em chẳng hạn.
Discovery thì cũng có nhiều hướng tiếp cận, em có thể discover from scratch hoặc discover dựa trên giả thiết mà team có. VD đây là một giả thiết:
“Ý tưởng của team thì xuất phát khá tự nhiên, trong lúc trò chuyện, các bạn nhận ra chưa có một nền tảng nào hỗ trợ việc lên kế hoạch đi chơi một cách trọn vẹn, nên quyết định thử bắt tay vào làm.”
Em có thể validate lại vấn đề này có thật không, thật trong hoàn cảnh nào, tại sao “nền tảng hỗ trợ việc lên kế hoạch trọn vẹn” lại là giải pháp tốt nhất.
All in all, sản phẩm có thể bắt đầu từ đâu đó:
- bắt đầu từ discovery thì có thể là em có giả thiết mạnh hơn,
- bắt đầu từ delivery cũng oke luôn nếu em biết cách scope đủ hợp lý để launch nhanh và lấy feedback từ thị trường (balance giữa resources và rủi ro), hay chỉ đơn giản ship ra cái gì đó thì revisit lại cuộc nói chuyện ban đầu “trong lúc trò chuyện, các bạn nhận ra chưa có một nền tảng nào hỗ trợ việc lên kế hoạch đi chơi một cách trọn vẹn, nên quyết định thử bắt tay vào làm.” để xem sản phẩm đã giải quyết dc vấn đề đó chưa, thực sự chính tụi em có xài hay không.
- cái quan trọng là em phân biệt được đâu là sự thật (có data point back cho nó, kể cả 1 data point từ em thì cũng ok miễn là em khách quan và không lừa chính mình) và đâu là giả thiết trong quá trình em làm, và em tìm cách tìm kiếm sự thật để validate/invalidate giả thiết của em.
Hiện giờ tụi em có gì rồi thì có thể evaluate từ điểm đó trở đi để inform lại bước tiếp theo. Những plan delivery nào đang tốn nhiều effort nhưng được plan dựa trên giả thiết không cứng hoặc rủi ro cao có thể tạm pause lại để validate thêm. Các yếu tố để cân nhắc cho quyết định: nguồn lực, rủi ro/bất định.
2/ Nếu trong quá trình interview/empathy em phát hiện ra JTBD hoặc hướng đi khác với những gì team đang định làm, thì nên xử lý thế nào để vừa giữ đúng định hướng sản phẩm, vừa không làm team member nản?
Chị nghĩ “nản” hay không là do khoảng cách giữa expectation vs reality. Khoảng cách xa quá thì nản là chuyện bình thường.
VD của expectation hợp lý dựa trên data thật:
-
95-99% startup và idea đều thất bại, khả năng cao mình cũng sẽ thất bại, hoặc thành công là cực kỳ bất định.
-
Nếu biết outcome là cực kỳ bất định thì mình chỉ nên có kỳ vọng hợp lý về input/output: mình sẽ dùng cái này làm cơ hội thử sai để học đc gì đó, mình blog lại quá trình thử sai này để kể cả thất bại cũng có cái để showcase cho cơ hội tiếp theo, etc.
-
etc.
Nếu từ đầu expectation không hợp lý (VD: ý tưởng này sẽ thành công, mình sẽ kiếm dc X dollars, etc.) thì chuyện nản chắc chắn sẽ xảy ra.
Chị nghĩ đây là lúc team nên ngồi lại với nhau và chia sẻ thẳng thắng kỳ vọng muốn đạt được từ project này là gì, có hợp lý với thực tế đang diễn ra không, mọi người muốn đi tiếp như thế nào cho bền vững (VD: giữ effort vừa đủ để làm chuyện khác song song, quyết tâm all in trong 6 tháng không ra metrics gì thì dẹp làm chuyện khác, etc.)
3/ Với một team nhỏ và còn non kinh nghiệm, làm sao để cân bằng giữa tính thực tế (khả năng triển khai được) và việc xây dựng một sản phẩm thật sự có giá trị cho user
Cơ bản 2 yếu tố em nói “giữa tính thực tế (khả năng triển khai được)” và “việc xây dựng một sản phẩm thật sự có giá trị cho user” nó không conflict nhau chuyện làm được hay không thì chắc quay lại năng lực và commitment của team với nhau và với dự án.
Team nào cũng sẽ bắt đầu từ đâu đó, non kinh nghiệm thì làm dần sẽ có kinh nghiệm. Chị nghĩ quan trọng nhất vẫn là hiểu rõ tụi em muốn gì từ project này, sẵn sàng bỏ bao nhiêu resources (eg. thời gian, năng lượng, chi phí cơ hội, đi kêu gọi giúp đỡ, etc.), cả team có align trên những yếu tố đó không, cơ cấu team có ‘tạm’ cover đủ các khía cạnh end-to-end của dự án không (eg. discovery, delivery, go-to-market, iterate, etc.) hoặc có sẵn sàng học thêm để đủ không, có thể set ra những milestone để evaluate khi X xảy ra thì Y sẽ xảy ra (VD: nếu project này kiếm dc 20tr/tháng trong 1 năm thì team sẽ làm tiếp, nếu làm mọi cách mà sau 6 tháng không có users thì team dừng lại, etc.)
“Mục tiêu của tụi em không phải làm app cho vui hay nội bộ dùng với nhau, mà là mong có thể xây dựng một sản phẩm có user thật và giải quyết được nhu cầu thật ạ. Nên em thật sự rất mong nhận được ý kiến từ những anh/chị đã đi trước ạ.”
Mục tiêu này thì không có gì sai nhưng nó đang hơi selfless và chị không sure nó sustain được bao lâu :))) chị nghĩ team nên đặt mục tiêu thực tế hơn, selfish hơn, hoặc thẳng thắn với nhau và thẳng thắn với chính mình hơn là mọi người muốn gì cho bản thân từ project này, đừng muốn cho thiên hạ nữa.
Chị thấy kể cả “làm app cho vui hay nội bộ dùng với nhau” thì nghe nó vẫn bền vững hơn là làm cho thiên hạ á :))) vì ít nhất em có niềm vui từ đó, chứ what’s the point của việc stress lên stress xuống để tạo ra giá trị cho người khác, nghe quá noble và thấy hông bền vững xíu nào :)))
