Đảo ngược thứ tự Feasibility cho bài toán AI và xác lập ngưỡng chấp nhận
Giải mã lý do giả định khả thi truyền thống sụp đổ trước bài toán AI, đảo ngược chu trình thẩm định (Feasibility đi trước) và hiệu chỉnh UX theo xác suất thực tế.
Đảo ngược thứ tự Feasibility cho bài toán AI và xác lập ngưỡng chấp nhận
Product Manager truyền thống luôn thuộc nằm lòng bộ ba tiêu chuẩn thẩm định sản phẩm của IDEO: Desirability (Người dùng có muốn không?), Viability (Có mang lại hiệu quả kinh doanh không?), và Feasibility (Chúng ta có xây dựng được không?). Với phần mềm thông thường, Feasibility gần như luôn là câu trả lời "Có" nếu cấp đủ nhân lực kỹ thuật. Do đó, PM có thói quen thẩm định Desirability và Viability trước, rồi mới chuyển yêu cầu cho đội ngũ Engineering.
Tuy nhiên, với các sản phẩm AI, mô hình tư duy này hoàn toàn sụp đổ.
Ví dụ xuyên suốt bài: Đội ngũ sản phẩm FinTrack Logistics đánh giá tính năng "Tự động ước lượng thời gian giao hàng (Estimated Time of Arrival - ETA) theo thời gian thực" và dự án "Tự động duyệt bồi thường thất lạc hàng hoá dưới 2 triệu đồng".