Phát triển sản phẩm
-
-:
- Bởi vì sản phẩm có tính quy hồi và có thể là thành phẩm chung của nhiều sản phẩm lớn hơn, nên để quản lý được nó ta phải biết lập trình
- Design thinking bắt đầu từ một đề bài. Nhưng đề bài được ra thế nào thì không nói
- Có thêm nhân viên không làm sản phẩm phù hợp với thị trường hơn
- Dữ liệu chính là lập trình
- Insight trong phát triển sản phẩm gắn liền với việc thay đổi hành vi người dùng
- Ngôn ngữ của người dùng và ngôn ngữ của người cung cấp giải pháp có thể khác nhau
- Làm sản phẩm thiên về cảm giác, làm tăng trưởng thiên về dữ liệu
- Khi app có nhiều tính năng thì sẽ không biết một người dùng không vào là vì họ không tìm thấy tính năng họ cần hay là vì họ không biết app có tính năng họ cần
- Phân loại người dùng khi phát triển sản phẩm khác với phân khúc khách hàng
- Sản phẩm ra mắt 10 năm rồi cũng có thể không biết gì về người dùng
- Đặc điểm của quy trình phát triển sản phẩm truyền thống là bước nghiên cứu xem ý tưởng có đúng không luôn đến sau việc nghĩ ra được ý tưởng đó trước
- ❓Có nên làm tiếp thị khi mình chưa làm nghiên cứu người dùng không
- ❓Với một sản phẩm demo còn nhiều lỗi vặt thì có cần phải hoàn thiện những lỗi vặt đó trước khi hỏi ý kiến khách hàng không?
-
Chỉ số:
- Chỉ theo đuổi một chỉ số là quá đơn giản
- Dựa vào KPI thì bộ phận kinh doanh sẽ có tiếng nói lớn nhất, còn đội phát triển sản phẩm rất ít có tiếng nói
- Phân tích quyết định đa tiêu chí (MCDA) là phương pháp để tìm điểm đánh đổi tối ưu nhất
- Chỉ số ta theo đuổi phải là chỉ số về giá trị của sản phẩm đối với người dùng
- Chỉ nên nghĩ về viral khi đã có một lượng người thực sự sử dụng sản phẩm của mình
- Tăng trưởng của thị trường quan trọng hơn tăng trưởng doanh số
- Tăng trưởng là khoảng cách giữa chuyển đổi và rời bỏ
- Tỉ lệ quay lại là thứ quan trọng nhất trong tăng trưởng
- Đừng dùng chỉ số sao bắc cực, hãy dùng chỉ số hải đăng
- NPS trên 50% là đạt được sản phẩm phù hợp thị trường
-
Kiểm định giả thuyết:
- Có quá nhiều điều cần kiểm chứng nhưng dù muốn đi tìm cũng không ai chịu dành thời gian để trả lời
- Giả định có mặt ở khắp nơi
- Hãy liệt kê những niềm tin trước khi phỏng vấn
- Hệ thống giả thiết ban đầu dễ khiến ta bỏ qua việc kiểm chứng niềm tin, hoặc kiểm chứng bằng những câu hỏi định hướng
- Việc kiểm định giả thuyết thường bị bỏ qua khi có quá nhiều việc
- Sử dụng nhiều phương pháp khác nhau để kiểm tra giả thuyết sẽ tránh thiên kiến tốt hơn là dùng một phương pháp nhiều lần
- Để có thể thiết kế một giải pháp một cách nhanh chóng và tự tin, ta cần được thử nghiệm ý tưởng mới và kiểm tra giả thiết ngay khi chúng vừa được nghĩ ra
- Đừng chạy theo tính năng, mà hãy xác định vấn đề cần ưu tiên giải quyết và nhanh chóng kiểm tra các giả thuyết
-
Quan niệm, thái độ, hành vi của người dùng:
-
Sắp xếp độ ưu tiên:
- Bảng quan trọng – khẩn cấp
- Bỏ công đi học lập trình thì không đáng, nhưng không biết thì sẽ rất lệ thuộc vào người khác
- Lý do mọi người hay gặp nước đến chân mới nhảy, không giải quyết chuyện quan trọng khi vấn đề còn nhỏ là vì ta không có đầu óc để nghĩ đến nó
- Có người giới thiệu về vấn đề có lẽ là cách duy nhất để làm được những thứ mình muốn làm nhưng không khẩn cấp
- Muốn thấy được những vấn đề lớn cần sự thong thả
- Số lượng vấn đề tìm ra trong 1 buổi có thể nhiều hơn số lượng vấn đề có thể giải quyết trong 1 tháng
- Việc nghĩ về sản phẩm lôi cuốn hơn việc nghĩ về thành quả rất nhiều
- Vấn đề ngắn hạn hay dài hạn không quan trọng, quan trọng là làm cái này mà phải nghĩ về cái khác thì sẽ nhức đầu
- Ý tưởng sinh ra không theo độ khẩn cấp
- When someone’s taking time to do something right in the present, they’re a perfectionist with no ability to prioritize, whereas when someone took time to do something right in the past, they’re a master artisan of great foresight
- Điều quan trọng thì thường hiếm khi khẩn cấp, và điều khẩn cấp thì thường hiếm khi quan trọng
Cập nhật lần cuối :
27 tháng 11, 2023
Tạo : 16 tháng 10, 2023
Tạo : 16 tháng 10, 2023