Quản lý dự án, phát triển sản phẩm, xây dựng tổ chức
-
-:
-
Các câu hỏi:
- Ai là người nên được nhận hỗ trợ？
- Biết rằng một người phải đi làm để kiếm tiền, nhưng tại sao họ lại phải cảm thấy có trách nhiệm nếu phải làm một thứ họ cảm thấy hứng thú？
- Các cấp độ theo dõi một cá nhân？
- Chốt lịch cố định hay hỏi lịch rảnh mỗi tuần？
- Các dự án giáo dục đo lường mức độ thành công của mình thế nào？
- Các dự án nghiên cứu điền dã thuyết phục nhà tài trợ thế nào？
- Các dự án sắp xếp thời gian thế nào？
- Có cần phải ra hạn chót cho công việc ko
- Có những cách nào để các thành viên tự chủ động đề ra mục tiêu cho công việc của mình？
- Có lý do gì để các dự án xã hội không công bố PKM của mình
- Có nên công khai tài liệu nội bộ cho người ngoài？
- Khi chưa có hiểu hết thì có nên làm dự án thay đổi xã hội không？
- Cần bao nhiêu thời gian để xây dựng một cộng đồng？
- Khi chưa tìm hiểu hết thì có nên đưa ra quan điểm không
- Khi nào một chuyên gia về một lĩnh vực không hào hứng nói về lĩnh vực họ thành thạo？
- Khi nào một người cần và họ sẽ đóng góp, và khi nào họ thấy rất cần nhưng họ cũng không đóng góp？
- Làm sao để biết việc mọi người vẫn có thể làm thong thả như không hề có hạn chót mà vẫn có mốc thời gian cho công việc sẽ làm？
- Mối quan hệ giữa thành viên nòng cốt, động lực nội sinh của tnv và sự hứng thú của những người theo dõi
- Những người làm dự án lâu năm có vẫn thường xuyên gặp bất ngờ với độ phản ứng của thị trường không
- Nếu cảm thấy mình nhận được nhiều thì tại sao không cảm thấy hứng thú？
- Nếu TNV đã chủ động nộp đơn vào rồi, thì tại sao họ lại không có sự chủ động？
- Mỗi người làm một việc thì có cần phải quan tâm tới thành viên khác không
- Sẽ xảy ra chuyện gì nếu TNV không quan tâm lắm đến chiến lược và sự khả thi của tổ chức？
- Nếu đã tag rồi mà không trả lời thì có nên hiểu là họ không hứng thú, và mình thôi không cần tag nữa không？
- Số lượng người tham gia tối thiểu, tối đa để cuộc họp có hiệu quả？
- Tại sao các bài dịch không được ủng hộ lắm, mặc dù bài viết tổng thì được nhiều người share？
- Tính quyết định trực tiếp mà không hỏi lại ý kiến mọi người
- Tại sao không nên giải thích khi nhận sự chỉ trích
- Tại sao sự tò mò không biết nó sẽ trông như thế nào là chưa đủ để một người đóng góp cho nó？
- Tại sao tỉ lệ tương tác online kém, nhưng các bạn vẫn trả lời là hứng thú tham gia các buổi họp？
- Tại sao việc cập nhật trên Notion không làm cảm giác hiệu quả？
- Tại sao việc hướng đến động lực nội sinh là không đủ để tạo ra các ưu điểm của sự kỷ luật？
- Tại sao có những người xin vào làm tình nguyện điền đơn thấy nhiệt tình nhưng sau một buổi nói chuyện thì xin rút hoặc không trả lời？
- Tại sao việc thường xuyên tham gia vào các buổi họp nhóm không tạo cảm giác mình thuộc về nhóm？
- Việc không nhận được sự phản hồi sẽ đem đến những hệ quả gì？
- Việc phân loại các nhu cầu thành từng nhóm có giúp
- Tại sao việc phát triển bản thân thì lại có thể không vui？
- Điều gì khiến cho những dự án không thể đi đến mức cuối cùng？
- Vì sao khi chưa tìm hiểu hết chúng ta đã có thể có quan điểm ngay rồi？
- Động lực làm việc không liên quan đến sự khuếch tán trách nhiệm？
- Khi nào thì một người thấy được mình có thể giúp người khác nhưng lại không có hứng thú giúp？
-
Công việc:
- Agile dành cho sản phẩm thay đổi nhanh, và tập trung vào tốc độ và sự linh hoạt. Lean dành cho sản phẩm thay đổi chậm, và tập trung vào việc giảm lãng phí
- Công việc khai phá và công việc khai thác
- Công việc khai phá chính là việc nghiên cứu và quản lý kiến thức
- Dự án chủ yếu là các công việc khám phá. Chương trình chủ yếu là các công việc khai phá
- Nhiều khi vấn đề chỉ được phát hiện ra khi đến khâu triển khai ý tưởng
- Sau 2 tuần nên cập nhật những cái mới
- Mọi thứ nên được xây từ trên xuống, trừ lần đầu tiên
- Sự khám phá thực ra chỉ là lấy mẫu chứ không phải khám phá kiến thức
- ❓Chuyên gia là người có thể chỉ ra cho mình thứ mình không biết là mình cần
- Ta không lường trước được những công việc mình cần làm là gì trừ phi đã từng làm nó rồi
- Công việc chính là giải pháp
- Công việc và cuộc sống không thể tách rời nhau
- Cần nghĩ về công việc như là một cách để kiểm định giả thiết, chứ không phải chỉ để hoàn thành
- Công việc sẽ được gắn ở khắp nơi
- Insight through making
- Dự án chủ yếu gồm các công việc khai phá. Chiến dịch chủ yếu gồm các công việc khai thác
- làm sao để cân bằng giữa exploration và exploitation
- Bảng quan trọng – khẩn cấp
- 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
- 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
- Có những thứ ta biết là cần thiết nhưng không thể thấy thú vị nổi, thậm chí không thể đồng cảm nổi
- Giữa thời gian, chất lượng, chi phí, ta chỉ chọn được 2
- Có những cái ta cần làm trước khi ta thấy cần làm
- Khi một người dành thời gian làm một điều đúng trong quá khứ, họ là nghệ nhân bậc thầy với tầm nhìn xa trông rộng
- Muốn thấy điều không biết là mình không biết thì cần phải ở trạng thái khám phá
- Nhiều khi không chịu đi bán vì việc code tiếp sẽ có lợi hơn khi ta biết sản phẩm rồi sẽ cần phải được code tiếp
- 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
- Đừng ra quyết định khi bụng đói
- ❓Kết quả cuối cùng của MCDA có khác gì với tiền
- ❓Dù việc sử dụng phân tích quyết định đa tiêu chí vẫn là quy về một chỉ số, thì việc theo đuổi nó vẫn khác với theo đuổi một chỉ số thành phần, nên cũng không sợ nó quá đơn giản
- Muốn thấy được những vấn đề lớn cần sự thong thả
- Loạn chủ đề khi chat
- Việc nghĩ về sản phẩm lôi cuốn hơn việc nghĩ về thành quả cần có hơn nhiều
- Thay vì lập ra danh sách công việc, hãy thử lập ra danh sách không phải công việc xem
- 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
- Đ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
- Ý tưởng sinh ra không theo độ khẩn cấp
- ❓Sự khác biệt giữa việc thấy một thứ là có tiềm năng và cần thứ đó là gì
- 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
- 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ó
- Sự hoàn hảo và không phạm sai lầm
- Quản lý cuộc sống chính là quản lý dự án
- Thành quả mong muốn và giả định của một công việc tìm hiểu một vấn đề nào đó là chính nó
- Giải pháp gợi ý chính là thành phẩm
- Dự án là sản phẩm
- Mục tiêu, yếu tố hỗ trợ, ý tưởng tốt hơn. Mục tiêu, sản phẩm, hoạt động, tác vụ
- Nguồn lực bị tắt nghẽn tạo thành điểm đau
- Nói về nhu cầu thì thấy nghèo, nói về nguồn lực thì thấy giàu
- Nếu không có nhu cầu thì nguồn lực sẽ không di chuyển
- ❓Nhu cầu = impact = vấn đề = điểm đau = động lực = lý do bắt đầu = thành quả mong muốn nguyên thuỷ
- Các cấp trong tổ chức nên nói chuyện với nhau bằng thành quả
- Mọi thành quả mong muốn đều chứa trong mình những giả định
- Nhu cầu mà có định lượng sẽ là kết quả mong muốn
- Nhìn vào hành trình người dùng và xem coi hành vi nào giúp đạt được mong muốn của mình. Đó chính là thành quả mình cần hướng đến
- Sản phẩm là kết quả của các công việc
- Sản phẩm là sự bồi tụ của các dòng hải lưu nhu cầu và kết tinh của nguồn lực
- Sản phẩm là vùng đất
- Sản phẩm là vật thể
- Thành phẩm (output) là các kết quả trực tiếp của các công việc
- Một số thành phẩm sẽ có những thành quả mong muốn bên trong nó, nhưng thường chỉ là thành phẩm nhỏ hơn
- Thành quả (outcome) là kết quả thu được do sự thay đổi về hành vi của người dùng khi tương tác với sản phẩm đã được cải tiến hoặc sản phẩm mới
- Thành quả quan trọng hơn thành phẩm
- Thành quả phải có nhiều không gian để thay đổi
- Tiêu đề của thành quả mong muốn bắt đầu bằng người dùng
- Tầm nhìn = thành quả lớn nhất
- Tầm nhìn là thứ mình muốn có. Sứ mệnh là thứ mình sẽ làm. Sản phẩm là thứ mình tạo ra
- Một sản phẩm được tạo nên bởi nhiều thành phẩm. Thứ ta gọi là sản phẩm thành phần, hoặc sản phẩm nhỏ hơn, chính là thành phẩm
- Tầm nhìn là điều mình sẽ có khi tất cả mọi hoạt động của mình đều thành công
- Working on niche, personally-meaningful projects brings weirder, more serendipitous inbounds
- Đổi những câu hỏi chất vấn giả định của một thành quả về dạng khẳng định thì ta sẽ có những thành quả mong muốn thành phần
- ❓Một object khi chưa tồn tại mà ta muốn có nó thì nó là objective
- ❓Tại sao không gọi thẳng là kết quả từ sự thay đổi hành vi của người dùng？Dùng thành quả dễ gây nhầm lẫn cho người chưa biết
- ❝Mục tiêu❞ và ❝Kết quả❞ là những từ bao trùm
- Chỉ có thể ước lượng được thời gian cần có để hoàn thành khi công việc của ta gần như chỉ gồm công việc khai thác
- Cây quyết định và PERT dành cho những dự án chủ yếu gồm các công việc khai thác
- Gọi sự chú ý là tài nguyên là không chính xác, vì đa phần ta có thể sống thiếu tài nguyên, còn sự chú ý chính là sự sống
- Khi đã chuyển được nhiều thứ mình biết là mình không biết sang mình biết là mình biết, thì xác suất dự đoán chính xác thời gian hoàn thành sẽ tăng lên
- Lên lịch khối thời gian giúp cân bằng sự quan trọng và khẩn cấp
- Danh sách công việc chỉ là danh sách chờ. Để một công việc thực sự được tính đến, ta cần để nó vào lịch
- Mọi thứ sẽ luôn tốn thời gian hơn bạn nghĩ
- Nếu bạn nghĩ rằng bạn có thể hoàn thành đúng kế hoạch, có thể bạn đang ngộ nhận
- Quản lý công việc là quản lý thời gian
- Quản lý tác vụ chỉ có thể giải quyết khi nó kết hợp được lịch để time blocking
- Việc họp hành phá hỏng việc tạo sản phẩm
- Xong hạn chót này thì sẽ tới hạn chót khác
- Vì tôi không biết làm nên không được giao, nhưng vì không được giao nên càng không biết làm
- Áp lực giết chết sự sáng tạo
- Điều đã biết là đã biết được dùng để lên kế hoạch chính. Điều không biết là đã biết được dùng để lên kế hoạch dự phòng. Điều đã biết là không biết thì cần nghiên cứu thêm
- ❓Chỉ số sau và kết quả mong muốn của công việc thành phần có phải là một
- Từ thành quả mong muốn nghĩ ra công việc trước dễ hơn nghĩ ra giả định trước
-
Hệ thống thông tin:
- Các nhóm làm việc qua mạng ngày càng nhiều
- Các tổ chức thường chỉ lưu trữ kiến thức mà ít khi dành nhiều sự chú ý tới kết nối chúng
- Dữ liệu chính là lập trình
- Những gì ta viết thì nên được tự động được cấu trúc
- Việc quản lý công việc thường cần một cấu trúc
- Cấu trúc phân cấp thường cứng nhắc và nhân tạo
- Email không được sinh ra để trao đổi thông tin, mà là để làm todo list
- Dữ liệu dưới dạng văn bản phù hợp cho việc quản lý kiến thức
- Silo thông tin khiến cho những thao tác tự động hoá đơn giản không thể làm được
- CRM tập trung vào tăng sale, ERP tập trung vào cắt giảm chi phí
- ❓Tại sao không cho người chưa biết gì về CNTT học về cơ sở dữ liệu trước thay vì học lập trình trước？
- Việc lưu dữ liệu ở các công cụ khác nhau tạo thành các silo thông tin
- Các ERP được dựng sẵn không đủ khả năng đáp ứng những luồng làm việc và suy nghĩ đặc thù
- Các tiếp thị về no code hàm ý rằng việc code là việc khó nhất trong việc tạo sản phẩm, nhưng thực ra việc thảo luận và lên kế hoạch mới là thứ quan trọng nhất
- Dùng low code để xây dựng hệ thống là đang mang nợ kỹ thuật vào người
- Cái tên no code chỉ bình mới rượu cũ của GUI
- Excel dịch chuyển một phần quyền lực của chuyên gia IT vào người sử dụng
- Excel không cho ta quản lý phiên bản được
- Excel không cản ta làm điều mà ta sẽ hối tiếc
- Excel không phù hợp cho việc lập cơ sở dữ liệu
- Excel không làm ta hiểu về lập trình một cách đúng đắn
- Excel là loài gián trong ngành phần mềm
- Excel là một ngôn ngữ lập trình mà không làm ta cảm giác là đang lập trình
- Excel là nguồn ý tưởng cũng như là kẻ thù lớn nhất của các SaaS
- Excel là người bạn tuổi thơ tuyệt vời, nhưng là kẻ thù của tuổi dậy thì
- Excel đã làm một việc phi thường trong việc giáo dục hàng trăm triệu người về sức mạnh của phần mềm
- Excel là sản phẩm low code tồn tại lâu dài nhất
- File Google Docs không thực sự là file
- Lập trình viên khó chịu với hệ thống low code vì nó được tiếp thị như là một giải pháp hoàn hảo có thể giải quyết được mọi nhu cầu thực tế
- Sản phẩm no code không thể nào đáp ứng được nhu cầu tuỳ biến cao
- Sản phẩm no code đem đến sự phản hồi tức thời
- No code so với có code giống như so xe Lego so với ô tô thực sự
- Ghi chú thì linh hoạt, nhưng tĩnh. App thì cứng nhắc, nhưng động
- Quản lý công việc và quản lý kiến thức không thể tách rời nhau
- Sự khác biệt giữa các ứng dụng quản lý chủ yếu ở nghiệp vụ cần giải quyết chứ không nằm ở yếu tố kỹ thuật
- Ta được hứa hẹn sẽ có những chiếc xe đạp cho tâm trí. Thay vào đó ta lại có máy bay
-
Phát triển sản phẩm:
- An outcome is a change in human behavior that drives business results
- 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ỉ theo đuổi một chỉ số là quá đơn giản
- Chỉ số
- Các chỉ số đo lường thu nhập
- Con số không nói dối, nhưng nó nói nửa sự thật, và người nói dối dùng con số
- 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
- Khi một phép đo trở thành mục tiêu, nó thường mất đi sự hiệu quả của nó
- Mô hình phễu không xem khách hàng như là người cùng đồng hành với mình
- Nếu bạn không thể đo lường, bạn không thể cải tiến
- NPS trên 50% là đạt được sản phẩm phù hợp thị trường
- Thứ nào được đo thì sẽ tốt lên, còn thứ nào khó đo thì sẽ tệ đi
- Hệ số k đo lường số lượng người dùng mới mà mỗi người dùng cũ đem lại
- Tăng trưởng thị trường là khoảng cách giữa chuyển đổi và rời bỏ
- 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 thị trường quan trọng hơn tăng trưởng doanh số
- Tỉ lệ quay lại là thứ quan trọng nhất trong tăng trưởng
- ❓Có phải thứ quan trọng nhất là tìm được sản phẩm phù hợp thị trường không
- Đừng dùng chỉ số sao bắc cực, hãy dùng chỉ số hải đăng
- ❓Việc theo đuổi chỉ số sẽ không phải là vấn đề nếu người tạo ra chỉ số là người quyết định dự án hoặc không để quyết định con người
- ❓Việc theo đuổi các chỉ số ESG, phát triển bền vững có giúp làm điều tương tự không
- ❓Theo đuổi một bộ chỉ số thì không còn sợ là quá đơn giản nữa
- các công ty không quan tâm đến tính năng chuyên biệt
- 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
- 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
- Insight không dùng đi dùng lại
- Design thinking bắt đầu từ một đề bài. Nhưng đề bài được ra thế nào thì không nói
- 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
- 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 suy nghĩ độc lập, nhưng phản biện cùng nhau
- Hãy liệt kê những niềm tin trước khi phỏng vấn
- Nên so sánh nhiều ý tưởng cùng lúc hơn là đánh giá từng ý tưởng một
- Nếu người dùng nói cho mình nhu cầu của họ thì mình không cần phải đi khảo sát nhu cầu họ nữa, mình cũng không phải lo lắng xem giả định của mình có sai hay không
- 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
- Quan trọng là chứng minh được rằng điều mình làm thành công hay không, chứ không phải là tin rằng nó có thể thành công rồi mới làm
- Rất khó để kiểm chứng hết toàn bộ các giả định
- 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
- Việc kiểm định giả thuyết thường bị bỏ qua khi có quá nhiều việc
- Đừ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
- ❓Thu thập dữ liệu đến đâu là đủ
- Để 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
- 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
- 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
- Mô hình xoắn ốc nhấn mạnh vào phân tích rủi ro
- Biểu đồ cánh hoa phù hợp cho việc phân tích bối cảnh cạnh tranh ở một thị trường mới hoặc resegmented markets
- Biểu đồ cạnh tranh XY phù hợp cho việc phân tích bối cảnh cạnh tranh trên một thị trường đã có sẵn
- Tổng hợp các cách biểu diễn các bên liên quan
- Các mạng xã hội có những báo cáo về xu hướng của người dùng nền tảng của họ
- Biểu đồ cạnh tranh giúp ta có được những giả định đầu tiên về những khách hàng đầu tiên của chúng ta
- Giai đoạn lên ý tưởng thường khó khăn
- Các nghiên cứu có thể có cùng một mục tiêu nghiên cứu, nhưng khác nhau về câu hỏi nghiên cứu
- Ai cũng có một kế hoạch cho tới khi bị đấm vào mồm
- Những thứ không quan trọng có thể tự xử lý lẫn nhau
- Sự ghi chú tạm để để sau thôi cũng có khi tốn vài tiếng
- Nên ưu tiên làm những việc có thể sẽ khiến ta phải viết lại kế hoạch
- Việc lập kế hoạch là để giảm những hệ quả không lường trước được và tạo ra được sự bền vững dài hạn
- Việc ưu tiên ra quyết định nhanh làm ta thấy thảo luận và dành thời gian xây dựng kế hoạch và nghiên cứu là phí thời gian
- Để không bị đối thủ đấm vào mồm mà còn đấm được vào mồm hắn thì phải lên kế hoạch
- Việc bàn kế hoạch sẽ có nhiều chủ đề đâm ngang mà cũng phải bàn cho rốt ráo
- Idea là một cái gì đó để thử, còn insight là kết quả của sự thử
- Mô hình kinh doanh và định giá
- Nghiên cứu, tìm ý tưởng
- Dữ liệu cho dự đoán tin cậy về hành vi người dùng
- Dữ liệu cho ta biết hành vi của một người, nhưng không nói lý do họ làm điều đó
- Các câu chuyện mà người dùng kể được lấp đầy bởi khoảng trống mà họ kỳ vọng vào thế giới
- Persona tuy tạo sự đồng cảm với người làm sản phẩm, nhưng lại chứa quá nhiều giả định
- Đừng dùng câu chuyện người dùng (user story), mà hãy dùng câu chuyện công việc (job story)
- ❓Persona khác gì với segmentation
- ❓Persona là exemplar của segmentation
- Segmentation là một nhóm user, còn persona thường là một chân dung có tính đại diện của nhóm đó
- 5 người dùng đầu tiên phát hiện 85% vấn đề ở sản phẩm
- Con người không muốn mâu thuẫn với những điều mình nói ra
- Con người nhiều khi không nói dối mà chỉ đang lý tưởng hoá bản thân
- Con người thường lạc quan về hành vi của mình
- Người dùng nói thích một tính năng không có nghĩa là họ sẽ bỏ những sản phẩm khác để đến với tính năng của mình
- Người có nhu cầu thường để lại ấn tượng nhiều, nhưng số lượng không nhiều trong thị trường
- Người dùng thường không nói không với những tính năng mới
- Sự tiêu cực của người dùng là cơ hội làm dự án
- Hãy hỏi người dùng họ cần sản phẩm này để giải quyết việc gì
- Insight sẽ thường ra ngay lúc phỏng vấn
- Khi phỏng vấn hãy hỏi cả về hành vi, đừng chỉ hỏi về lý do họ làm điều đó
- Kết quả phỏng vấn phải actionable
- Một số ví dụ về mục tiêu nghiên cứu
- Người dùng dịch vụ của mình thường phản hồi những thứ họ chấp nhận được. Người dùng dịch vụ của đối thủ thường phản hồi những thứ họ không chấp nhận được
- Nên phỏng vấn cả những người không nằm trong nhóm đối tượng mục tiêu của mình
- Nên phỏng vấn một tập người dùng nhiều lần, nhưng không nên một người nhiều lần
- Việc chọn đối tượng phỏng vấn phụ thuộc vào việc giả định của mình liên quan đến hành vi nào
- Người thích mình thường có nhu cầu khác về sản phẩm so với người không thích mình
- Người tham gia phỏng vấn nhóm cần có đặc điểm tương đồng để mọi người cảm thấy tự tin, thoải mái
- Nếu có thể phỏng vấn liên tục thì không gặp phải áp lực hỏi quá nhiều
- Phần lớn các câu hỏi nghiên cứu không thể sử dụng để hỏi trực tiếp
- Phỏng vấn là để hiểu vấn đề người dùng gặp phải, không phải để cải thiện giải pháp
- Nghiên cứu người dùng không nên là một bước, mà nên là một hoạt động diễn ra liên tục
- Phỏng vấn phù hợp để hiểu lý do cho một hành vi của một người
- Phỏng vấn phù hợp để đánh giá cách tiếp nhận hay thái độ
- Phỏng vấn thường kém chính xác trong việc dự đoán các hành vi tương lai của người dùng
- Phỏng vấn
- Phỏng vấn người dùng nên được diễn ra liên tục, tốt nhất là hàng tuần. Khảo sát thì không nên nhiều, mỗi quý một lần là được
- Trong nhiều trường hợp, kết quả phỏng vấn bị rơi vào quên lãng
- Trả tiền cho người phỏng vấn sẽ khiến họ làm việc chuyên nghiệp
- ❓Câu hỏi khiến cho đáp viên muốn nói dối
- ❓Có nên phỏng vấn một người nhiều lần để vét cạn suy nghĩ của họ về các giả thiết của mình
- ❓Có nên yêu cầu người tham gia phỏng vấn phải đọc trước cái gì không
- ❓Có nên đưa câu hỏi trước cho người tham gia phỏng vấn đọc trước không. Có nên cho họ coi kết quả ghi chú của mình không
- Việc phỏng vấn làm ta mệt và muốn nghỉ ngơi, nhưng ta vẫn phải tiếp tục làm
- ❓Người dùng thấy không hiểu ý đồ của mình và giải thích nhiều vì nghĩ là mình không hiểu
- ❓Làm sao để cho họ tiếp tục nói hết ý của mình khi mà họ không có nhiều thời gian cho mình, và mình cũng không có nhiều tiền để trả họ
- Tìm hiểu vào bối cảnh, không chỉ hành vi đơn lẻ
- Phỏng vấn phi cấu trúc hữu ích khi nghiên cứu viên có đủ thời gian phỏng vấn nhiều lần, ở nhiều hoàn cảnh khác nhau, và khi chủ đề nhạy cảm
- Sự miễn phí chỉ có ích khi ta cần phản hồi của người dùng, hoặc khi nền tảng của ta cần hiệu ứng mạng
- ❓Với những người mà mình biết sẽ có cố gắng tìm hiểu mình, mình nên tiếp tục cho họ thấy mình có những thứ họ cần, hay là cho họ thấy mình là như thế nào
- Có 4 loại câu hỏi khảo sát
- Khảo sát định lượng chỉ có tính chính xác tương đối
- Vì câu hỏi nghiên cứu thường là câu hỏi mở, nên ta cần chuyển thành câu hỏi định lượng được
- Khảo sát thường được dùng để kiểm chứng các phát hiện quan trọng có được từ phỏng vấn trên quy mô lớn
- Khảo sát tốt nhất là chỉ có một câu. Người chịu khó trả lời câu hỏi mở thường là người đã quý mến mình sẵn rồi
- Những câu hỏi đánh giá tác động đòi hỏi phải nghiên cứu sâu
- Ý tưởng với hiểu biết sâu đều là giả thiết
- ❓Hiểu biết sâu thông qua việc bắt tay vào làm, hay hiểu biết sâu thông qua việc nghiên cứu
- 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
- ❓Khảo sát để lọc ứng viên phỏng vấn khác gì khảo sát để xác nhận phát hiện mới từ phỏng vấn trên quy mô lớn
- 1 nghiên cứu 20 ngày khác với 4 nghiên cứu 5 ngày
- Lean comes from the automotive industry and they have a lot of regulations to follow
- Người dùng hài lòng với chất lượng sản phẩm, không phải tốc độ làm ra nó
- Người dùng yêu cầu tính năng không có nghĩa là họ sẽ 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
- Nên chọn tính năng nào
- Phát triển sản phẩm
- 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
- Những người viết phần mềm vì cả nhu cầu của mình và người giống mình
- Khoảng 20% người mở tab lên là tắt ngay hoặc để đó không đọc
- Người muốn có giải pháp sẽ muốn đọc nội dung dài
- Những tính năng khác của app hấp dẫn hơn tốc độ app, trừ phi nó quá chậm
- Người đã biết xài công nghệ sẽ muốn tiết kiệm thời gian
- Trong số những người chịu đọc, về trung bình họ dành ra 25 s đầu để hiểu giao diện, các tính năng khác và hình ảnh. Sau đó cứ 100 chữ thì đọc thêm 4.4 s, cỡ 18 chữ
- 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
- Việc làm sản phẩm thì muốn làm thật ít chức năng càng tốt, nhưng việc viết phần mềm đòi hỏi nên lên kế hoạch các chức năng kỹ càng
- ❓Thu thập kinh nghiệm từ các blog cũng là xây dựng sản phẩm
- ❓Tung ra quá sớm sẽ dễ bị thị trường chi phối ngược lại
- ❓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
-
Quản lý rủi ro:
-
Quỹ, gọi vốn:
- Người đã muốn tiết kiệm thời gian sẽ chấp nhận trả phí
- Nhiều người thấy việc không thu phí thì chỉ làm cho vui, dễ bug
- Funder-exclusive writing should be a secondary by-product of primary work
- Crowdfunding depends on highly visible public work
- Getting Paid for Open Source Work
- Lý do thường gặp nhất của những người ủng hộ trên Patreon là để sản phẩm mà tác giả đang làm hoàn thành sớm hơn, hơn là để cảm ơn những gì họ đã làm
- Patreon không được thiết kế để có được sự tương tác trực tiếp với người ủng hộ
- Patreon quảng cáo theo ngôn ngữ của kinh tế quà tặng, nhưng cách vận hành lại theo kinh tế thị trường
- Patreon vận hành gần giống như một cuộc mua bán hơn là hoàn toàn ủng hộ
- Nhà đầu tư tìm kiếm tiền trong vụ đầu tư
- Nhà đầu tư đầu tư vào việc kinh doanh, không phải ý tưởng
- Thiên thần dùng tiền của bản thân. VC dùng tiền của người khác
- Thứ quyết định hiệu quả của việc kinh doanh là văn hoá doanh nghiệp và phản ứng của thị trường về mình
- Nhà đầu tư tốt nhất đầu tư vào những startup chưa có câu chuyện thuyết phục, vì khi đã có câu chuyện thuyết phục rồi thì startup có giá đắt hơn
- Định giá
- Để gọi vốn thì rất cần nắm chắc những con số
- Nếu không thế nói về thành tựu của mình thì hãy nói về tốc độ của mình
- Thứ quan trọng không phải là ý tưởng, mà là người có ý tưởng
- Hãy nhắm còn đủ tiền cho khoảng 20 đến 30 lần thất bại
- Không thể làm dự báo tài chính dài hạn khi chỉ mới có một vài người dùng
- Người cho tiền thấy mình đáng được cho tiền nhất khi không thấy mình cần tiền
- Nhà đầu tư đầu tư vào bạn và vào câu chuyện của startup
- Trước khi gây quỹ cần biết mục tiêu của mình là gì
- Hãy loại bỏ quyền lợi truyền thông tài trợ ra khỏi tài liệu mời tài trợ
- Tài trợ từ doanh nghiệp, CSR
- Ít có doanh nghiệp nào làm CSR mà thực sự đặt vấn đề phát triển cộng đồng lên hàng đầu
- Việc thuê ngoài chỉ giải quyết được một lần, trong khi phải thử rất nhiều lần
- Quỹ, gọi vốn
- 30% of the pivotal papers from Nobel laureates in medicine, physics and chemistry was done without direct funding
- Kinh nghiệm gây quỹ cho dự án nghiên cứu độc lập
-
Thành lập dự án:
- Làm thứ một số người rất cần quan trọng hơn là làm thứ nhiều người thấy hay
- Không có giải pháp nào cho người sáng lập để giải quyết sự quá tải ngoài những lời khuyên chung chung
- Chiếm lĩnh thị trường nhỏ trước
- Làm người sáng lập có hại cho việc cân bằng cuộc sống
- Mở ra một công ty giống như nhảy xuống vực và lắp được máy bay trong lúc rơi xuống
- Nhà đầu tư không ăn cắp ý tưởng vì phải cạnh tranh với các nhà đầu tư khác
- Những dự án ngoài lề thường là ý tưởng tốt cho startup. Những ý tưởng chỉ để có một startup lại thường không tốt
- Nhà đầu tư là người ra quyết định cuối cùng về sản phẩm, không phải người dùng
- Quá trình chú ý và ghi nhớ ép ta phải đơn giản
- Startup giải quyết những vấn đề nghe thì tồi
- Sự đơn giản ép ta phải làm nó cực kỳ tốt
- Việc kể ý tưởng startup ra thường không phải là nguy hiểm, vì không ai cạnh tranh với ý tưởng tồi
- Startup = tăng trưởng
- Ý tưởng startup lớn thách thức căn tính của bạn
- Đừng nhìn vào đối thủ cạnh tranh, mà hãy nhìn vào người dùng
- Hiểu về quản trị chỉ cần thiết khi đã có thành công bước đầu. Trước đó thì hãy chỉ tập trung vào sản phẩm
- Đa số startup không chết vì cạnh tranh với đối thủ, mà vì không có người dùng sản phẩm của mình
- Liệt kê các giả định tốt hơn là liệt kê giá trị
- Thành lập dự án
- Trực giác về con người thường đúng. Trực giác về cách startup hoạt động thường sai
-
Xây dựng nhóm, quản lý nhân sự:
- Gốc của thương hiệu là văn hoá doanh nghiệp
- Không nên có quá 20 nhân sự khi chưa có sản phẩm phù hợp thị trường
- Một người sẽ tiếp tục được thăng chức dựa trên thành tích trong vai trò hiện tại cho đến khi họ đạt đến một vị trí mà họ không đủ năng lực thực hiện tốt
- Vị trí càng cao trong tổ chức thì đề xuất càng dễ bị cấp dưới hiểu thành yêu cầu phải làm
- Người người vạch chiến lược hay nhiều khi được giao triển khai luôn, hoặc người làm chuyên môn tốt nhiều khi được đề bạt lên làm quản lý, lãnh đạo
- Người lãnh đạo tốt là người tránh được khủng hoảng ngay từ đầu chứ không cần vượt qua nó. Nhưng vì vậy, họ sẽ không có câu chuyện thú vị nào để kể
- Bội thực chat nhóm gây phân tán nguồn lực, mất tập trung, tăng rủi ro lộ dữ liệu
- Có sự đánh đổi giữa quá tải thông tin và cập nhật thông tin kịp thời
- Việc muốn các thành viên sử dụng Discord thay cho Facebook hay Zalo thường khó khăn
- Thảo luận có tính xây dựng là để tìm kiếm sự hiểu nhau, không phải để tìm kiếm sự đồng ý
- Việc có quá nhiều ý kiến làm ta thấy loạn
- Đa số những lúc cần phải ra quyết định thì đều có nhiều áp lực
- Có nhiều người đăng ký tham gia nhưng chỉ để thoả mãn sự tò mò
- Tìm được người cùng muốn làm chung với mình và đủ rảnh là rất khó
- Không cần kiếm thêm nhân sự khi không thấy quá nhiều việc
- Từng làm chung với nhau trước khi tuyển dụng sẽ tốt hơn là phỏng vấn
- Có một quy trình đánh giá năng lực định kỳ sẽ làm giảm vấn đề khi tăng lương hoặc đuổi việc nhân viên
- Một nhóm đáng tin là nhóm mà các thành viên có thể nói lên sai lầm của mình
- Nhìn thấy được người kia đang làm gì làm tăng sự tin tưởng đối với họ
- Văn hoá tổ chức là những giá trị, niềm tin và hành động của mỗi thành viên giúp đóng góp cho sứ mạng của nó
- Sociocracy
- Chuyển giao tri thức rất khó khăn
- Nếu thất bại nhanh hơn thì sẽ học nhanh hơn
- Tổ chức nào học nhanh hơn đối thủ thì sẽ có lợi thế cạnh tranh lớn hơn
- ❓Liệu quy luật 1% vẫn còn đúng cho nhóm nòng cốt
- Văn hoá giao tiếp bối cảnh thấp thường có ở tổ chức phẳng. Văn hoá giao tiếp bối cảnh cao thường có ở tổ chức phân cấp
- ❓Thành viên nòng cốt không cần trách nhiệm ngang hàng, nhưng cần có sự tự gánh trách nhiệm
- ❓Thành viên nòng cốt là người chịu trách nhiệm lớn nhất hay là người có nhiều đóng góp nhất