@daphtd Dạ chị Daphne ơi, em có tìm hiểu một số bài thi Product Case và thấy mọi người thường dùng “hypothesis”, nhưng có 2 cách tiếp cận hơi khác nhau trong việc đặt hypothesis (trong bối cảnh giải case cải tiến hoặc thêm feature cho sản phẩm đã có sẵn):
Một số bạn đặt hypothesis ngay từ bước xác định vấn đề (dựa trên đề bài), sau đó mới đi research thị trường, competitor… để kiểm chứng lại hypothesis đó.
Một số bạn khác lại làm research trước (market, user, competitor…), rồi sau đó mới đưa ra hypothesis và đi tới solution/feature.
Ngoài ra em cũng tham khảo được một flow như sau:
Research sơ bộ (market, competitor, problem) → Hypothesis → Research user (interview) để validate hypothesis → Chốt problem → Đề xuất solution + feature.
Dạ chị có thể giúp em nhận xét xem flow này đã hợp lý chưa và nên điều chỉnh như thế nào cho đúng hướng làm Product Case không ạ?
(tin nhắn của Hoàng Diệu, được repost từ Discord community của Khoá học BPM 7 tuần)
chị thấy cả 2 cách tiếp cận đều sẽ có pros and cons nhen. nhưng mà một trong những nền tảng quan trọng là “Hypothesis” của em xuất phát từ đâu, nền tảng mạnh không, đã có evidence hòm hòm hay trigger từ đâu để hình thành chưa hay chỉ là ‘cảm giác’ 'em nghĩ/em tưởng". nếu chị đánh giá sơ bộ thì:
cách 1.
pros: thu hẹp được vấn đề khai phá, hợp cho trường hợp bị giới hạn thời gian (consulting case, cuộc thi, etc.).
cons: đâu biết hypothesis có khách quan hông, có bias cá nhân hog, rùi cố tình cherry pick dẫn chứng để validate/thay vì reject.
không friendly cho các bạn beginner ở chỗ có thể bị điểm mù về bias cá nhân.
cách 2.
pros: không có bias cá nhân nào, research ra thông tin gì (grounded) thì mình triển khai từ thông tin đó.
cons: có thể siêu to khổng lồ mất định hướng nếu các bạn chưa có bộ evaluation criteria hay north star metrics nào để định hướng di chuyển.
không friendly cho các bạn beginner ở chỗ nó quá rộng, sẽ khá rối và khó navigate.
flow này của em thì chị thấy hợp lý để bắt đầu ùi ó.
Research sơ bộ (market, competitor, problem) → Hypothesis → Research user (interview) để validate hypothesis → Chốt problem → Đề xuất solution + feature.
thực tế thì chị nghĩ cũng ko có rigid flow nào đâu, mình định hình được hướng nào đó nhưng giữ tâm thế cởi mở sẵn sàng accept/reject hướng đó hoặc đổi hướng khác, rùi cứ có data feed vào thì mình iterate thêm nè.
